Re: [ietf-dkim] DKIM Key Sizes

[Jon Callas <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


> On Oct 27, 2016, at 1:29 AM, Peter Goldstein <[e-mail]> wrote:
> 
> Those guidelines ... specify that receivers MUST validate signatures of 512 to 2048 bits, but are not required to validate signatures with longer keys - may be worth revisiting given advances in computing power, the increasing importance of DKIM as an element of email authentication, and the reuse of these guidelines in other proposals (i.e. ARC).
>  

[...]

> 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. 

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.

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.

In any event, I don't object to changing it, but I do think that if someone's going to implement long keys, they're going to get criticism about enabling surveillance of their users.

	Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.3.0 (Build 9060)
Charset: us-ascii

wsBVAwUBWBJ/yPaTaG6hZJn9AQi25gf/RKmX+4WUI+QatOiyiX0wKRsW2yZ8AGvE
8PYRnT+eB9a9QJ6xEBSllFC5DTO97Qwkdeob5rjpMEpgGC8XVujPN31kuFn0M9Hd
diRpt0QSpT5VWIqVFoHv0kg1ucylJrjuDDQv8YbvKEwnSI7UDdWUilU7eZLxc341
B5D0jhAMbKnXFu6xQiTf+ANcpnpyaIOaQdfBo+4xsh1ZQ8ghgIT7gvSva3hfgFQy
1yIC5IikhMKUCIhBalu6y5hKdwLOHS+L9Fi8JTDSt3hdWQc9DQcYz4mCQqqZvOF8
qTs7pKKoJnn/+KkePZURH6xm6/yAVyK7/K5dux3qFuUc8QykRM6QHQ==
=3qlc
-----END PGP SIGNATURE-----

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html