Julian Mehnle wrote:
Hector Santos wrote:
Julian Mehnle wrote:
The trick is to list From twice in h=. This ensures more From headers
cannot be added without breaking the signature.
Julian, this was explored and it does not matter. You can add N
number of h=from: and N+1 is all that is needed in the security hole.
I don't get what you're saying.
I interpret RFC 4871, section 5.4 (actually, exactly the part you quoted
originally), such that signing a message that has a dingle From field
with h=From:From ensures that adding another From field will break the
signature. If you're saying there is a way to add a second From field a
message thusly signed without breaking the signature, could you please
explain to me how?
You are correct. Adding a second from: to the h= tag:
"h=from:from:.........."
can address this. But no implementation does that. Instead the
ALT-N open source code library counts the 2nd in the verification
process and invalidates the signature.
My earlier response to you got mixed up with SIGNING test cases where
there was multiple 5322.From and multiple from: adding to the h=.
Example:
From: <--- Injected, Replayed and MUA Display
From: <--- satisfy 2rd hash binding
DKIM-Signature: h="from:from:...."
From: <--- satisfy 1rd hash binding and EXPECTED MUA Display
So you have N number of h=from SIGNER binding, and you need N+1 to
exploit it in the VERIFICATION.
Of course, you would have violate 5322 in the first place to have a
2nd bound 5322.From. So no good guy will do this. But bad guys will
see your typical single 5322.From and one from: in the h= tag.
Either way, there is a security issue and a new requirement to secure
it either with your suggestion or changes to the guidelines to check
for this exception.
Obviously, the ease of this exploit is a concern. Any high value
domain mail can now be found and replayed with a phished or spooked
2nd or more 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