Subject: RE: [ietf-dkim] Supporting alternate algorithms

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 21 Feb 2006 09:17:32 -0800

In that case I would suggest that we make SHA256 a MUST support for
signature verifiers and a SHOULD for signature generators. 

SHA-1 should probably also be a MUST for verifiers and a SHOULD for
signers.

As a practical matter folk are likely to want to do DKIM with hardware
acceleration that only supports SHA-1 for some time to come. I don't
think we can realistically mandate SHA-256 as a MUST.

If implementations are to be genuinely interoperable then something that
calls itself DKIM compliant must implement both hashes.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, February 20, 2006 6:33 PM
> To: Daniel Dreymann
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Supporting alternate algorithms
> 
> 
> While I wouldn't quibble with anyone's position on whether 
> sha-1 is still ok, or whether sha-256 is interestingly 
> stronger, (not being qualified myself), I do think the place 
> from which DKIM ought to accept guidance is the saag.
> 
> The saag minutes [1] from Vancouver contain the following:
> 
>   Security Area Response to Hash Function Breaks
>       Russ said we should "walk, not run."  This is not a problem yet
>       but as attacks are improved it will become a problem.  NIST held
>       a hash workshop.  Conclusions from that workshop include a
>       reminder that SHA-1 will reach end-of-life  for digital 
> signatures
>       by 2010.  Also, we cannot expect any new standardized hash
>       functions before then.  The security ADs have decided 
> that we need
>       to transition to sha-256 now.  There will probably be a later
>       transition to something new after it is developed.  So, we need
>       to become good at transitions as we have at least two.
>       Protocols with active WGs will be analyzed within those WGs;
>       others in SAAG.
> 
>   Directives to WGs/Chairs:
>        Do analysis on every protocol in the WG by IETF 65
>        Start standards work on transition to sha-256, but plan for
>        future transitions.
> 
> So, I'd encourage folks who want to debate algorithm 
> specifics to do so on the saag list, where such discussion is 
> more appropriate and where there is more expertise available. 
> (And so the discussion can be repeated less often:-)
> 
> For DKIM, I think we ought to try to take action as per the 
> above, but, in the knowledge that things can, and do, change, 
> so the more agile we can be, as a group, and in terms of the 
> specs we write, the better.
> 
> If there's an argument that DKIM should not follow saag's 
> line on this, then that of course would be appropriate to 
> discuss, but I find it hard to see what's that different 
> about DKIM in this respect.
> 
> Stephen.
> 
> [1] http://www3.ietf.org/proceedings/05nov/saag.html
> 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://dkim.org/ietf-list-rules.html
> 
> 

_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 21 Feb 2006 14:28:03 -0600

> SHA-1 should probably also be a MUST for verifiers and a SHOULD for

For the record, I'm fine with this.  I "felt a disturbance in the Force" 
so our implementation and library on sourceforge is already capable 
here.  The only assumption I made was that the tag would end up being 
a=rsa-sha256.

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Feb 2006 12:35:23 -0800

Arvel Hathcock wrote:
> For the record, I'm fine with this. 

I don't think I understand what it means for a signer to be required to support 
two different "SHOULD" requirements for the same function.

Hmmm.

Perhaps there is a distinction between saying that the signing implementation
MUST *support* a core set of algorithms, versus that a signer SHOULD *use* one 
of them?

d/
-- 

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

---

From: Ned Freed <[email-masked]>
Date: Tue, 21 Feb 2006 13:32:34 -0800 (PST)

> MUST *support* a core set of algorithms, versus that a signer SHOULD *use* one

There clearly is a distinction, but I don't think that's the problem here. As a
rule I think we should avoid saying something MUST be used no matter what.
We're concerned that implementations be _able_ to interoperate, not with
constraining all forms of operation everywhere to use the same algorithm.

The problem here isn't that someone could configure the use of some random
signature algorithm and still remain compliant, but rather that someone can
write an implementation which supports generation of neither SHA-1 nor SHA-256
signatures and still be compliant. As such, I suggest making support for SHA-256
on generation a MUST and SHA-1 a SHOULD. Both SHA-1 and SHA-256 need to be
a MUST for verifiers. 

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Tue, 21 Feb 2006 16:46:05 -0500

