Re: [ietf-dkim] Re: 1368 straw-poll

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
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html