On Fri, Nov 18, 2016 at 3:47 AM, Michael Storz
<Michael(_dot_)Storz(_at_)lrz(_dot_)de> 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.
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?
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.
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 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.
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"
These are purely implementation policy choices. At best a specification
like this one would lay them out as options in a non-normative way.
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?
It's worth considering further if we were to become convinced that this is
a problem that needs to be solved in the form of changes to DKIM. Right
now I think we should wait for operators to explain why going down any of
these paths is the best option. My main worry is that it seems to invite a
lot of complexity in code and either solution would introduce a lot of
complexity into the problem space, possibly more than they really would
solve.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html