Re: [ietf-dkim] Issue: Repeated headers
On Wed, 20 Apr 2011 23:15:52 +0100, Barry Leiba barryle...@computer.org wrote: Yes indeed. We discussed lots of wording for all of this, and the one that has got into the document is about the worst. Your objection is noted. Note that I have escalated this to as Issue. DKIM is broken if we do not get this right. This is reopening a closed discussion, and the chair considers that inappropriate and unwarranted at this stage. It has been decided. I appreciate that you disagree with the decision, and that will be noted in the PROTO writeup when I do it. There may be a rough consensus for the present text, but my understanding of the IETF procedures is that rough consensus is always trumped by Hard Technical Facts. And I ASSERT that the following is a Hard Technical Fact: Where a Vewrifier is minimally compliant with the present draft, in particular if it omits any test for repeated headers (there is no REQUIREMENT for such a test), then a phisher can easily devise a message which, in the majority of current MUAs, will be displayed as From: serv...@paypal.co.uk and which will pass through that verifier unscathed. This is true whether or not paypal.co.uk has declared a Discardable ADSP policy and that Verifier implements ADSP. I have described this attack several time on this List, and yet it still works. Hence the present draft can only be described as unfit-for-purpose. -- 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
Re: [ietf-dkim] Issue: Repeated headers
On Tue, 19 Apr 2011 22:37:59 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.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: 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
Re: [ietf-dkim] Issue: Repeated headers
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Monday, April 25, 2011 3:46 AM To: DKIM Subject: Re: [ietf-dkim] Issue: Repeated headers 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. The chair has declared this particular topic closed, so I defer to him about this proposal. My understanding (as a WG chair, though not of this WG) is that the presentation of working group consensus is presumed to have taken technical facts into account, so the assertion of a Hard Technical Fact does not automatically trump working group consensus. Besides, there is no debate about what the attack is. The issue is whether or not this is the right place to make normative assertions about how to deal with it. The text we have now is a compromise between two hard-fought views of the answer to that question. It is a path forward, and (as one of the antagonists of that debate) I think it quite reasonable. 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: [...] Those all look okay to me, and as they're largely editorial I'll include them in the next version unless someone objects. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [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. Your objection is noted. Note that I have escalated this to as Issue. DKIM is broken if we do not get this right. This is reopening a closed discussion, and the chair considers that inappropriate and unwarranted at this stage. It has been decided. I appreciate that you disagree with the decision, and that will be noted in the PROTO writeup when I do it. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Issue: Repeated headers
On Sat, 16 Apr 2011 01:05:02 +0100, Douglas Otis do...@mail-abuse.org wrote: http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-3.8 ,--- DKIM's design is predicated on valid input. Therefore, signers and verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322 http://tools.ietf.org/html/rfc5322], [RFC2045 http://tools.ietf.org/html/rfc2045], and any other relevant message format standards. See Section 8.15 http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-8.15 for additional discussion and references. '--- Should change to: --- DKIM's design is predicated on valid input. Therefore, signers and verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322 http://tools.ietf.org/html/rfc5322], [RFC2045 http://tools.ietf.org/html/rfc2045], and any other relevant message format standards. See Section 8.15 http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-8.15 for additional discussion and references. In addition, verifiers MUST ensure the presence of multiple singleton originating header fields do not provide a valid signature result. Yes indeed. We discussed lots of wording for all of this, and the one that has got into the document is about the worst. It is Absolutely Pointless to check for minor infringements of 5233 et al, and so to say that implementors SHOULD check for some reasonable subset of infringements is ridiculous, unless you spell out what reasonable really implies. Now AFAICS, minor infringements in the format of particular headers etc, naughty as they might be, have no impact on DKIM. The naughtiness will be signed, so you can see whether it was present at signature time, if you happen to care about it. But there is just ONE breach of 5322 (so far as we know) that is serious enough to break DKIM completely. And that is repeated headers that should not be repeated. A number of scams involving repeated From headers have been described, and one can well imagine there may be scams with repeating Subject, Content-Type, Message-ID and whatever else (and if you are going to catch one, then catching the others with the same code has negligible additional cost). So if we are going to have normative language (such as SHOULD or MUST), then let us address it to the known problem, rather than to some vague reasonable test that might lead people to waste time on things that are not broken, and omit the one case that is broken. Moreover, when it comes to a choice between SHOULD and MUST, the narrower the test you are asking for, the easier it is to justify a MUST wording. So there are just two questions to ask: 1. What exactly do we really REALLY want implementors to do in this matter.? 2. Is it to be a SHOULD or a MUST? Note that I have escalated this to as Issue. DKIM is broken if we do not get this right. -- 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
Re: [ietf-dkim] Issue: Repeated headers
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.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. It is Absolutely Pointless to check for minor infringements of 5233 et al, and so to say that implementors SHOULD check for some reasonable subset of infringements is ridiculous, unless you spell out what reasonable really implies. Now AFAICS, minor infringements in the format of particular headers etc, naughty as they might be, have no impact on DKIM. The naughtiness will be signed, so you can see whether it was present at signature time, if you happen to care about it. I believe the added text adequately addresses this problem, especially the new Section 8.15. I also believe that the chair has said we have rough consensus on this point. So if we are going to have normative language (such as SHOULD or MUST), then let us address it to the known problem, rather than to some vague reasonable test that might lead people to waste time on things that are not broken, and omit the one case that is broken. 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. 1. What exactly do we really REALLY want implementors to do in this matter.? I believe Sections 3.8 and 8.15 make this clear to anyone that's designing and implementing software in this area. 2. Is it to be a SHOULD or a MUST? Given the RFC2119 definition, I think we've appropriately settled on SHOULD. I don't want to re-hash all the arguments. What we have is a compromise between two hard-argued positions, and I think reopening it now will just drag everything out even longer. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Repeated headers
On 4/19/11 2:37 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.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. Here is mine. :^) http://mipassoc.org/pipermail/ietf-dkim/2011q2/015838.html -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Repeated headers
I don't want to re-hash all the arguments. What we have is a compromise between two hard-argued positions, and I think reopening it now will just drag everything out even longer. I agree that the current language addresses the issue about as well as it could be addressed, and see no advantage in rearguing it. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Repeated headers
On Apr 19, 2011, at 3:55 PM, John R. Levine wrote: I don't want to re-hash all the arguments. What we have is a compromise between two hard-argued positions, and I think reopening it now will just drag everything out even longer. I agree that the current language addresses the issue about as well as it could be addressed, and see no advantage in rearguing it. +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
