Julian Mehnle wrote:
President Obama wrote:
[...]
Funny, but this shows nothing because mipassoc.org resigns messages
(d=mipassoc.org). (Oh, and it even included *two* "From"s in h= on your
message.)
Right. Does this add "signer" reputation weight for the injected
5322.From?
Not good. If mipassoc.org is being vouched by some 3rd party
reputation service. The user sees a signed valid message possibly
vouched by trusted service with a signature hash bound spoofed 5322.From.
I propose the following addition text by adding to 48721bis to address
this serious issue;
Special Consideration for Verifying and Signing From: Header
As an exception, header hash verification MUST be done for all
5322.From fields and not just the last one. Signing MUST be done
for all 5322.From fields found, even though RFC5322 recommends
only one 5322.From should be used. This will mitigate any
replay that prepends a new 5322.From header to a DKIM signature
valid message. Some MUAs have shown to display only the first
5322.From header found.
-1. Why do you insist on changing the hashing semantics to special-case
"From"? Recommending that one more "From" be added to h= (and hashed)
than From headers are initially placed in the message should be enough.
There is no need to change the semantics of the spec.
Not proposing a to change the semantics. But rather to add insight
about the issue so that implementators can deal with it.
For example, when I received the echo back from the list, my MTA
rejected it.
18:46:07 C: MAIL From:<ietf-dkim-bounces(_at_)mipassoc(_dot_)org> SIZE=5329
18:46:07 S: 250 <ietf-dkim-bounces(_at_)mipassoc(_dot_)org>
18:46:07 C: RCPT To:<hsantos(_at_)isdg(_dot_)net>
18:46:08 S: 250 <hsantos(_at_)isdg(_dot_)net>... Recipient ok
18:46:08 C: DATA
18:46:08 S: 354 Start mail input; end with <CRLF>.<CRLF>
18:46:08 ** end of data received. (bytes: 5738)
18:46:08 ** WCX Process: SmtpFilterHookLoader ret: 0
18:46:08 ** Invalid 5322 Message - multiple From: headers not allowed
18:46:08 S: 551 Message Not Accepted by filter.
18:46:10 C: QUIT
18:46:10 S: 221 closing connection
Personally, -1 on suggesting a h=from:from, because you are assuming
that operators are actually defining a h= tag. If its blank, its
falls back to the semantics written - use the LAST header found.
However, if you are suggesting that it needs to be explicitly defined
to mitigate this problem, then the specs needs to be updated to
address the security issues.
The fact, Mipassoc.org, stripped my original header and signed with
the double from: lines, one real, one an injected spoofed, proves
exactly what the problem here is.
I would not be surprised if testing this with gmail.com shows the same
thing which the online gmail MUA will have an indicator:
signed by: some signer domain
but will it display the injected spoofed unbounded 5322.From?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html