Subject: RE: [ietf-dkim] agenda item on upgrading hash algorithms?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 24 Feb 2006 11:52:21 -0800

> [mailto:[email-masked]] On Behalf Of John R Levine

> I don't see a hash upgrade as urgent.  Even as SHA-1 becomes 
> easier to break, it doesn't seem likely that it'll be broken 
> badly enough to make it possible to put fake signatures on 
> messages at high speed.

It is not urgent. But it is a lot easier to do the earlier we do it.

One of the big mistakes we made in HTTP was not rendering HTTP/0.9
obsolete when there were only 10 Web servers using it. Today there are
tens of thousands.

If we make SHA-256 a MUST support for verifiers now we can guarantee
that every significant verifier will support it before the RFC is
published. If we wait the transition will take upwards of three years as
it always does.

The reason people are pushing for SHA-256 now is not because there is a
probable imminent break. It is because we know just how long the process
of switching algorithms takes.

We do know that we will have to do a second change at some point when
SHA-3 is approved. That is a long time off. When it comes we are likely
to be looking at moving away from using RSA at the same time for the
same reasons that NIST deprecates RSA beyond 2048 bits. 

I think that the consenus here is to:

1) Start the SHA-256 transition now, making it a MUST for verifiers,
MUST/SHOULD for signers.

2) Ensure that we are confident that the protocol design will allow an
algorithm transition in 2010 or so.

The only point of contention appears to be over whether we need to
consider support for large key blobs. I say no because I think it most
likely we would move to ECC rather than 4096 bit RSA. Doug argues that
we should change the protocol completely in case we might want to use
very large keys.

I would hope that at the point where we are looking at the algorithm
transition we would also be looking at experience from deploying DNSSEC.
Given how closely DKIM and DNSSEC are bound I think we can punt the
large key issue to that whole discussion.

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

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Feb 2006 15:56:57 -0500

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "John R Levine" <[email-masked]>; "Eliot Lear" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 24, 2006 2:52 PM
Subject: RE: [ietf-dkim] agenda item on upgrading hash algorithms?

> of switching algorithms takes.

I agree.

> 1) Start the SHA-256 transition now, making it a MUST for verifiers,

My only take here is that this MUST/SHOULD for signers will always be tagged
with a basic implementation question of

   "well, which one should I use?"

So I think it should be carefully phrase to say:

    SIGNERS "SHOULD" use the highest form of security first among the
    choices currently available {SHA-1, SHA-256}.  Although it is out
    of the scope of this specification, an SIGNER "MAY" use a
    VERIFIER lookup concept to determine the highest form of
    security it offers.

This helps or resolves both issues and addresses the future, especially the
case if indeed when a method is hacked and DKIM signer wishes to quickly
migrate to a new method as supported by the validators. In my view, it is
almost inevitiable, the signer will need to be a lot smarter than the
documentation calls for. i.e. find out more about the host system it is
about to send a "valuable" mail to.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 24 Feb 2006 13:26:39 -0800

On Feb 24, 2006, at 11:52 AM, Hallam-Baker, Phillip wrote:

>
> We do know that we will have to do a second change at some point  
> when SHA-3 is approved. That is a long time off. When it comes we  
> are likely to be looking at moving away from using RSA at the same  
> time for the same reasons that NIST deprecates RSA beyond 2048 bits.
>
> 1) Start the SHA-256 transition now, making it a MUST for  
> verifiers, MUST/SHOULD for signers.

Agreed.  Hash is not where most of the time is spent, and DKIM should  
be able to afford this algorithm.  Whatever the security group  
decides will likely be a good choice, but this reliance may cause a  
modification prior to final acceptance of the DKIM draft.

> 2) Ensure that we are confident that the protocol design will allow  
> an algorithm transition in 2010 or so.
>
> consider support for large key blobs. I say no because I think it  
> most likely we would move to ECC rather than 4096 bit RSA. Doug  
> argues that we should change the protocol completely in case we  
> might want to use very large keys.

The comment was in regard to extensibility.  Adopting a different  
service other than DNS may be to increase trust, for example.

> I would hope that at the point where we are looking at the  
> algorithm transition we would also be looking at experience from  
> deploying DNSSEC. Given how closely DKIM and DNSSEC are bound I  
> think we can punt the large key issue to that whole discussion.

