John Levine wrote:
Unless John, Jon, Dave, and Mike can assure the WG that current
algorithms will always be sufficiently strong, and that a transition
sufficiently swift, ...
Let's say I am a signer, you are a receiver. I publish a policy that
says "don't trust that old fashioned sha256 signature, just the new
rot13 one." What should you do with that policy record? Why should
you do anything other than ignore it because it's stupid?
More generally, I hear an implicit assumption in all of this that
senders know more about crypto than receivers do. Why would that
be so? Why shouldn't receivers use their own best judgement about
what hashes are adequately strong, and why should they believe
statements from random spammers about relative strengths of
crypto algorithms?
Folks,
Before we take a straw poll on solutions, perhaps we should take one on
problems?
The proposed mechanism incurs an additional lookup for every signed message.
The goal of this mechanism is to deal with a potential danger, during a
transition.
We can assume that there will, indeed, be transitions.
Whether we can assume that there will be danger in using the older algorithm
is the question.
1. Given a 35 year history of Internet transitions, it would help to document
previous ones that have a) had this problem, and b) ones that were helped by
this sort of mechanism.
2. Unless I'm missing something pretty basic, the duration of a transition is
the time between the last message is signed with an algorithm and the signer
deletes the key record. For DKIM intended use, I believe this duration will
be in the range of 3-10 days. If I'm wrong, it would help for someone to
explain how.
3. If an older mechanism is somehow "dangerous", then why is the algorithm
still being supported by the sender? (We know it is still supported, because
the sender still publishes a key record for it.)
4. We should also consider the impact of the transition to the mechanism
itself. DKIM is already deployed. Before the SSP work is published, there
will be more deployment. Further, not everyone is going to implement this SSP
mechanism. So, what does it mean to have partial support throughout the DKIM
service?
In other words, we appear to be talking about embedding permanent, per-message
overhead, for a mechanism that is designed to cover an event that has no
precedent in 35 years of Internet history, and to embed it in a system that is
explicitly intended to provide security features that are limited in time and
scope.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html