Re: [dispatch] Updating DKIM for stronger crypto

[Cullen Jennings <[e-mail]>]

Hi John, 

Assuming that some groupr of people wnated to work on this, how would you suggest organizing the work in IETF? Is this just a draft that gets AD sponsored be a sec AD, or do we spin up a mini WG that does just one RFC, or is it an amount of work that it ends up with a WG that produces more than one RFC? I'm just trying to get a feel of how much work is involved here. 

Cullen


> On Feb 5, 2017, at 6:08 PM, John Levine <[e-mail]> wrote:
> 
> The DKIM spec RFC 6376 specifies the hash algorithm to use to make
> hashes of e-mail message bodies and headers, and the signing algorithm
> to use to sign them, with the results placed in a header in the
> message.  To check signatures, the recipient looks up the verification
> keys in the DNS, where it's stored in TXT records.
> 
> Every signature includes a tag saying what hash and signature
> algorithms it used, and every key record includes a tag saying what
> signature algorithm the key is for.  The plan was always that we'd be
> able to move to newer algorithms when needed.  Early versions of DKIM
> used SHA1 hashes, but by the time the original spec was published in
> 2007, we'd added SHA256 and the spec says that everyone should use
> SHA256 hashes but also has to verify SHA1 hashes.  In practice everyone
> uses SHA256.  
> 
> The only signature algorithm is RSA, and the spec says that verifiers
> must handle signatures from 512 to 2K bits and strongly suggests at
> least 1K bits.  So far, that has not changed.
> 
> Needless to say, 512 bits is now way too weak, and 1K is iffy, so it
> would be a good idea to update the advice.  Over in DMARC land, there
> is an anti-DMARC design called ARC which uses DKIM's signing
> algorithms, and it would be nice to launch ARC with up to date crypto
> too.
> 
> The obvious change would be a one sentence update to the DMARC spec
> saying to sign with at least 2K keys and verifiers must handle at
> least 4K keys.  The code changes to DKIM signers and verifiers would
> be trivial, and it is my impression that most verifiers handle larger
> keys now, since they just pass them to OpenSSL or the like.
> 
> Unfortunately, we have a stupid but significant problem.  DKIM keys
> are published in DNS TXT records, the strings in TXT records are
> limited to 256 characters, and keys longer than 1K bits don't fit
> in 256 characters.  No problem you might think, since the DKIM spec
> says that verifiers catenate multiple strings together, so you just
> break the key into two or three strings.
> 
> A lot of people manage their DNS using web based crudware at their
> registrar or DNS provider, and most of the crudware only handles TXT
> records with one string.  You don't have to tell me how broken that
> is, but the cruddy state of DNS provisioning has been a problem for
> many years, and nothing we say is going to fix it in any finite amount
> of time.
> 
> I note RFCs 7748 and 8032 which remind us that ed25519 has excellent
> performance with much smaller keys.  So I would like to publish a
> small update to the DKIM spec to add ed25519 as a signature algorithm,
> require that ed25519 signatures use at least 256 bits, and provide
> some advice for migration, e.g., publish both keys in separate TXT
> records and sign with both algorithms for a while.  256-bit keys fit
> in a single TXT string with ease.
> 
> Does this seem reasonable?
> 
> R's,
> John
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch