[ietf-dkim] Re: 1368 straw-poll

[Paul Hoffman]

At 8:48 AM -0800 2/26/07, Dave Crocker wrote:
>The proposed mechanism incurs an additional lookup for every signed message.

You keep saying this without justifying it. Others have shown it to 
be wrong. Please stop repeating it or support your statement.

>The goal of this mechanism is to deal with a potential danger, 
>during a transition.

That is only one goal. Another goal is to let a sender who wants to 
use a different algorithm *for any reason they wish* to do so. That 
is a requirement for security protocols.

>We can assume that there will, indeed, be transitions.

Yes

>Whether we can assume that there will be danger in using the older 
>algorithm is the question.

Maybe, but Ekr's message brings that into 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.

Simple: we allow signers to sign with multiple algorithms. Therefore 
the transition can last as long as the signer wants. It is possible 
that this might be many years.

>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.)

As Ekr pointed out, it is not necessarily "dangerous" and "safe", but 
"less good" and "better". People use "less good" algorithms during 
transitions until they are sure that swithching completely to 
"better" algorithms will suit their needs, namely that the recipient 
will be able to correctly interpret their signature.

This is *exactly* what is being played out in the PKIX world today 
with the attacks on MD5 and SHA-1.

>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?

That's a very good question, and the unfortunate answer is "not 
much". I might make some sender feel better, but it is not likely to 
help any verifier. That combination usually leads to senders 
misunderstanding the value of the feature and confusion in the 
market. That should give us pause.

The bigger question is, "Given that dkim-base is completely clear 
that a message is validly signed or it is unsigned, what extra value 
to each party is gained from adding signature algorithms to 'I sign 
everything'?". I don't think the sender gets any value because the 
recipient either validates with one of the algorithms (success, no 
SSP needed) or it doesn't. It doesn't help the recipient in the case 
where they can validate one of the signatures. The only possible 
value is when the recipient wants to know why they can't validate, 
and this addition to SSP doesn't tell them anything definitive.

I don't support SSP giving hints or partial information, so I am -1 
on the proposal.

--Paul Hoffman, Director
--Domain Assurance Council