On 6/23/11 8:24 AM, John Levine wrote:
In article<4E02EE24(_dot_)2060708(_at_)gmail(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf