[ietf-dkim] Base-02 //Deprecated Signature Version & New List

[Douglas Otis]

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