Let's break this down. If we're going to include recipients in the DKIM
signature, it seems we have at least three key design decisions to make:
(1) Whether or not to
(a) Enumerate the recipients, or some representation of them, outside the
DKIM hash, and sign that, or
(b) Include the recipients, or some representation of them, under the
DKIM hash only and don't expose them otherwise.
(2) Whether we enumerate recipients as:
(a) Cleartext
(b) Hashes
(c) Encrypted form
(d) Some combination of forms
Note that (2)(b)-(d) are still choices even in the case of (1)(b).
(3) Whether or not the recipient check is an (a) mandatory or (b) optional part
of the validation operation. (If you change what's signed in some way it's
effectively mandatory, if you add a header containing either the hash of the
recipients or a representation of the recipients and include it in
the DKIM signature in the normal way it's optional.)
Now, in regards (1), I have to say I regard (1)(b) as a complete nonstarter,
for all the reasons previously given. The complete lack of control the sender
has over how recipient lists get split along the way has the potential to cause
all sorts of subtle failures. And given past behavior I don't trust senders
using this feature to use mitigations like single recipient messages when
necessary. In fact I skeptical most senders will even understand the issues in
play well enough to do the right thing.
I also categorically reject arguments along the lines of "this problem only
happens outside the intended use cases for this capability so we don't need to
worry about it". Given the way DMARC has deployed it would be utter folly to
base our design decisions on limited use case claims.
This is especially true since this mechanism can be employed, albeit in a crude
way, to try and prevent people from forwarding messages the message sender
doesn't want them to forward. And I absolutely can see people noticing this
capability and trying to use it.
In fact given the history here it's going to be seriously tempting to view
(1)(b) as yet another attack on existing email infrastructure, with all that
implies.
I'll also note that the implicit claim that the (1)(b)/(2)(a) combination
avoids exposing recipient information is in fact false. A simple
counterexample would be a message to a single Bcc: recipient in addition to the
whoever is listed in the various headers. If I receive such a message I can
simply perform the DKIM operation on the recipients listed in the headers, and
if it doesn't match I know there's a Bcc:. I then try inserting possible Bcc:
recipients into the list until I get a match. And in many cases I'll have a
pretty good idea what addresses to try, so in those cases this attack will be
many, many, many orders of magnitude more effective than brute force.
I believe this last point makes (2)(a) a nonstarter regardless of how (1) is
answered.
As for whether or not (2)(b) or (2)(c) makes the most sense, the fact that in
many cases a recipient can come up with a list of likely addresses to try as
noted above is a really serious problem for any hash-based scheme. I'm not
exactly wild about the idea of all the public key operations (2)(c) calls for,
but I'm even less enthusiastic about adding to the reicpient leakage problem in
any way.
As for (2)(d), I see little point in using it in conjuction with (2)(b) - it's
much simpler to hash them all and be done with it. The combination of (2)(c)
and (2)(d), however, has the potential of eliminating some/most of the
public key overhead. (Another variation would be to use (2)(c) when
a public key is available and (2)(b) when it isn't.)
And that brings us to (3). It's important to note that making recipient checks
a mandatory part of validation doesn't make enforcement mandatory - a reciever
can simply detect and ignore DKIM signatures that require recipient checks.
The capability optional recipient validation provides is that a receiver has
the option of using the signature in the usual way. (That, and backwards
compatibility.)
Finally, I note that there is in fact a (0):
(0) This scheme can be applied to
(a) Any message
(b) Single recipient.
Requiring separate copies for each recipient in order to cover the recipient
with a signature renders (1) and (2) moot. In fact this scheme is so simple
that it merits serious consideration.
The big problem I see with (0)(b) is the overhead it imposes downstream. But as
I noted previously, so many messages are already sent separately to different
recipients it's unclear to what extent this is a factor.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