Agreed.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Sat, 25 Feb 2006 08:13:32 -0800

> about to send a "valuable" mail to.

This discussion, though, all assumes that we're talking about strong
cryptography.

We're not. We're talking about weak authentication, primarily for email
whitelisting. There are so many other trivially exploitable flaws in the
whole DK concept if it were applied to other problem domains  
(phishing, say)
that considering it as anything outside the domain of weak  
authentication
of email originator is going to be unwise.

Given that, even if an algorithm is compromised it is still of value  
if the
cost of faking up a hash drastically exceeds the value of being able to
look signed when you're not. That value is pretty low in any scenario
where the sender and recipient are going to be relying solely on DK.

Given the CPU overhead of SHA-256 is about 50% higher than SHA-1 it
makes more sense for the senders of most email currently to use SHA-1
than SHA-256. That will continue to be true if SHA-1 is "broken" for  
some
definition of the word.

Even if you wildly disagree with all of the above it all remains  
quite true
in the perception of the largest senders of DKIM authenticated email
and you need to bear that in mind.

Cheers,
   Steve

---

From: Eliot Lear <[email-masked]>
Date: Sat, 25 Feb 2006 18:42:18 +0100

Steve Atkins wrote:
> that considering it as anything outside the domain of weak authentication
I don't accept this assumption.  Creating a new weak link in the
architecture would be unwise.  If you are referring to the fact that DNS
itself could be attacked, you're right, it could be.  But there are
standards to deal with that.
> than SHA-256. That will continue to be true if SHA-1 is "broken" for some
> definition of the word.
According to what I've hard so far, nobody is CPU bound in
implementations, so this may not be an issue.
>
> Even if you wildly disagree with all of the above it all remains quite
> true
What I keep in mind is not so much what things look like today, but what
they might look like 2-4 years from now, when Moore's law and many grad
students have had a few more shots at us.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Feb 2006 09:51:45 -0800

> students have had a few more shots at us.

What I am trying to keep in mind is specification language.  What I cannot tell 
from this thread, is what language is being proposed.

d/

-- 

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

---

From: Jon Callas <[email-masked]>
Date: Sat, 25 Feb 2006 13:35:19 -0800

On 25 Feb 2006, at 9:51 AM, Dave Crocker wrote:

> What I am trying to keep in mind is specification language.  What I  
> cannot tell from this thread, is what language is being proposed.
>

The present one, which I'll summarize as MUST accept SHA-1, and  
SHOULD use SHA-256.

I think I'm going to agree with the majority of what Elliot Lear and  
Steve Atkins have said, but put a different slant on it.

I find this all to be exactly why the above proposal is to me the  
right thing. We're doing strong authentication, but for (often) weak  
semantic purposes. The signer is taking all the risk. Remember, the  
signature accepts responsibility for the message. It also means that  
the signer accepts risk for the signature being hacked. If the signer  
accepts the risks of using SHA-1 because of performance or whatever,  
so be it. That's what SHOULD is for.

Of course, the secondary risk is that the receivers will get bogus  
messages. But also of course, they can reject all SHA-1 sigs as  
evidence of a bogus message ipso facto.

Here's the way I see it:

    Le Chiffre: Before I kill you, Mr Bond, let me explain my plan to
    you. Do you see that array of computers on cookie sheets? That
    <dramatic pause> is a SHA-1 collision finder! <evil laugh>

    Bond: What are you going to do with it? Subvert bets at Casino
    Royale?

    Le Chiffre: No, they're using SHA-256, which is beyond even my
    powers to crack. This is -- much more subtle than that. <cackles>
    I am going to forge millions of DKIM messages, send them to
    people all over the world, and then the reputation of the Direct
    Marketing Association -- will -- be -- NOTHING!

    Bond: Oh. Well. That's different. Sign me up.

This is one of the reasons why many people are upset at a light- 
haired Bond, and think new screenwriters are in order.

	Jon

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 25 Feb 2006 22:55:36 +0100

>     Bond: Oh. Well. That's different. Sign me up.

<g>   Be careful with that jokes, otherwise some poor jabber
scribe in Dallas could be forced to note that Bank of America
now tries to figure out the secrets of PGP and S/MIME after
SHA-1 failed miserably in a recent James-Bond episode... ;-)