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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Feb 2007 10:25:43 -0800

> [mailto:[email-masked]] 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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Feb 2007 10:46:24 -0800

> [mailto:[email-masked]] On Behalf Of Mark Delany
> Dave Crocker wrote:
> 
> > The proposed mechanism incurs an additional lookup for every signed 
> > message.
> 
> Whatever algorithm policy you embed in a separate SSP can 
> just as easily be embedded in the Selector of the weakened key.

Almost, you still need a means to tell the verifier that there are distinctions between the published keys. In the proposal I am making this is by means of a constraint on the key selectors.

> But maybe that just means I don't get any of the discussion 
> about downgrade attacks or weakened keys needing a separate 
> SSP. As others have said TTL is irrelevant because they are 
> always going to be many orders of magnitude smaller than the 
> response time of human administrators. Heck most 
> administrators haven't even heard of DKIM yet alone the 
> discovery of any algorithmic weakness.

The issue is not the transition at one site, it is the transition for the entire Internet. As it stands I can not start to sign with new algorithm B and advertise a useful policy until every verifier supports B.

> I was under the impression that a separate SSP can only add 
> value for domains *not* verified by the signature.

Policy can only add value for messages that are not verified by an acceptable signature. In this case acceptable meaning 'I trust it' and 'I implement it'.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Feb 2007 11:11:19 -0800

> [mailto:[email-masked]] On Behalf Of Paul Hoffman
 
> At 10:10 AM -0800 2/26/07, Dave Crocker wrote:
> >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.
> 
> Well, at least I have. If a recipient gets a message with a 
> valid signature, they never need to look up an SSP record. 
> That refutes your statement pretty fully, doesn't it?

The argument that was made seemed to be:

1) People will prefer to do a DNS lookup to a signature verification
2) Therefore they will always look up policy first as an optimization
3) Therefore policy requires an extra DNS lookup
4) Therefore policy is a bad thing

So in other words we should not support policy since this would enable people to optimize their systems in ways that would make them less efficient.

Regardless of what the rationale is this has nothing to do with what the policy actually says.

And the argument is bunk anyway. It is very likely that any spam management scheme is going to be doing some form of per message reputation lookup by domain on a per message basis but that is almost certainly going to be to a local resource rather than to the Internet at large.

Any speculation as to the design of such systems or how policy would be involved is futile and out of scope.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Feb 2007 11:18:42 -0800

> > Well, at least I have. If a recipient gets a message with a valid 
> > signature, they never need to look up an SSP record. That 
> refutes your 
> > statement pretty fully, doesn't it?
> 
> I have no idea.
> 
> The discussion is about algorithm transitions.  Those aren't 
> interesting things to talk about unless there is a signature. 
>  My understanding of the current topic is that it pertains to 
> an SSP query that is only worth making when there is a signature.

You thus exclude precisely the two cases at issue here:

1) There is a signature that is not considered strong enough
2) There is a signature that uses an unknown algorithm 

You conflate both these cases with the case that there is no signature at all. 

The difference here is that the policy you appear to propose tells you only when you should expect to find a signature on a message while the policy myself and others want to implement tells you when you should expect to find a signature that is acceptable to you on a message.

> Some of the discussion seems to be about having a signature 
> that is valid but not "strong enough".  That might not be a 
> scenario that you have in mind, but it sure seems to be one 
> that is being discussed.

That is the less problematic case, the more problematic case is there is a signature that is completely bogus which you are unable to detect as bogus.

Under my scheme the verifier can continue to work as if the new signature algorithm never existed. Under your status quo scheme the verifier can be bamboozled when this is avoidable.