Re: [ietf-dkim] detecting header mutations after signing

> > Sheesh, I think I've answered this at least three times now.
> Well gosh, I sure do appreciate your patience in dealing with the rest 
> of us fools that might not share your view or have something else to 
> offer.
Sorry.  But I could swear we had this exact exchange before.

> > In the
> > absence of a DKIM signature, there is no reason to worry about doubled
> > headers since there is no reason to think one is "real" and the other
> > "fake".  They're only a threat when they provide a way to make a DKIM
> > signed message render differently from what the signer expected.
> But some agents, maybe even many of them, do via some mechanism decide 
> that one is the "real" one and make a filtering decision based on it.  It 
> might be as simple as an MUA electing to render the first one it finds, 
> for some value of "first".
Aha!  We did have this discussion.  I reported that tried a few MUAs and 
found that some MUAs render the first one, some render the last.  Each MUA 
appears to be internally consistent but there's no consistency from one 
MUA to another.
To me this says that at this point nobody's considered doubled headers to 
be other than a bug, since they haven't provided a way to do anything 
antisocial--they don't evade filters and they don't crash MUAs.  It's only 
a threat when, well, you know.
Re Security Considerations, it's better than nothing, but it would be nice 
to put in concrete advice rather than a general warning, i.e., "verifiers 
SHOULD NOT verify a signature on a message that contains a mix of signed 
and unsigned copies of a header that is supposed to occur only once", 
rather than "bad guys can do bad things by adding extra headers to signed 
messages."
I believe the SHOULD NOT plugs the hole without changing DKIM's behavior 
on any valid message, but I want to finish coding it and try it for a 
while to see what else I've missed.
R's,
John

smime.p7s
Description: S/MIME Cryptographic Signature

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