Subject: [ietf-dkim] Core algorithm support/use, draft text v2

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Feb 2006 13:56:30 -0800

My proposal for language to cover supported text was confounded by suggesting 
some alternative language.  Discussion since then has frequently expressed 
agreement with my text, but even I am not sure what exact text folks are 
agreeing with.  I also think that Ned's point about the benefit of citing 
sender-side support, versus what is actually sent, is significant.

Based on all that, here is what I think reflects groups consensus.  Those 
agreeing should say something simple, like "agree".  Those disagreeing, should 
say something simple, like, "I proposal the following alternate text...".

Here goes:

    A validator MUST support {SHA-1, SHA-256}.

    A signer MUST support {SHA-1, SHA-26}.  A signer SHOULD use {SHA-256} for 
its higher security strength. However a signer MAY use {SHA-1}, such as for 
compatibility with an installed base, lower computational cost, or easier 
implementation effort.

Consensus?

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Arvel Hathcock <[email-masked]>
Date: Sat, 25 Feb 2006 16:04:05 -0600

> Those agreeing should say something simple, like "agree".

agree

-- 
Arvel

---

From: John Levine <[email-masked]>
Date: 25 Feb 2006 22:11:01 -0000

>compatibility with an installed base, lower computational cost, or easier 

Yes, with a note that if the IESG tells us they want something other
than SHA-256, that's fine.

R's,
John

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 25 Feb 2006 23:16:17 +0100

>     A validator MUST support {SHA-1, SHA-256}.

+1
 
>     A signer MUST support {SHA-1, SHA-26}.

IMHO unnecessary, "SHOULD use SHA-256" and "MAY use SHA-1"
are good enough as you have it here:

> A signer SHOULD use {SHA-256} for its higher security
> strength. However a signer MAY use {SHA-1}, such as for
> compatibility with an installed base, lower computational
> cost, or easier implementation effort.

All fine, but IIRC Stephen's concern was about the future
transition to another constellation when SHA-1 met Mr. Bond.

To emulate this, what would you say about CRC32 today ?  Is
that "SHOULD NOT accept" and "MUST NOT generate" ?  Or take
MD5 if CRC32 is too simple.
                              Bye, Frank

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Feb 2006 14:25:57 -0800

> than SHA-256, that's fine.

I always strongly resist spec language that tries to anticipate the unknown future.

At best, it is useless.  At worst, it confuses things.

If/when the language needs to be changed, for whatever reasons, it will be.

d/

-- 

Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Sat, 25 Feb 2006 14:31:43 -0800

On Feb 25, 2006, at 1:56 PM, Dave Crocker wrote:

> My proposal for language to cover supported text was confounded by  
> suggesting some alternative language.  Discussion since then has  
> frequently expressed agreement with my text, but even I am not sure  
> what exact text folks are agreeing with.  I also think that Ned's  
> point about the benefit of citing sender-side support, versus what  
> is actually sent, is significant.
>
> Based on all that, here is what I think reflects groups consensus.   
> Those agreeing should say something simple, like "agree".  Those  
> disagreeing, should say something simple, like, "I proposal the  
> following alternate text...".
>
> Here goes:
>
>    A signer MUST support {SHA-1, SHA-26}.  A signer SHOULD use  
> {SHA-256} for its higher security strength. However a signer MAY  
> use {SHA-1}, such as for compatibility with an installed base,  
> lower computational cost, or easier implementation effort.
>
>
> Consensus?

agreed (modulo someone at IESG telling us that there's something
better to standardise on than SHA-256).

