Am 2016-11-18 22:53, schrieb Murray S. Kucherawy:
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.
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 sense.
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.
My specification part ended at '===' These examples should only show
that more than one implementation is possible for the requirement
"refuse to sign with this extension".
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.
Sure, it must be evaluated, if this extension will give us enough value
which would justify the additional costs of the implementation.
-MSK
Links:
------
[1] https://tools.ietf.org/search/rfc5322#section-3.6.3
Michael
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html