Subject: Re: [ietf-dkim] DKIM Key Size Constraints

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 May 2015 16:15:03 -0400

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.

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 May 2015 16:22:51 -0700

> 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