Re: [ietf-dkim] 1193 considered harmful

On Mar 23, 2006, at 9:09 AM, Michael Thomas wrote:

> I just realized this morning that this benefit is mostly a mirage:  
> you don't have the public key until you query DNS, and in all  
> likelihood the message is going to be received by the time you get  
> the key back (assuming it's average size). The only way to make  
> this a reliable feature would be to send the key in the mail itself  
> ala IIM.
There could be many more than one signature within a message.  This  
separate hash parameter feature may help to reduce the number of  
these DNS transactions.
> So let me see if I can tally this up:
>
> 1) +/- can determine if body or headers are broken; - because it  
> can be done in a backward compatible fashion.
While yes, those messages sent without this change can be determined  
by the absence of the hash parameter in the signature header.  When  
the hash is included in the signature header, the phase of the  
process that fails validation can be determined.  That clearly seems  
to be a plus.  There is a change in the hash function anyway creating  
_exactly_ the same level of change.  This added benefit of isolating  
the failure should be a major plus.
> 2) +   can determine early on if header signature is valid; weak  
> because you won't ordinarily have the key, and most especially not  
> from malicious domains
This however provides a better clue why these signatures might  
accompany the message.  There will be breakage caused by a list  
service, for example.  This list server may add their signature that  
properly covers the message body after their flattening.
Although perhaps a rat-hole, with significant body alteration, it may  
still be practical to determine whether the initial message headers  
submitted can be verified independent of the body.  This would be  
trusting the list-server process in order to arrive at a partial  
initial submitter assurance.  Perhaps there could be a type of list-*  
headers that used to capture modified headers.

> 3) +   can hash a body once for redistribution; a fairly marginal  
> feature that might help mass mailers, but Moore's law is just as  
> likely to help, um, more.
When signatures arrive on a message from many domains, checking the  
body hash quickly indicates which signature should be checked, as  
those that fail to match (at the various lengths) would be  
fruitless.  The traffic and delays induced by a borage of needless  
signature validations will not greatly change, where the speed of  
light contributes substantially to this overhead not affected by  
shrinking die sizes. : (

> 4) -   breaks backward compatibility
As does the SHA-1 hash change which provide the same level of breakage.


> 5) -   no way for signer to determine when it's safe to not send - 
> allman-01; the longer we wait for the RFC #, the bigger this  
> problem becomes
The SHA-1 hash represents the same issue.  A hash located within the  
signature header also indicates a change in the hash algorithm which  
is no less significant.

> 6) -   canonicalization/hashing agreement is the hardest part of  
> the spec to get right from an interop standpoint.
The body hash being separable from that of a more complex header  
hashing process should improve upon identifying where a problem  
exists.  Locating the problem facilitates maintenance of interoperation.

> So the way I look at it you've got one nice benefit that can be  
> implemented in a backward compatible way, and two benefits that are  
> of fairly marginal utility. The downside is that we get churn in  
> the part of the spec that's hardest to get right, and a not  
> terribly easy way for a signer to know when it's safe to deprecate - 
> allman-01.
It would seem the need to recognize SHA-256 and hash parameters  
within the signature have already caused a need to depreciate the use  
of the draft.  The reason should be rather obvious, as there will be  
messages older versions will be unable to validate.  The SHA-256  
should be enough to tell this older version it is unable to verify  
this newer version.  The inclusion of the hash does _nothing_ to  
alter this.  Inclusion of the hash parameter however helps determine  
why a message has been broken.  If this process is as hard as you  
suggest, this change is even more beneficial.
-Doug

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