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