I'd say that it would be better to just say that if you sign a
non-compliant 5322 message that its verification is undefined,
and move on. That at least matches reality, and hasn't hurt
anything that I'm aware of.
Except that's not the situation we have here.
a) Author creates a 100% compliant message
b) Signer signs 100% compliant message
c) Bad guy adds an extra header, making it non-compliant, and sends it to
someone
d) Receiver receives it and, uh, well, what?
Nobody has signed a non-compliant message, so while there is nothing wrong
with Mike's advice, it completely misses the point.
As far as I can tell, this problem, detecting header changes, is a
security problem that has never come up before. PGP, S/MIME, and PEM only
protect the body, in some cases by wrapping the entire message as a
message/rfc822 MIME body part and signing that. RFC 2822 and its
predecessors tell you what is a valid message, but say approximately
nothing about invalid messages other than a few historically motivated
notes like bare linefeeds really are invalid. I think I can safely say
that there is no chance at all that Pete Resnick et al. would agree to
change 2822bis to fix holes in DKIM.
I'm scratching my head to see if there is any advice we can offer to make
signing and verification more robust while not changing the behavior of
existing code for normal (for some definition of normal messages).
A) You have to sign either all occurences of a header or none of them, and
a message with some but not all occurences signed fails verification. This
is probably too strong, although I doubt that there are many places in
practice where it would matter.
B) Same as A, but limited to an enumerated set of headers that are
supposed to occur only once.
c) Same as B, but tell signers to use the h= trick to make verification
fail if extra headers show up.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html