On Jun 25, 2006, at 9:40 AM, Paul Hoffman wrote:
At 5:46 AM -0700 6/25/06, Douglas Otis wrote:
This next I-D offers a much simpler solution from the prior
suggestion.
No, it doesn't; it is more complex.
Rather than marking the 'v=' revision or using the 'n=' parameter,
this uses a 'c=' parameter to both mark the signature specifics as
"deprecated" by the signing domain and to qualify the required
concurrent non-deprecated signature specifics. This approach
counters objections of modifying existing parameters. In that sense,
this is simpler.
Full upgrade of SMTP will require years. How does this provision
accommodate this possible need?
Making absurd statements does not make the WG want to revisit the
problem. There is no need to "upgrade SMTP" in the case of an
algorithm transition for some DKIM implementations.
Once DKIM becomes entrenched, it will take years before an "upgrade"
of SMTP servers incorporating DKIM become fully incorporated, in
response to an intermittent problem. Until it becomes practical to
obsolete a problematic signature, there does not appear be a means
for preventing a "downgrade" attack. The current draft ignores
"deprecated" signatures which effectively treats these signatures as
"obsolete." With the current draft, there is no difference between
"deprecated" and "obsolete". Until obsoleted by the verifier,
deprecated status is best established by the signer. Implementing
the present draft as written imposes an abrupt reduction of
protection during what is likely a lengthy transitional phase. When
the problem is intermittent, this approach is detrimental from a
security standpoint.
This is a security related work group.
Exactly. In a security working group, there needs to be a consensus
about the threat model for the use case of the protocol. This WG
has agreed on the threat model, and has designed the protocol
around that threat model. No analysis of the protocol has shown
that the proposed protocol does not match the agreed-to threat model.
The threat is anything related to DKIM. The question is about the
specifics of signaling the status of the signing domain to preclude
the "downgrade" scenario. Currently none exist. Abrupt obsolescence
of a commonly used DKIM signature is sure to cause havoc. Until then
there is little available to curtail an intermittent problem.
The fact that one person disagrees with the agreed-to threat model,
and repeatedly tries to get people interested in his threat model,
is bothersome but irrelevant.
This is not about a specific threat, but a general one. The current
draft deals with change in an abrupt, disruptive, and ultimately
dangerous fashion. Deprecated is not the same as obsolete except as
defined in the current base draft.
It is also worth noting that this part of the threat model
(algorithm transition) agreed to by this working group is the same
as the threat model used in other IETF security protocols.
Am I right about the possible problem ahead with a transition?
It is not a question of right or wrong; it is a question of
perceived threats. Yours differs from the rest of the working
group, and from those of the people who designed most (all?) other
significant security protocols.
This does not speak to the specifics, and there is no desire to
include past efforts and attempts to decide what is relevant. Are
you suggesting that it is okay that there is no signaling as a means
to prevent a downgrade attack?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html