Re: Last Call: <draft-ietf-dkim-rfc4871bis-12.txt> (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/23/11 8:24 AM, John Levine wrote:
In article<4E02EE24.2060708@xxxxxxxxx>  you write:
On 6/22/11 11:14 AM, Dave CROCKER wrote:
Folks,

The bottom line about Doug's note is that the working group extensively
considered the basic issue of multiple From: header fields and Doug is
raising nothing new about the topic.
Dave is quite right.  Doug's purported attack just describes one of
the endless ways that a string of bytes could be not quite a valid
5322 message, which might display in some mail programs in ways that
some people might consider misleading.  If it's a problem at all, it's
not a DKIM problem.
Perhaps you can explain why the motivation stated in RFC4686 includes anti-phishing as DKIM's goal? Why of all the possible headers ONLY the From header field MUST be signed? Why RFC5617 describes the From header field as the Author Author address that is positively confirmed simply with a Valid DKIM signature result? Both RFC4686 and RFC5617 overlooked a rather obvious threat clearly demonstrated by Hector Santos on the DKIM mailing list: Pre-pended singleton header fields.

Neither SMTP nor DKIM check for an invalid number of singleton header fields. These few header fields are limited to one because they are commonly displayed. Multiple occurrence of any of these headers is likely deceptive, especially in DKIM's case. DKIM always selects header fields from the bottom-up, but most sorting and displaying functions go top-down selection.

Complaints from John, Dave, and Barry and others is likely and understandably out of fatigue. They just want the process to be over. We are now hearing there is a vital protocol layering principle at stake which even precludes DKIM from making these checks! Really?

Although DKIM will be securely hashing the headers fields which MUST include the From header, developers are being told they must ignore multiple singleton header fields discovered in the process. It is not their burden! As if securely hashing, fetching any number of public keys, and verifying any number of signatures isn't?

-Doug


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]