Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

[Brandon Long]

On Tue, Nov 22, 2016 at 8:05 AM, John Levine  wrote:
>
>
> >And, if you think about it, spam is in the eyes of the recipient.  If you
> >take this message I'm composing right now and send a couple billions
> copies
> >to the top 10 mailbox providers, how many spam markings will it get?  With
> >some of the spammers we deal with, all they're looking for is clicks on
> the
> >links in the email, there is nothing particularly commercial about the
> >content itself.
>
> Now I'm really confused about what problem we're trying to solve here.
> You are of course right that there are messages that become spam if
> they're remailed a zillion times, but there are also messages that
> don't.  If I send a message to, say, nanog, it goes to a lot of
> people, the DKIM signatures usually survive, and it's not spam.
>
> If the bulk remail is spam, that will presumably affect the reputation
> of the places from which it is remailed.  That's not enough?
>

In a reputation based system, you take reputation on various features of
the message, and whether or not a message is spam depends on all of those
features, and then feeds back into each of those features.

So, the IPs for the botnet the message is spammed from will certainly take
a hit, or may already be bad.  The reputation of the dkim auth domain is
likely also to suffer, though.

In an IPv6 world, domain auth may play a higher role than IP for
reputation, given the high number of IP addresses.

Of course, the obvious mitigation there is to be more careful of dinging
dkim auth when spf auth doesn't pass or match.

Brandon
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Michael Storz]

Am 2016-11-22 03:15, schrieb Brandon Long:

Also realize that this isn't "Gmail shouldn't sign spam", it's
everyone who normally has a good reputation needs to not sign spam,
this is a way to steal reputation from any service allowing you to
choose your own message, and can be used against any mail receiver.

That said, I think this proposal mostly duplicates spf with some small
benefit, but one can combine the spf and dkim signals to try to combat
this issue without introducing a new standard.  Forwarding will take
the worst hit in false positives, but things like arc may help with
that issue separately.

Brandon


The lesson I learned from discussing this draft is:

If you want to DKIM sign your messages you should either

- publish a SPF record (SPF gets mandatory) or
- include the discussed extension (in this case it looks like SPF is not 
needed anymore, SPF is optional)


and if a message leaves your ADMD you have to either

- DKIM sign it, if it originates from your ADMD or
- ARC sign it, if it is relayed through your ADMD (recipient has 
changed)


It is not enough to use ARC only in the case the message content has 
changed. It looks like only then a replay attack can be detected or 
mitigated.


Regards,
Michael
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[John R. Levine]

I'm with Murray -- why is this a problem?  Single recipient has been
the de-facto standard for years, and unless you are extremely
bandwidth constrained, it's faster.


No, it's not faster, see my answer to Murray. It's wasting a lot of 
ressources.


People who've measured say the elapsed time is faster, and the extra bytes 
on the wire don't matter.  This is an old argument, and not one you're 
going to win.


John, did you read my email? The whole text is about how the leakage of the 
BCCs can be prevented and the feature of a multi-recipient email be 
preserved. If you see an error in the algorithm, please explain.


See previous messages, particularly the ones from Ned Freed.  Any sort of 
multi-recipient signing is subject to guessing attacks.


This isn't saying that signing the recipient is a good idea, but signing 
them individually is no worse than signing them together and avoids the 
leakage.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Michael Storz]

Am 2016-11-19 15:22, schrieb John R. Levine:
The negative side of the proposal is the requirement to split all 
multi-recipient-emails to single-recipient-emails, which is a show 
stopper for me.


I'm with Murray -- why is this a problem?  Single recipient has been
the de-facto standard for years, and unless you are extremely
bandwidth constrained, it's faster.


No, it's not faster, see my answer to Murray. It's wasting a lot of 
ressources.




 But I don't think this requirement is needed. I would allow a list of

recipients and have a paragraph which states ...


See previous discussion.  We rejected multi-recipient signatures
because of the bcc recipipient leakage.


John, did you read my email? The whole text is about how the leakage of 
the BCCs can be prevented and the feature of a multi-recipient email be 
preserved. If you see an error in the algorithm, please explain.




Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for 
Dummies",
Please consider the environment before reading this e-mail. 
https://jl.ly


