[cryptography] DKIM: Who cares?

Jon Callas jon at callas.org
Thu Oct 25 00:18:45 EDT 2012

Hash: SHA1

As someone who is one of the DKIM authors, I can but roll my eyes and shrug.

It's an interesting, intentional facet of DKIM that any given key being used only has to last as long as it takes the email to go from the sender's domain to the receiver's.

You could set things up so there's one key per message and take them down as the message is used. That's a lot of trouble, but you *could* do that.

However, RFC 4871 says on the subject:

3.3.3.  Key Sizes

   Selecting appropriate key sizes is a trade-off between cost,
   performance, and risk.  Since short RSA keys more easily succumb to
   off-line attacks, signers MUST use RSA keys of at least 1024 bits for
   long-lived keys.  Verifiers MUST be able to validate signatures with
   keys ranging from 512 bits to 2048 bits, and they MAY be able to
   validate signatures with larger keys.  Verifier policies may use the
   length of the signing key as one metric for determining whether a
   signature is acceptable.

   Factors that should influence the key size choice include the

   o  The practical constraint that large (e.g., 4096 bit) keys may not
      fit within a 512-byte DNS UDP response packet

   o  The security constraint that keys smaller than 1024 bits are
      subject to off-line attacks

   o  Larger keys impose higher CPU costs to verify and sign email

   o  Keys can be replaced on a regular basis, thus their lifetime can
      be relatively short

   o  The security goals of this specification are modest compared to
      typical goals of other systems that employ digital signatures

   See [RFC3766] for further discussion on selecting key sizes.

Note the weasel-words "long-lived." I think that the people caught out in this were risking things -- but let's also note that the length of exposure is the TTL of the DNS entries.


Version: PGP Universal 3.2.0 (Build 1672)
Charset: us-ascii


More information about the cryptography mailing list