[ietf-dkim] Re: 1368 straw-poll
dhc at dcrocker.net
Mon Feb 26 08:48:01 PST 2007
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?
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
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
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
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
More information about the ietf-dkim