[ietf-dkim] Re: 1368 straw-poll

[Dave Crocker]

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