ietf-dkim
[Top] [All Lists]

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

2010-10-07 19:29:01
On 10/07/2010 05:01 PM, John R. Levine wrote:
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.

You're right, it does miss the point. What I'm trying to get my
head around is whether this is a real problem in the real world.
Any reasonable spam filter would notice evil double From:'s in
a New York minute, so I can't get particularly worked up about
this being some sort of existential threat. Can someone come
up with a scenario where this really could be evil and isn't
trivially fixed by... making spam filters insist that they're
really receiving valid 5322 as one of their rules?

Mike, I only have vague recollection of the h= trick anymore...


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

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

<Prev in Thread] Current Thread [Next in Thread>