Am 2016-11-17 21:57, schrieb Murray S. Kucherawy:
On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz
<Michael(_dot_)Storz(_at_)lrz(_dot_)de>
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