[ietf-dkim] Re: 1368 straw-poll

[Dave Crocker]

Paul Hoffman wrote:
> 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.

Actually, they haven't.  They have suggested an optimization that something 
could be added to the regular key query response, but I still don't understand 
what it is, exactly, or what presumed value-add is supplies.

After all, if there is a key query that returns a successful result, then that 
means that the signer does, in fact, support the algorithm.

But, of course, I've been asking some deeper questions that also aren't 
getting answers...


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

And isn't it nice that DKIM allows that.  So, the proposed mechanism is not 
about that requirement.  It is about something else.


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

These are two of the deeper questions we ought to answer, before polling about 
solutions.


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

Were DKIM intended to have signatures that lasted years, that might make 
sense.  Since it isn't, I am pretty sure it doesn't.


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

Perfection is costly.  Why is this "improvement" worth the cost?


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

ack.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net