----- Original Message ----- From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]>
> 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
