> [mailto:[EMAIL PROTECTED] 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