Regards,
Michael
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[Michael Storz]

Am 2016-11-18 22:53, schrieb Murray S. Kucherawy:

On Fri, Nov 18, 2016 at 3:47 AM, Michael Storz 
wrote:


Normal DKIM-Signatures give us a way to check if the body and/or
header of an email has been changed on the way from the signer to
the verifier. The new extension extends this to the recipients of
the email. A change means the email was either relayed (now indirect
mail) or replayed. I think this is a new valuable information for an
anti-spam-system. However, we have not discussed how this gets
propagated from the verifier to the consumer of the information.


That's certainly possible to do if it's useful.  The pseudo-API
described by RFC6376 is vague; it just says the signature has to fail.
 Whatever reporting mechanism you want to provide in an actual
implementation is fine as long as it complies just to that.  A
specific error code, or sub-code (a la enhanced status codes) is
certainly a valid choice.  OpenDKIM has a large number of them.


I meant how the Authentication-Results header field would be changed to 
transport the result of this extension.





The negative side of the proposal is the requirement to split all
multi-recipient-emails to single-recipient-emails, which is a show
stopper for me.


That's curious; why?


Because SMTP is defined as a multi-recipient transport. If this 
extension would require a mandatory split of every message, then this 
has to be discussed at IETF-SMTP because the semantics of SMTP are 
changed. It is a big difference if the implementation of a mta decides 
to split all messages on arrival or if some ISPs decide to send only 
singe-recipient emails, or if a protocol extension requires mandatory 
splitting.


If a sender splits all emails because of some local advantage the sender 
forces the receiver to waist a lot of ressources for nothing. Instead of 
one message going through anti-spam several messages must be processed. 
For example, we are runnig amavisd+spamassassin in pre-queue mode to be 
able to reject spam on arrival (legal reasons). Splitting means we have 
to provide more ressources for parallel connections and/or to limit the 
number of connections per ip address or network which results in delayed 
messages.





But I don't think this requirement is needed. I would allow a list
of recipients and have a paragraph which states:



===
Every compliant implementation of this extension MUST check if the
signing of the message as is would result in the leakage of hidden
BCC recipients. The check has to be done in the following way:

- Collect the set of visible recipients from the header fields

* From
* Sender
* Reply-To
* To
* CC
* Resent-From
* Resent-Sender
* Resent-To
* Resent-CC

- For each address from the set of envelope recipients check if the
address is included in the set of visible recipients.

If not, then either

* refuse to sign with this extension or
* split the message and sign and send a single-recipient-copy of
the message with this recipient


We discussed the idea of tying it directly to To and Cc.  The downside
of doing so is that participating DKIM implementations would have to
know the syntax and semantics of RFC5322 header fields; right now it
needs only very basic syntax information about them, just enough to
run canonicalization.  It adds a whole lot of code complexity we'd
rather avoid.  On top of that, if someone were to later register some
other sender or recipient header field that should be included in this
list, we'd have to update everything on the DKIM side by updating this
list.



I don't buy this argument. I would assume that every program which 
manipulates an email will use a library for this. Normally such a 
library will have a function call to extract the addresses from a header 
field. Using libopendkim you would use


**  DKIM_MAIL_PARSE_MULTI -- extract the local-part and hostname from a 
mail

**   header field that might contain multiple
**   values, e.g. "To:", "Cc:"

(BTW, the files dkim_mail_parse_multi.html as well as 
dkim_sig_setdnssec.html are missing in the distribution of OpenDKIM.)


How high is the probability that a new sender or recipient header field 
will be registered? And even if that's the case, that's not a big 
problem. The program would treat the addresses as BCCs until the 
administrator changes the config to use the additional field or an 
update of the program would incorporate this field.



Simplicity is very desirable here, as is reaching across the layer
boundary as little as possible.


===

If the submission MTA already enforces the handling of bcc
recipients as described in
https://tools.ietf.org/search/rfc5322#section-3.6.3 [1] the signing
can always be done.


This sort of thing might work if you also specify the way both ends
will process this symmetrically.  Any ambiguity will result in
interoperability problems.



Sure, the algorithm has to be used on both sides otherwise it would make 
no