On Wed, 06 Jul 2011 17:31:47 +0100, Barry Leiba <barryle...@computer.org>
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 <c...@clerew.man.ac.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:
The signer most certainly CAN attack, but what he is attacking is not
DKIM; rather it is the recipient, or Ebay, or lenient MTAs. DKIM is, in
fact, his weapon of attack.
I carefully included two scenarios in my paragraph, which you quote above,
because they are subtly different attacks. The 1st is the more pernicious
IMHO and the hardest to counter, since the 'h=from:from:' defence does not
work. I therefore regard it as ESSENTIAL that our Security Considerations
give warning of that scenario. Moreover, it is also necessary to draw
attention to the 'working upwards' signing order, which is at the heart of
both scenarios, since that might not otherwise be clear to the reader.
I would be happy to reword my paragraph to make it clear that these
attacks are not against DKIM (although that point is also made strongly in
a later paragraph). How about the following?
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). This DKIM feature can be deployed to mount a
variety of attacks against the email system. In some, the attacker is
also 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.
and then my following paragraph as they stand.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
