[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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