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