Yeah, me too. Same conclusion, and same assumption.

	Tony Hansen
	[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Feb 2006 14:00:00 -0800

Ned,

> write an implementation which supports generation of neither SHA-1 nor 
> SHA-256 signatures and still be compliant. As such, I suggest making support
> for SHA-256 on generation a MUST and SHA-1 a SHOULD. Both SHA-1 and SHA-256
> need to be a MUST for verifiers.

I am not sure whether your text covers the point I want to pursue, in this note. 
  Since I think it is a core requirement, I want to make this explicit:

A signer needs to have at least one algorithm that I can use that they can be 
positive will supported by *all* validators.

Whether there is only one and whether it is "preferred" are separate issues, to me.

That's why I distinguished between "MUST support" vs. "SHOULD use".

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Feb 2006 15:20:42 -0800

Ned Freed wrote:
 > Exactly so, and given the current hash function situation that algorithm
 > needs
 > to be SHA-256.

Is this really the case, or is SHA-256 a sort of generic placeholder
for "something better than SHA-1"? I haven't paid very much attention
to what the cryptographers have been saying about this, but it doesn't
seem clear to me that SHA-256 has been settled on as The short term
replacement. Or has it?

		Mike

---

From: Ned Freed <[email-masked]>
Date: Tue, 21 Feb 2006 15:22:44 -0800 (PST)

> seem clear to me that SHA-256 has been settled on as The short term

I think it is fairly clear that SHA-256 is shaping up to be the _short_ term
replacement. It may also prove to be the long term replacement, but I wouldn't
bet the farm on it. Whirlpool is the obvious alternative right now, but who
knows what might emerge in the future.

I personally prefer Whirlpool, but I observe very little support for it in IETF
circles.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 21 Feb 2006 14:32:04 -0800 (PST)

> I am not sure whether your text covers the point I want to pursue, in this note.

I believe it does.

> positive will supported by *all* validators.

Exactly so, and given the current hash function situation that algorithm needs
to be SHA-256. This is why I said both generators and verifiers MUST support
it.

However, others have noted that there are sometimes good reasons to use SHA-1 -
hardware accelerator support being the most obvious. This argues for making
SHA-1 a SHOULD for generators, but it has to be a MUST for verifiers so it can
be checked when someone does use it.

I'm personally not a fan of the effort the IETF goes to to provide numerous
alternatives for crypto functions. So specifying things like, I don't know,
Tiger or GOST-MAC or whatever is of no interest to me. That said, I don't think
it is appropriate to enjoin people from specifying such things for use if
there is sufficient support for it.

> That's why I distinguished between "MUST support" vs. "SHOULD use".

THey are indeed distinct, but I think we need to be more concened about what
implementors have to put in their implementations than about how users of those
implementations actually set things up. Of course the universal presence of
support for SHA-256 will make it the perferred algorithm to actually use on the
open Internet, which is as it should be. We could even put in a SHOULD default
to using SHA-256" if that would make folks happier.

				Ned

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Feb 2006 08:59:29 +0100

Ned Freed wrote:
> SHA-256
As my colleague Jim Fenton is fond of saying, I am reticent to impose
restrictions on verifiers.  The issue here is how much they wish to
trust SHA-1, and there's no need for the IETF to dictate to them on this
count, and there should be no need for us to update the document when we
want to pronounce SHA-1 dead.  That to me therefore rates a MAY.  Just
as Phil mentioned in another note, we're pretty close to a green field
here.  Had it been otherwise I might consider a SHOULD.

Eliot

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Feb 2006 08:38:24 -0500

----- Original Message -----
From: "Eliot Lear" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Sent: Wednesday, February 22, 2006 2:59 AM
Subject: Re: [ietf-dkim] Supporting alternate algorithms

> here.  Had it been otherwise I might consider a SHOULD.

Green Fields ... full of mushrooms.

I think this ought to be part of the Migration Planning.  The past research
we done in regards to login/authorization methods, suggest the experts think
SHA1 is good enough for the next X years but that is should it definitely be
part of your planning to switch to sha-256.

In my opinion, lets remove this thorn from the side now for the new
protocol.  Make SHA1 and SHA-256 part of the default signing choices and
that both are required for DKIM support.  The technical recommendation
"should" be:

      You SHOULD use the highest protection you deem necessary for
      the transaction.

The signer could choose to use SHA1 for less-valuable transactions and
SHA256 for others.  Who knows? He might incorporate "enhanced security" into
his cost/business model.

If a wide spread SHA1 hack does come out,  signers will be able to switch to
SHA-256 on a moments notice.

The key is to make sure verifiers are ready for both.

This resolves it IMO.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Feb 2006 09:16:39 -0800

>>here.  The only assumption I made was that the tag would end up being

Just as a practical note, openssl requires -0.98 which gives me a
slight bit of pause given problems in -0.97. Somebody better in
the know can tell me how mature -0.98 is...

		Mike
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ned Freed <[email-masked]>
Date: Wed, 22 Feb 2006 09:24:27 -0800 (PST)

> restrictions on verifiers.

I'm sorry, but it is folly to think you have a choice in the matter. There has
to be at least one mandatory to implement mechanism to insure all
implementations can interoperate. The least we can get away with is a single
common mandatory to implement for both signers and verifiers. But I'm reluctant
to do things this way for a variety of reasons including, but not limited to,
the ability to leverage the installed SHA-1 base.

Another reason for having two mechanisms in there is that it insures some
minimal amount of testing of algorithm ability will occur. In my experience
untested mechanisms are often broken mechanisms.

> The issue here is how much they wish to

As Dave pointed out previously, this discussion continues to confuse
implementation requirements with usage requirements. Nobody is saying that you
have to accept a message signed with SHA-1 now and forever. Rather, what's
being said is that due to huge existing base of optimized and accelerated SHA-1
support out there, those users who want to use SHA-1 should have some assurance
for the time being of their ability to do so.

In particular, a document that says "SHA-1 support MUST be implemented for
verification and SHOULD be an available option for signing" doesn't need to be
revised when we reach the point of wanting to say "SHA-1 MUST NOT be used to
sign messages any longer".

The question of whether or not it is actually OK to make such a change (as
opposed to it being essential) is trickier in that it depends on whether or not
you care about the long-term ability to verify DKIM in old messages. My
personal view is that DKIM is intended to be ephemeral and it is therefore OK
to make such a change. But I don't know if we really have consensus on this
view.

				Ned

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Feb 2006 18:46:50 +0100

Ned Freed wrote:
> implementations can interoperate. 
Most of the time I would buy this Ned, but the ramifications of NOT
interoperating are not at all clear here.  The worst is that you don't
show the message as verified.  And while that is a deployment and not an
implementation consideration, why force people to implement something we
know we're transitioning away from?  It doesn't matter so much today. 
Everyone today is going to implement SHA-1.  But it matters 2 - 3 years
down the road, when that decision shouldn't be forced by the IETF.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ned Freed <[email-masked]>
Date: Wed, 22 Feb 2006 10:05:01 -0800 (PST)

> down the road, when that decision shouldn't be forced by the IETF.

The ramifications of not having a common mandatory to implement hash are going
to be not being able to make it to proposed. Even if we were able to reach
consensus on it in the WG (I for one would strenuously object) I see no chance
whatsoever that it would pass security review.

Feel free to prove me wrong by getting statements to the contrary from the
relevant ADs. Absent that I'll continue to reach this conclusion based on
extensive past experience, which AFAIK is 100% consistent on this point. And I
don't think the argument that DKIM is somehow different than, say, the even
more ephemeral mechanisms used in something like TLS, is going to sway people
to your point of view.

Of course this doesn't mean we couldn't just have SHA-256 as the only MUST. I
think that's a bad idea, but it would probably fly. But you appear to be
arguing that there should be no mandatory to implement at all.

				Ned

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Feb 2006 19:36:25 +0100

> arguing that there should be no mandatory to implement at all.
I could live with a mandatory SHA-256, although Mike Thomas has raised a
real concern about the robustness of the available code base.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Feb 2006 10:44:13 -0800

> real concern about the robustness of the available code base.

this suggests that my odd, alternate proposed language for the signer side needs 
to say something not only about the "efficiency" of SHA-1, but also about its 
existing installed base, ie, ready availability.

d/
-- 

Dave Crocker