Hi Jon,
On 10/28/16 12:29 AM, Jon Callas wrote:
I'd like to suggest that it may be a good idea to increase the upper
value to 4096 or even 8192, to ensure that the standard is compatible
with best practices going forward.
I don't object to increasing it in the standard, but operationally I
don't think it's a good idea. Per-message processing cost is one
reason, but the larger one is the semantic value of a DKIM signature,
and what it is trying to do.
DKIM is a conversation between two administrative domains, and a
signature only states that an administrative domain is taking
responsibility for placing the message in the message stream. Nothing
more.
I really don't get your point. Either the thing is worth signing or it
isn’t. See below.
That assurance comes at a cost of whatever integrity that assigns to a
message that might have been unintended. That message integrity is a
privacy loss by the users.
The real-world case in point is the leaked Podesta emails, where some
people have asserted that authenticity can be checked via the DKIM
signatures. I've raised an eyebrow on that, and the bottom line is
that you're presuming that attackers were sophisticated enough to
steal the email, yet unsophisticated enough that stealing the DKIM key
from an MTA is out of the question.
If it’s the same conversation I was engaged in, I think the person was
just confused. A simpler approach to plausible deniability is simply
not to sign. And further, just because a person can hack someone’s
personal message store, as seems to have happened to Podesta, doesn’t
mean that they can hack the private key out of Google. Furthermore,
using the example above, the key would actually have to be around for a
while (e.g., not rotate out of DNS). In fact, if the key really is
intended to verify the source over a longer period of time than, say,
delivery, certainly 512 is not enough.
The full discussion is pretty nuanced, and I think the relevant part
here is that if an administrative domain wants to protect the privacy
of its users, it should be using *smaller* DKIM keys, not larger ones.
I think I could convincingly argue that a privacy-friendly email
provider is better off using 512 bit keys (where there's a chance of
spam forgery) than 4K keys (where there's a chance of ruining the
privacy of the customers). Now actually, I think the sweet spot for
key size is above 512, but it's lower than 768. For maximum balance,
you want the key to take longer than a week to crack, but less than a
year, and change it every month. Or something like that. You get the idea.
Color me obtuse, but are you worried about the incentives to break into
the user's account or are you worried about the provider wanting to peer
into users' email in order to assure itself that it’s not spam?
Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html