[dispatch] Updating DKIM for stronger crypto

["John Levine" <[e-mail]>]

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