On 5/11/15 1:15 PM, Scott Kitterman wrote: > On Monday, May 11, 2015 07:23:58 PM John Levine wrote: >>> I propose a short draft that updates 6376 to say MUST use at least 1024 >>> bits and setting that as the minimum size verifiers must be able to >>> validate. I'm volunteering to write it if people agree it's appropriate. >> That seems fine. This makes the usable range fairly small, since keys >> longer than 1536 run into the 512 byte DNS packet limit which shouldn't >> still be an issue 16 years after EDNS0 was introduced, but is anyway. I >> don't see that as a problem, but it's likely worth mentioning. > The last time I saw an interoperability problem related to EDNS0 was this > month, so while I generally agree, the impact is still non-zero (it may be > time to decide we don't care), but either way, I'm not proposing we do > anything other than raise the floor for this update in order to avoid having > to > decide about things like this. > >> With regards to Doug's point, yeah, we could have other ways to >> distribute keys like, say, a new DNS record type that has a binary >> key. For some reason, that gives me a bad feeling. > Even if it was a good idea, it wouldn't be a quick update. Dear Scott,
It was not Moore's law that made the 768 bit keys unsafe. They were unsafe when DKIM first proposed their use. NIST already deprecated use of 1024 bit keys and lists them as legacy, so why stop at 1024? Even those keys are already unsafe, especially when poorly managed. There are other weaknesses noticed causing DNS to be less untrustworthy. So overhead likely needs to factor in use of DNSSEC. Since IPv6 changed the minimum MTU from 576 to 1280, perhaps firewalls will more reliably permit larger DNS message sizes instead of being limited to 512 bytes. Base64 increases the amount of bytes required by 133.4% over a binary key. This increase should include the 11 bytes used by DKIM tags and 17 bytes used by DKIM text than otherwise needed by a binary approach. The DKIM non-binary penalty is approximately 71 bytes and 114 bytes for 1024 and 2014 bit keys respectively. Can we expect at some point DANE will replace DKIM's key methodology? This will force down the barriers imposing limits inhibiting reasonable levels of security. Or is this something not to be asked? Ever since Edward Snowden revelations driven home by Barbara Honegger, it seems high time to not be sloppy about security. Especially when you don't know who to trust. Regards, Douglas Otis _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
