Subject: RE: [ietf-dkim] 1193 considered harmful

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Mar 2006 11:57:57 -0800

I agree, we have already agreed to introduce a new cannonicalization: the
slippery slope argument is not operative.

The slippery slope argument is difficult to distinguish from 'I don't have a
real case to make against this change so I will make an unanswerable
objection based on the possibility of unforseen consequences'. The more
relevant question is whether this commits us to a change that breaks
backwards compatibility, it does not as we have already made this
concession.

We have a good deployed base and I don't want to see that trodden on without
cause. But the consequences of minor treading are not serious. Verifiers are
part of anti-spam infrastructure that is aggressively upgraded at this point
in time. I think that we can manage a transition without creating a long
term maintenance issue. We are not talking about a major impact on already
written code, it is a detail change that does not require major
re-architecting. 

I would have serious issues if we had a major deployed base of verifiers.

I very much prefer the separate hash approach for several reasons:

* It is easier to debug deployments. 
	Unintended modificaiton of the head and body can be distinguished.
	If there are multiple signatures it is possible to see who probably
screwed up

* In a reporting environment the sender can adapt the canonicalization
strategy
	If mail sent to vmail with cannonicalization A is repeatedly
reporting 
	body validation failures try canonicalization B

* It allows for a more flexible software architecture
	Message digests frequently calculated for other purposes can be
reused
	Mailing list signers only need to digest the body once.

* The costs are marginal, at most an extra digest cycle.

With this particular change DKIM would be exactly isomorphic to
Authenticater Sender, the VeriSign domain keyed signed email proposal
(leaving aside the ability to link to certs which is an option/extension
issue). I believe that with this change DKIM has reached a local minima, I
am not aware of other likely slippage.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Mar 2006 17:32:14 -0800

> [mailto:[email-masked]] On Behalf Of Dave Crocker

> Russ Housley wrote:
>   > Not exactly.  I do not want to see backwards 
> compatibility raised as the
> > sole reason for objecting to something.  I offered one way 
> to approach 
> > this.  There are clearly other acceptable ones.
> 
> So incompatibility is somehow a lesser status than any other 
> sort of concern?

Incompatibility is a very serious concern, however at the point that one
incompatible change in a module has been accepted it is a weak argument when
made against a proposal to make another change.

In such circumstances it seems very reasonable to ask for more
justification. 

I think that in this particular case it is clear that we should argue the
case on the merits. As I and others have observed there are very powerful
arguments in favor of this change, I would like to hear if anyone has an
argument against.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Mar 2006 17:36:35 -0800

> [mailto:[email-masked]] On Behalf Of Michael Thomas

> Please. I brought this issue up. It was not the *only* 
> objection, and I *did* bring up an alternate way to solve the 
> problem without breaking backward compatibility, at least 
> until the motivation morphed into something other than the 
> originally stated goal.

Reading your original post I find only one argument against the proposal,
that it is a change.

I note that you also provide an alternative solution that does not involve a
change. It provides some but not all of the advantages of the 1193 proposal
but not all.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Mar 2006 19:46:43 -0800

I raised the issue and got the same response, i.e. agenda denial and refusal
to answer the substantive point. 

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Wednesday, March 22, 2006 7:40 PM
> To: Hallam-Baker, Phillip
> Cc: Russ Housley; [email-masked]; [email-masked]
> Subject: Re: [ietf-dkim] 1193 considered harmful
> 
> Hallam-Baker, Phillip wrote:
> >>Define "needed". If the standard of "needed" is "required 
> to make the 
> >>protocol viable", then this is not "needed". If "needed" means 
> >>"anything we feel like changing, we can change", then the 
> words in the 
> >>charter are meaningless.
> > 
> > 
> > Needed means that the value of making the change is 
> justified by the 
> > cost of making the change.
> > 
> > In this case the cost of the change now is much less than the cost 
> > will be in the future. This particular change was proposed multiple 
> > times during the development of DKIM (I was the proposer). 
> Each time 
> > the pushback was the cost of making the change.
> 
> Really? I don't remember that. In fact, there was no backward 
> compatibility issues at that time because the DKIM-Signature 
> header/hashing was different than the DK signature/hashing. 
> As I remember it, the chosen hash generation was different 
> than both IIM and DK. And here we are two years later, um, 
> rehashing the same decision.
> 
> 		Mike
> 
>