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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 24 Feb 2006 13:17:25 -0800

I would strongly suggest that we make SHA-256 the MUST on the signer
side for interop and SHA-1 a MAY.

>From a S&M (Should & Must) perspective it is not logical to have a
SHOULD on the signer side. If we are requiring all verifiers to support
SHA-256 there is no logical necessity for SHA-1 support.

In principle I could build a 'zero config' email signer/sender box that
hooks into the infrastructure via DNS SRV and acquires its crypto keys
through XKMS-ACC or similar. I would not want to support SHA1 on that
box if it means an unnecessary configuration parameter.

> -----Original Message-----
> From: Hector Santos [mailto:[email-masked]] 
> Sent: Friday, February 24, 2006 3:57 PM
> To: Hallam-Baker, Phillip; John R Levine; Eliot Lear
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms?
> 
> 
> ----- 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?
> 
> 
> > 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.
> 
> I agree.
> 
> > 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.
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 

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

---

From: "John R Levine" <[email-masked]>
Date: 24 Feb 2006 16:22:03 -0500

> side for interop and SHA-1 a MAY.

Agreed, with a note that if the IESG has a new and improved hash they like
better than SHA-256, we can plug that in instead.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I shook hands with Senators Dole and Inouye," said Tom, disarmingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Feb 2006 21:43:49 +0000

John R Levine wrote:
> Agreed, 

Lovely.

S.

---

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

----- Original Message -----

> I would strongly suggest that we make SHA-256 the MUST on the
> signer side for interop and SHA-1 a MAY.

> From a S&M (Should & Must) perspective it is not logical to have
> a SHOULD on the signer side.

I agree as you state it.  However, I didn't state it that way.

> If we are requiring all verifiers to support SHA-256 there
> is no logical necessity for SHA-1 support.

Not necessarily. I may want to use a smaller transaction security footprint
in less valuable communications, maybe within a social network of vendors or
customers, or list mail!!

But if I want to send a bill or subscription or support renewal email, I may
want to use the highest form of security allowed by the target.

> box if it means an unnecessary configuration parameter.

I understand and I go either way.  I am just trying to make heads and tails
of the current specification and what's currently available for hashing. I
am simply adding a little implementation insight on what it will take for us
to add-value and smarts to it based on the current model drawn on the white
board.

If you crypto experts believe SHA-256 is a short term solution, then the
DKIM designers should have a protocol today that allows for inherent
switching to a newer or higher secured method.  As you said, we know how
long the process of switching algorithms takes and we should not take this
very lightly many of us will not want to go through this process again.

So is this is a big issue, and only you crypto people can answer that, as a
system guys, I prefer a built-in migration/switch mechanism today rather
than to depend on changing code again tomorrow or wait until the IETF
sanctions a new method.

Personally, since there will most likely be an elevated cost of doing
business associated with DKIM certified, signed mail, bad actors will have a
much greater incentive to crack SHA-256 a lot sooner than we might think.

So I am simply suggesting the highest form of security should be used.
Today, that would be SHA-256 with a DKIM specification provision that signer
implementators may use advanced techniques to determine what a target
validation host may have to offer.

I don't think this changes anything that you have said. But it gives
implementators the power to build in the logic of having more secured
methods today with the idea that we will look for compliant validators.

Just look at ESMTP AUTH.  It allows for unlimited hashing methods with the
host system exposing its capabilities at the EHLO response.

All I am asking that we consider this angle more to address the issues you
are concern about when it comes to signed messages.

If people think SHA-256 is vulnerable, then we need to be ready for
additional methods.