[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave Crocker
The proposed mechanism incurs an additional lookup for every
signed message.
That is completely wrong.
The mechanism has no impact on the number of lookups you need. You can argue
that people will do a policy lookup before they check the signature but 1368
has no effect whatsoever on the benefits of doing so.
The rule remains that if you find a sufficient signature you can assume that
the message is authentic.
If you want to claim that 1368 changes the number of lookups then you have to
explain how this happens and how 1368 changes this.
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.
The problem is that the older algorithm will almost certainly not be so
terrible that a change is absolutely inescapable.
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.
Better would be to consider the reasons why previous transitions have not been
possible.
No Internet protocols have had policy mechanisms and that is the major reason
why almost every protocol has become frozen after a short time.
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.
The transition here is the period of time between the first verifier being
capable of verifying the new algorithm and the last signer using the old
algorithm.
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.)
It need not be dangerous, merely expected to become so in a decade or so. As
stands it would take twenty years or more to perform algorithm transitions with
DKIM policy.
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?
This has no effect on DKIM base, only on SSP which as currently defined is
broken and needs to be suppressed.
If you want to do things faster then quit arguing.
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.
Completely wrong.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html