Re: [ietf-dkim] Introducing myself

On Tue, 31 Oct 2006 06:27:14 -0000, Eliot Lear <lear(_at_)cisco(_dot_)com> 
wrote:

> Hi Charles, and welcome.  I can't answer many of your questions, but I  
> can certainly take a whack at a few.
> > > 3.5  The DKIM-Signature header field
> > Can the various tags appear in this header in any order? OTOH, why is
> > there not an insistence that the b= tag should come last (since it has  
> > to
> > be easily joined to and separated from the rest)?
> I can't speak to anyone's implementation, but general SMTP folding rules  
> apply, no?
Yes, sensible folding would help. But it would make life easier for  
implementors if the b= tag was always last. That is, in any case, where  
most implementors are likely to put it simply because that is easiest, and  
it is also the easiest place to ignore it when a verifier needs to grab  
everything in the header _except_ that bit when constructing its hash.
> > >    l=  Body length count
> > >            INFORMATIVE IMPLEMENTATION WARNING:
> > I am very suspicious of the propriety of suggesting, in any IETF  
> > standard,
> > that it is legitimate to remove text from a message being conveyed
> > (certainly without the consent of the recipient). Surely marking it with
> > blood-red ink, or warnings in 32pt characters is as far as one should  
> > go?
> What if it's executable code inserted by an attacker?
A fair point, but labelling it clearly should surely be enough. One  
application of this tag is apparently for boilerplate added by a mailing  
list expander, and if that boilerplate is there, it is presumably intended  
that people should read it, and the list admin is entitled to be miffed if  
the recipients do not even get to see it.
>
> > >    z=  Copied header fields
> > >        Verifiers MUST NOT use the header field names or copied values
> > >        for checking the signature in any way.  Copied header field
> > >        values are for diagnostic use only.
> > Why ever not? I can think of examples where a verifier might find it
> > exceedingly useful to be aware of the original state of some header  
> > which
> > might have been changed somewhere en route. And what potential
> > interoperability arises if a verifier makes some use of this  
> > information?
> Because z= field does NOT get rendered to the user, but rather the real  
> header fields will.  It makes no sense that the z= field should be  
> verified and the others are not.  Allowing otherwise would provide for a  
> malicious opportunity.
Yes, but it is the policy module of the verifier, rather than the user,  
which might find it useful. Some headers may legitimately get changed en  
route. These should probably not be signed, but knowing what such a header  
originally looked like might enable the policy module to spot some unusual  
situation and work around it. The example I have in mind is the use of  
UTF-8 in headers, being worked on by the ietf-EAI WG, where a message with  
'internationalized' headers will have a special header
    Header-Type: UTF8
If that message has to be downgraded en route, because it meets a legacy  
MTA that does not support UTF8, then that header gets changed to
    Header-Type: Downgraded
If a verifier can detect the change in that header, it can try to  
'upgrade' the message to its original form before checking the signature.  
I am not saying that is the only way that UTF8 headers might be made to  
work with DKIM, but it is certainly one possible approach that should be  
looked at.
> > > 3.6.1  Textual Representation
> > >    h=  Acceptable hash algorithms
> > >        ...  Signers and Verifiers MUST
> > >        support the "sha256" hash algorithm.  Verifiers MUST also  
> > > support
> > >        the "sha1" hash algorithm.
> > Why MUST signers support the "sha256" hash algorithm (clearly, verifiers
> > MUST)? Surely a signer who, as a matter of policy, always chooses to use
> > sha-1 is not obliged to implement something he is never going to use?
> Again, for interoperability.  We picked one.  That was the one.
I think you misunderstand my point. AIUI, a signer is allowed to choose  
either sha-1 or sha-256. So evidently all verifiers MUST be able to accept  
whichever of those turns up.
But if a signer decides "my policy is always to use sha-1" then what is  
the point of saying he MUST include code in his implementation which he is  
never going to use. RFC 2119 says you can only say "MUST" where there is  
the possibility of some interoperability problem or other harm. But in  
this case there would be no way for an outsider with no access to the  
signers machine to be aware that he had omitted that code. Hence the use  
of "MUST" for the signer is meaningless, since violating it produces no  
visible effects.
The same argument applies to the places where it says the signer MUST  
support dns/ext and rsa. In those cases too, it is only the verifier who  
MUST support everything the signer is allowed to send.
> I'm sorry, but I've run out of time and must be on a plane shortly.
Have a good trip!

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html