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

[Michael Storz <[e-mail]>]

Am 2016-11-17 21:57, schrieb Murray S. Kucherawy:
> On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz <[e-mail]>
> wrote:
> 
>> Thanks, I see. That means the recipient is bound to the message and
>> an attacker cannot delete or change the new tags. Great solution, I
>> like it, though I do not like the consequences when this extension
>> will go into production.
> 
> You may not need to worry about that.  We've reached a point where I
> think we can legitimately say, "We took a serious look, and this is
> the best we could come up with.  It has some pretty ugly side effects.
>  Are you sure you can't just stop signing spam?"  And absent a
> compelling answer to that question, there's no need to roll this out
> even as an experiment.
> 
> -MSK

Thanks Murray. My concern was, that a change to DMARC would give people 
the possibility to switch this optional extension to a mandatory one 
which has dramatic consequences at the moment. And I agree this change 
to DMARC should not be done at least in the near future.

However, for the extension itself we should carefully evaluate the 
positive and negative aspects.

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.

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. 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
===

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

Depending on an underlying policy from the administrator the "refuse to 
sign with this extension" could mean

- to sign without the extension
- wave the message through without signing
- to reject the message with an error like "Configuration error: DKIM 
signing this message would leak BCC recipients"

This check and the resulting split action is RFC 5322 compliant. However 
it would need to use the second variant of the bcc handling with the 
single-bcc-recipient-email.

In this multi-recipient scenario the hashing of the recipient makes 
sense. It protects against passive attacks (just looking at the header) 
but not against active attacks.

How about this?

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