ietf-dkim
[Top] [All Lists]

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

2006-02-24 15:12:31

----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>

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.

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.

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.

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


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