On Tue, 19 Apr 2011 22:37:59 +0100, Murray S. Kucherawy
<msk(_at_)cloudmark(_dot_)com> wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles
Lindsey
Sent: Tuesday, April 19, 2011 12:56 PM
To: DKIM
Subject: [ietf-dkim] Issue: Repeated headers
Yes indeed. We discussed lots of wording for all of this, and the one
that
has got into the document is about the worst.
Where is your proposed alternate text? Complaining without it isn't
especially helpful during a WGLC.
Well the message I was replying to contained a wording from Doug. But here
is my suggestion for 3.8:
3.8. Input Requirements
DKIM's design is predicated on valid input. Therefore, signers and
verifiers SHOULD (?MUST?) ensure that the messages they are processing
are valid, at least to the extent that no header field occurs more than
once where such is forbidden by [RFC5322], [RFC2045], or any other
relevant message format standards. See Sections 8.14 and 8.15 for
additional discussion and references.
Essentially, that replaces "reasonable steps" by "at least <doing the
duplicate header check>". It also adds a reference to 8.14.
I believe the added text adequately addresses this problem, especially
the new Section 8.15.
There is much duplication and confusion between 8.14.and 8.15 (e.g. the
technique of using "h= ... from:from: ..." is described in both, though it
is only really applicable to 8,15. So here are some proposals:
8.14. Attacks Involving Addition of Header Fields
2nd para, line 5 s/last/first/ (I think that was a typo).
3rd para (describing "h= ... from:from: ...")
At the end, add:
However, this offers no protection if the attacker is also himself
the signer.
Alternatively, delete that 3rd para (since it is duplicated in 8.15) and
substitute:
Note that the technique for using "h= ... from:from: ...", described
in Section 8.15 below, is of no effect in the case of an attacker who
is also himself the signer.
4th para line3 s/forgives malformations/forgives such malformations/
8.15. Malformed Inputs
1st para line 3
s/in a replay attack/in a replay attack or a man-in-the-middle attack/
2nd para line 3
s/but in some cases it might display/it will commonly (?often) display/
3rd para line 1
s/implementers are strongly advised to/implementrors need to/
3rd para line 3
s/Section 3.6 of [RFC5322]/the relevant standards [RFC5322], [RFC2045],
etc. (See Section 3.8)/
(for consistency with 3.8)
3rd para line 4: add "Reply-To:" and "Date:"g to the list of headers
typically displayed (Date: is particular relevant for replay attacks).
We do have normative language, in 3.8. And the text in 8.15 makes it
clear what the attack is, and therefore what the "reasonable" defenses
are.
No, section 8.15 only deals with replay and man-in-the-middle attacks. The
REAL problem is attacks by a phisher who provides perfectly valid
signatures from his own throwaway domain.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)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