(although I might word the second paragraph "SHOULD use SHA-256,
MAY use SHA-1" rather than requiring them to support one or the other.)

(On a more general note. I'm not convinced it makes any sense at
all to specifically require a signer to support anything in particular.
It's one of those cases where validator support is the important thing.
Causes no harm, though, it's just redundant.)

Cheers,
   Steve

---

From: [email-masked] (Wietse Venema)
Date: Sat, 25 Feb 2006 18:34:06 -0500 (EST)

> compatibility with an installed base, lower computational cost, or easier 

Agree.

	Wietse

---

From: Ned Freed <[email-masked]>
Date: Sat, 25 Feb 2006 17:54:32 -0800 (PST)

> are good enough as you have it here:

I'm sorry, but this is NOT good enough for all the reasons previously given.

> transition to another constellation when SHA-1 met Mr. Bond.

The problem isn't going to be finding a new hash - when SHA-1 falls we move to
SHA-256 and by the time SHA-256 falls I'm confident we'll have something
demonstrably better.

Rather, the problem is making sure that transitions are possible. This is why
having two mechanisms is a good idea - without two agility doesn't get tested
and likely will not work when we really need it.

> To emulate this, what would you say about CRC32 today ?

Not that it is especially relevant, but I would say it is fine for its intended
purpose, which never should have been (and among informed people never was)
cryptograhic in nature.

> Is

Attempting to list the many things it would be silly to do is a waste of time.
People will always find ways to be stupid. What we can do, and need to do, is
insure that a compliant implementation can be used intelligently.

				Ned

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 26 Feb 2006 03:59:36 +0100

Ned Freed wrote:

> the problem is making sure that transitions are possible.
> This is why having two mechanisms is a good idea - without
> two agility doesn't get tested and likely will not work
> when we really need it.

A "good idea" isn't necessarily expressed as MUST.  Violating
a MUST means that things break and cause harm.  MUST is also
not necessarily used to promote a certain way of implementing
a good idea like agility.  Instead of "edit config file and
select SHA-256" agility could be also implemented by "get and
install fresh package from where you got the last package".

I can see a SHOULD here, but no MUST.  Probably it's one of
the usual MUSTard interpretation issues, and we actually mean
the same thing.

If verifiers MUST support SHA-256, then it's fine if signers
support only SHA-256.  Why a "MUST SHA-1" for signers if they
don't want to use it ?  Maybe you want a "SHOULD support two
algorithms, and at this time one of them MUST be SHA-256, the
other MAY be SHA-1".  Or something else you talked about here,
whirlpool or whatever.

BTW, a conforming implementation could be a rather expensive
feature with an accredited SHA test lab and registration fee.

                           Bye, Frank

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Feb 2006 12:00:43 +0000

Dave Crocker wrote:
>    A signer MUST support {SHA-1, SHA-26}.  A signer SHOULD use {SHA-256} 
> for its higher security strength. However a signer MAY use {SHA-1}, such 
> as for compatibility with an installed base, lower computational cost, 
> or easier implementation effort.
> 
> Consensus?

Looks like there is consensus to me.

S.

---

From: Ned Freed <[email-masked]>
Date: Sun, 26 Feb 2006 07:59:52 -0800 (PST)

> A "good idea" isn't necessarily expressed as MUST.

Quite true but totally irrelevant. You're confusing the rationale for there
being a MUST implement for signers with the rationale for the specification
having two algorithms. The former is done to insure interoperability, the
latter to vet algorithm agility. These aren't completely disjoint goals, but
they're pretty close.

> Violating a MUST means that things break and cause harm.

Which is exactly what will happen if there is no mandatory-to-implement signing
algorithm. That's why there needs to be at least one MUST implement, unlike the
signers SHOULD SHA-256 MAY SHA-1 you advocated.

> MUST is also
> a good idea like agility.

I'm afraid this is a strawman since the reason for there being a MUST has
almost nothing to do with insuring agility.

> Instead of "edit config file and

Not if the implementation doesn't support SHA-256 or SHA-1 signing and there
are no packages to add such support.

> the usual MUSTard interpretation issues, and we actually mean

I don't think so. I think you're completely missing the point.

> don't want to use it ?

Another strawman. I don't have a problem with SHA-1 being a SHOULD, although a
MUST is also fine. My problem is there not being any mandatory-to-implement
signing algorithm at all.

> Maybe you want a "SHOULD support two

There's no "maybe" about it. I have been completely consistent here. Signers
and verifiers need to have at least one MUST implement in common, and it needs
to be the best algorithm choice we currently have available. And if past
history is any indication we don't have a choice in this. I've seen what
happens to specifications that reach the IESG that allow compliance without
assuring interoperability and specifications that try to go with inferior
crypto choices.

This then translates to MUST implement SHA-256 signing and verification.

As for SHA-1 the two reasons for having it are (1) We need a second algorithm
to insure agility and (2) Backwards compatibility. I would satisfied with a
SHA-1 implementation MUST for verify and SHOULD for signing, but MUST for both
is better as it vets agility more.

> feature with an accredited SHA test lab and registration fee.

I doubt very very much this is a real concern for most implementors, one way or
another. And on a personal note, I have been through an accreditation process
twice and was singularly unimpressed both times.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 26 Feb 2006 11:26:08 -0800 (PST)

> Consensus?

In case it isn't obvious, I fully support adopting this text.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Sun, 26 Feb 2006 16:52:39 -0500

I'm wondering if people who are arguing the difference between a MUST on
the signing end versus a set of SHOULD/MAY are confusing the choice of
terms "implement" versus "use".

I think Ned is saying that we MUST implement both on the signing end,
but we SHOULD use SHA-256 and MAY use SHA-1 (dependent on performance /
security tradeoffs).

	Tony

---

From: Ned Freed <[email-masked]>
Date: Sun, 26 Feb 2006 17:15:16 -0800 (PST)

> but we SHOULD use SHA-256 and MAY use SHA-1 (dependent on performance /

Correct.

				Ned

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Feb 2006 22:01:02 -0500

On 02/25/2006 16:56, Dave Crocker wrote:
> suggesting some alternative language.  Discussion since then has frequently
> expressed agreement with my text, but even I am not sure what exact text
> folks are agreeing with.  I also think that Ned's point about the benefit
> of citing sender-side support, versus what is actually sent, is
> significant.
>
> agreeing should say something simple, like "agree".  Those disagreeing,
> should say something simple, like, "I proposal the following alternate
> text...".
>
> Here goes:
>
> for its higher security strength. However a signer MAY use {SHA-1}, such as
> for compatibility with an installed base, lower computational cost, or
> easier implementation effort.
>
>
> Consensus?
>
> d/

I'm not experienced enough with IETF processes to know if the following would 
be a useful approach in an IETF context or not, but here goes anyway...

In other venues that I've worked in I've run into problems before when a spec 
had to be reopened "just to fix one little thing" and then the next thing you 
know, the engineers are loose and the whole thing has been updated in an 
incompatible way.  When there are aspects of a design the you KNOW are going 
to have to be periodically changed, it may be useful to break them out into a 
separate document so that the entire design doesn't get exposed every time 
you revise for the known item that will have to be updated.  I'm thinking 
this may be a similar case.  

Might it be useful to break the exact crypto algorithm out into a separate 
(very short) RFC so that it can be revised as necessary?  Something like:

     A validator MUST support all crypto algorithms listed as not deprecated 
in RFC ZZZZ or it's successors, initially {SHA-1, SHA-256}.

     A signer MUST support all crypto algorithms listed as not deprecated in 
RFC ZZZZ or it's successors, initially {SHA-1, SHA-26}.  A signer SHOULD use 
the highest strength algorithm in RFC ZZZZ or its sucessors, initially 
{SHA-256} for its higher security strength. However a signer MAY use earlier, 
non-deprecated algorithhms, initially {SHA-1}, for compatibility with an 
installed base, lower computational cost, or  easier implementation effort.

The initial text for RFC ZZZZ would be along the lines of:

For DKIM the following cryptographic algorithms are specified:

Deprecated:  None

Required:  SHA-1, SHA-256

High strength:  SHA-256

ZZZZ then could be easily revised at the point it becomes clear what the next 
high strength hash algorithm is or if SHA-1 is determined to be broken to the 
extent it should be deprecated.

None of this affects what has to be implemented now, but may make future 
transitions easier.

Scott Kitterman

---

From: Jim Fenton <[email-masked]>
Date: Sun, 26 Feb 2006 22:49:18 -0800

Dave Crocker wrote:
> point about the benefit of citing sender-side support, versus what is
> actually sent, is significant.
>
> {SHA-256} for its higher security strength. However a signer MAY use
> {SHA-1}, such as for compatibility with an installed base, lower
> computational cost, or easier implementation effort.
>
>
> Consensus?
[Just back from vacation, otherwise I would have chimed in earlier.]

I presume that the syntax {x, y} means "x and y".

I have read the discussion on "implement" vs. "use".  A signer could
follow the recommendation and use SHA-256 all the time; in that case why
MUST it implement SHA-1?  On the signing side, what's implemented makes
a difference if an algorithm is being negotiated, but there is no
negotiation here.

The word "However" in the next sentence makes it sound like SHA-1 is to
be used as an alternative to SHA-256.  This would have to be the case if
the motive is computational cost or implementation effort [is that
really a consideration?].  But compatibility would be maximized by the
inclusion of both signatures.

I propose the following alternate text:

Signers MUST use SHA-256.  A signer MAY additionally sign with SHA-1 for
compatibility with an installed base or to provide lower computational
cost for verifiers that wish to use it.

Verifiers MUST be capable of verifying signatures using SHA-256. 
Verifiers MAY verify signatures using SHA-1 for compatibility with a
legacy installed base of signers or to provide lower cost verification
when a SHA-1 signature is included.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Feb 2006 00:45:22 -0800

J>>    A validator MUST support {SHA-1, SHA-256}.

> I presume that the syntax {x, y} means "x and y".

yeah.  pseudo set notation.  don't giggle too much.  couldn't think of any other 
  way to designate it.  "x and y" would have been too simple and I wanted to 
imply that the list is subject to change.

> MUST it implement SHA-1? 

This was what Ned discussed:  An implementation could claim to be compliant, yet 
be unable to interoperate with the Sha-1 installed base.

  On the signing side, what's implemented makes
> a difference if an algorithm is being negotiated, but there is no

The required core set work without negotation.  Hence a new DKIM validator could 
work with a legacy DKIM signer.

> cost for verifiers that wish to use it.

My own opinion is that double signing is overkill -- and maybe misleading -- for
this application. As I understand things, SHA-1 is, in fact, valid for use 
today. At the least, if sha-1 gives acceptable security, then sha-256 isn't 
needed. If it does NOT give acceptable security, then it should not be used.

So double signing gives compatibility without better strength, but with lots 
more overhead.  In other words, I do not see the upside of the double signature.

d/
-- 

Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Mon, 27 Feb 2006 10:36:24 -0500

There will need to be an IANA registry of signing algorithms, and we
should actually point at that. Both key types ("rsa") and hash
algorithms ("sha-1", "sha-256") are pieces that will need to be
registered. We will need an IANA Considerations section dealing with the
registry process.

We could split the registration portion document out into a separate
document, or we could include it in the base. When MIME was first
created, descriptions of MIME media-type registrations and the registry
were all included together. It was eventually split out into separate
documents.

	Tony Hansen
	[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Feb 2006 16:40:21 +0100

> registered. We will need an IANA Considerations section dealing with the
You only need a registry

---

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Feb 2006 16:44:41 +0100

[Sorry about the truncated message.  Once more with FEELING...]

> registered. We will need an IANA Considerations section dealing with the
You only need a registry if you're NOT going to require an RFC to update
the algorithm.  I think such an RFC is desirable, if nothing else to
indicate which algorithms are deprecated, and perhaps why.  Conversely,
we could go for a registry and tie ourselves to an as of yet uninvented
process whereby the security directorate could do this for a group of
protocols all in one go.  My recommendation is that we plan former, but
expect someone to update the process either just prior to or sometime we
get through the process.  In either case it shouldn't slow us down.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Feb 2006 07:47:18 -0800

>> registered. We will need an IANA Considerations section dealing with the

the core specification must contain text that mandates support of a core sets of 
algorithms by all implementations.

Yes, each set that is allowed to be extensible also needs to provide for an IANA 
registry.

d/

-- 

Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Feb 2006 15:49:01 +0000

> registered. We will need an IANA Considerations section dealing with the

Do we really need that? There won't be a point in time where there
are 100 interesting DKIM signature algorithms, ever. (Now there's a
hostage to fortune:-)

There might be 10, I guess if I add up the various combinatorics (and
assuming that only a couple of ECDSA options are interesting).

S/MIME and PKIX do this via their RFCs (e.g. RFC 3279 for PKIX).

I think we could do the same, for *additional* algorithms and just
have the base spec include the consensus language on MUST/SHOULD
for rsa/sha-<foo>. An "additional algorithms" RFC could then be
developed later on, off the critical path. If it ever gets to be
unmanageable then someone can ask IANA for help.

Stephen.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Feb 2006 14:24:26 -0800

Dave Crocker <[email-masked]> writes:
> My own opinion is that double signing is overkill -- and maybe
> misleading -- for this application. As I understand things, SHA-1
> is, in fact, valid for use today. At the least, if sha-1 gives
> acceptable security, then sha-256 isn't needed. If it does NOT give
> acceptable security, then it
> should not be used.
>
> So double signing gives compatibility without better strength, but
> with lots more overhead.  In other words, I do not see the upside of
> the double signature.

I tend to agree with Dave here. 

That said, I think it's important to examine the security
requirements.  As I understand it, the major objective here is to use
the presence or absence of the message signature as an input to a
filtering process. Accordingly, unlike with S/MIME, it's not really
critical that people stop relying on a weakened hash algorithm as long
as the cost to forge a signature with that algorithm is
substantial.

Even if a collision attack is useful for attacking DKIM,
the cost to forge a SHA-1 signature would be quite high (2^61 as of
now), so the probability that a signed message is valid would remain
quite high. Given that the theory seems to be to treat an invalid signature
as nonexistent, this seems like an appropriate treatment to give an
invalid hash algorithm as well. So, I don't see a problem with letting
senders figure out which algorithm to use based on the likely
level of recipient deployment.

It seems to me that the key requirement here is that if/when senders
start moving to some new algorithm, that we be able to have a 
smooth transition. That requires two things:

1. That recipients handle multiple signatures correctly. I.e.,
   that signatures with unacceptable algorithms are skipped
   rather than creating an error if there is a valid signature.

2. That support for verifying that new algorithm be available
   broadly prior to senders starting to use it exclusively.

Given that, I think that we should either:

1. Require SHA-1 and SHA-256 verification support and recommend
   signatures with SHA-1.

2. Require SHA-1 and SHA-256 verification support and recommend
   (require?) signatures with SHA-256.

3. Require SHA-256 support and forbid SHA-1 in both generation
   and verification.

Option (3) seems like overkill. I don't have a strong opinion
between (1) and (2), but probably lean towards (2) on the grounds
that it's better to use something that we don't know has problems,
even probably irrelevant ones.

-Ekr

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Feb 2006 16:09:49 -0800

> even probably irrelevant ones.

Agreed.  When recipients rely upon DKIM for an assurance of the  
source domain for a message, improving the success rate of phishing  
attacks may make dedicated hardware or distributed botnet computing  
both a practical and relevant means to exploit these weaknesses.

It is also equally important to be concerned about DNS security.   
Executing hundreds of DNS queries in series, dictated by a foreign  
entity, seems insecure.  Yet many are currently suggesting DKIM be  
done in conjunction with this practice.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Feb 2006 16:04:42 -0800

> as the cost to forge a signature with that algorithm is
Hopefully, the presence of a *valid* message signature will be the
input.  I know you meant this, but there has been discussion as to
whether non-verification of the signature needs to be included in the
threats document.
> level of recipient deployment.
The "figuring out" of which algorithm to use is the central problem
here.  There just isn't a good way to do it, which is why my text
suggested the use of two signatures.  The verifier only needs to verify
one of them, and can decide which hash algorithm to use for the
verification early in the receipt of the message.  I'm less concerned
with burdening signers than verifiers.

I agree with your analysis about how much of a problem SHA-1 is for
DKIM.  But as Phill points out, the "marketing" aspect of this is such
that, given all the publicity about SHA-1 breakages, if we continue to
use it some IT manager is likely to say something like, "DKIM is
insecure because it uses SHA-1, so we don't use it."  For much the same
reason, I had interpreted SHA-1 as being "algorithma non grata" for new
protocols in IETF, although that's largely an impression rather than
being based on actual statements on anyone's part.
>    broadly prior to senders starting to use it exclusively.
Agreed.
> even probably irrelevant ones.
(2) works for me.  But I think we still need to point out how to achieve
compatibility with legacy SHA-1 verifiers, by using multiple signatures.

-Jim

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Feb 2006 17:30:11 -0800

> whether non-verification of the signature needs to be included in the

Doh. I meant to write this, but, well, failed.

> with burdening signers than verifiers.

Certainly, I agree that when transitioning from algorithm A
to algorithm B you need to temporarily sign with both A and B.

The question is to what extent we are transitioning from A
to B. E.g., if we do anything to break existing signatures,
then there's less point in running SHA-1 in parallel since
the signatures won't work anyway and we can just tell people
to deploy SHA-256 verification with the new canonicalization
or whatever.

That said, why are you less concerned with signers than verifiers?
RSA signatures are much faster to verify than generate (about 20x)
so even messages destined for a fair number of people tend to
burden the signer more. And, of course, the verification load is
likely to be more spread out....

-Ekr

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Feb 2006 22:58:25 -0800

> to deploy SHA-256 verification with the new canonicalization
I can't think of any reason that we would break existing signatures
without some observable change in the DKIM-Signature header field. 
Either a change in some parameter (such as the change in
canonicalization algorithm names between allman-00 and allman-01) or an
increment in the version number.  I consider such a change equivalent to
a change in the hash algorithm from a compatibility standpoint:  we
could run the old and new versions in parallel as separate signatures.
> likely to be more spread out....
A single message destined for a fair number of people would only be
signed once, since we aren't signing the envelope addresses.  The reason
I'm more sensitive to verification load is the potential make-work
attack from an attacker who generates valid-looking but invalid
signatures (which are effectively free in terms of computation).  This
is described in more detail in section 4.1.6 of the threat document.

-Jim

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Feb 2006 10:01:56 -0800

> could run the old and new versions in parallel as separate signatures.

Totally agree. My point was merely that there's no need to run the
combiatoric explosion of canonicalization and signature algorithm.
When you rev the canonicalization/version number you can rev
the hash algorithm as well--or not. There's no legacy issue for
SHA-1 support with new canonicalization algorithms.

> signed once, since we aren't signing the envelope addresses.

Yes, I know that. That's why I said that *even* messages destined
for a fair number of people....

> The reason

I don't understand why this is a relevant consideration for whether
we *require* signers to do multiple signatures or not at this time.
In order for transitions to work properly, verifiers must be able
to process multiple signatures, so an attacker can exploit this
whatever the behavior of any individual signer.

-Ekr

---

From: Jim Fenton <[email-masked]>
Date: Tue, 28 Feb 2006 11:06:35 -0800

> whatever the behavior of any individual signer.
I don't recall anyone suggesting that we require signers to do multiple
signatures (at least, I wasn't suggesting that).  In any case, I agree
with your statement.

-Jim

---

From: Mark Delany <[email-masked]>
Date: Tue, 28 Feb 2006 19:36:19 +0000

> signatures (at least, I wasn't suggesting that).  In any case, I agree

But surely at some point, if not at the beginning, they will have to,
won't they?

Say, eg, SHA-4096 comes along and is ordained as the preferred hash in
some future DKIM. A signer adopting SHA-4096, will need to continue to
additionally sign with the older hashes as long as they believe some
recipients may not have upgraded to verify SHA-4096.

That comes back to the point that Ned et al made perhaps a week ago,
if we know that transition will occur at some point in the future,
leaving that code unexercised until then is surely a recipe for
disaster.

I'm all for supporting multiple signatures in the first DKIM standard
simply to give us some chance of avoiding that disaster. That way I
can configure a subset of my outbound to generate two signatures using
different hashes, just to catch bugs in the early stages of
deployment.

Mark.