Murray S. Kucherawy wrote:
Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to
display the signed header? Are there really MUA's that will display the
unsigned headers *and* assert that it was validated? If so, that's
surely a bug in the implementation of the MUA.
This is a non-issue for DKIM anyway.
-1 Highly disagree.
All of this work is predicated on an email that's properly
formatted, and RFC5322 says a message with multiple From: headers
is malformed. So this is not specifically an attack on DKIM.
-1. It would be protocol flaw to pass the buck to MTA and MUAs when
the issue can be address with the protocol itself.
When BAD GUYS discover that valid signed mail can be replayed with a
spoofed 2nd 5322.FROM, you will become a major problem.
I don't think it's practical in DKIM to enumerate all the ways various
malformations can cause misleading displays in an MUA.
What would be not be practical is to expect existing MTA and MUAs to
compensate for this DKIM security loop hole.
This is about one specific item only - Multiple 5322.From. As a major
MTA discovered, they were required to change their implementation to
add an additional requirement which in effect, enforces only one
5322.From for signature validity. We did the same. We easily confirmed
this with a modified replay.
4871bis has the opportunity NOW to add the design insight now - not
after it is too late and bad guys and other current and future
implementators find out about this and had to opportunity to address
the problem but were DENIED the discovery and opportunity to address it.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html