On 7/6/11 9:31 AM, Barry Leiba wrote:
I actually like Charles's edits except for one paragraph, and, as a
participant, would be happy to change 8.15 accordingly. The one
problem paragraph is this one:
On Wed, Jul 6, 2011 at 7:17 AM, Charles
Lindsey<chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk> wrote:
...
Recall that, when multiple instances of a given header field are
present, they are signed starting with the last one and working
upwards (section 5.4.2). A variety of attacks taking advantage of
this feature can be envisaged. In some, the attacker is himself the
signer, signing the second of some duplicated field on behalf of his
own domain, whilst hoping that some lenient MUA will display only the
first. In others, a genuine signature from the domain under attack is
obtained by legitimate means, but extra header fields are then added,
either by interception or by replay.
As Pete has pointed out -- and has he's adamant about -- the signer
can't attack... that is, DKIM can't do anything about "attacks" by the
signer. And that's as Charles's text itself points out. So I'd be
happy merging just the last sentence with the next paragraph, and
eliminating the rest:
"A genuine signature from the domain under attack can be obtained by
legitimate means, but extra header fields can then be added, either by
interception or by replay. In this scenario DKIM can aid in
detecting such addition of specific fields in transit. This is done
by having the signer list the field name(s) in the "h=" tag an extra
time [...etc...]"
Barry,
When DKIM signatures serve as a basis for acceptance, the current
verification specification will not prevent deceptive results. This is
especially true for "too big to block" domains that nevertheless
restrict what is allowed in the From header field. Anti-phishing
protections originally sought using DKIM can be lost whenever multiple
From header fields result in a message verified as having valid DKIM
signatures.
While not a threat against encoding, it is a threat against validation
that fails to ensure DKIM results are not deceptive whenever checks for
multiple From header fields do not occur, for example. A requirement
absolutely essential for DKIM based acceptance. After all, verification
handles these headers twice and no other annotation will indicate
whether pre-pended header field checks were made. Without assurance a
pre-pended From header field had not been added, there is no safe method
to incrementally deploy DKIM, as suggested in the introduction.
It is also a mistake to suggest the "h=" tag can protect phished domains
whenever acceptance is based upon a different domain's signature that
does not make use of new recommendations. Nor are results for ADSP
defined either. The phished domain may continue to be phished despite a
signing domain's best efforts, where recipients are at even greater risk
when there is any expectation of DKIM related protections.
It would be neither the signing domain nor SMTP at fault. It would be a
deceptive DKIM verification process. This is not about ensuring all
messages comply with RFC5322. This is about preventing deceptive
results missed in DKIM's original threat analysis.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html