Subject: [dmarc-ietf] Changing algorithms

From: "John Levine" <[email-masked]>
Date: 5 Feb 2017 02:07:31 -0000

As threatened, albeit kind of late, here's plan for how to rotate to a
new algorithm.

We note that every Arc-Seal and Arc-Message-Signature header has an a=
tag that identifies the hash and signing algorithms used.  (In sec
5.1.1.1 it just says hash, which is wrong.)  Every DKIM key record has
k= tag that says what signing algorithm the key is for.  That should
mean that we could publish several key records for several algorithms
at the same domain and selector, except that RFC 6376 sec 3.6.2.2 says
you can't.  I think that's a bug in 6376, but we can fix that later.

We relax the language saying that there can only be one Arc-Seal
and one Arc-Message-Signature header for each i= value to say
that there can be a group but they can only differ in the 
a=algorithm, s=selector, b=signature, and for A-M-S the bh=hash
if the algorithms have different hashes.  The group is valid
if the recipient can verify at least one of them.

The Arc-Seal signature covers all of the A-S and A-M-S headers, even
ones it can't verify, and the header says cv=pass if it could verify
at least one of the headers in each group.  (Even if you can't verify
a new algorithm, maybe the next system can.)  To avoid infinite
regress, we leave the instructions in 5.1.1.3 alone, so when adding
new A-S headers, they're added as a group and the signatures are
computed as through the b= in all of the headers in the newly added
group were empty.

I don't think this will add a lot of code, and it provides a
straightforward upgrade path.  When a system is upgraded to support a
new algorithm, it starts adding headers for both the old and new
algorithm.  This potentially adds an extra A-S and A-M-S header at
each level, but it's just linear, not exponential.  When checking
signatures, verifiers should try the new algorithm first in each group
with multiple headers (it's a lot faster), and if so it need not check
any others.

Receivers can see from the ARC headers on their incoming mail how much
of the mail has new signatures in addition to the old ones and who's
adding them.  Eventually there'll be enough new signatures that we can
nudge the people still using only old ones and eventually only use the
new ones.

One minor weakness is that the A-S signature signs the headers in a
group in whatever order they're in, and if a later system reorders
them, the signature will break.  We could address that by allowing
sequence numbers like i=n.m where the m only affects the order in
which they're signed, but I doubt it's worth it.  It's hard to imagine
a mail system that would only reorder the headers and not also break
the signatures in other ways.

R's,
John