Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On Fri, 15 Oct 2010 15:48:05 +0100, Ian Eiloart i...@sussex.ac.uk wrote: Here's a more interesting attack: Compose an email apparently from eBay, and send it to yourself. Get a valid DKIM signature, then add a From: header containing an eBay address, and use the replay to send that message to third parties. Now, your email will be displayed to (some) recipients as an authenticated email from eBay. Note, the problem is that the MUA is saying the message is Authenticated, but the user is doing reputation assignment based on the (incorrectly) displayed eBay address. Yes, that is more like the attacks that I have been worrying about. But I don't see what you gain by be sending it to yourself. Is that supposed to cause it to pick up some signature on the way? If so, then it certainly won't pick up an ebay signature (though it might be a useful technique if it was Yahoo rather than Ebay you sere trying to attack). But yes, getting a valid signature on it (even the phisher's own signature) is sufficient to prevent any ADSP lookup happening, and the main aim is to avoid getting caught by ebay's 'discardable'. Actually, I'm not sure this is different from just sending email with a spoofed From: header, though the dual header attack might be more useful to a phisher who has access to a system which, for example, won't sign spoofed headers. I would think any competent phisher can find a system to generate whatever he want to generate. But a simple (unsigned) message with a spoofed From: header will get trapped by an ADSP 'discardable' (modulo the problem that ADSP doesn't actually specify which of several From: headers to look at, though most ADSP implementations will likely just look at the first). -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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: 4871bis-02 - Section 8.14 comments
On Fri, 15 Oct 2010 17:47:24 +0100, Jim Fenton fen...@cisco.com wrote: On 10/15/10 6:06 AM, Charles Lindsey wrote: I don't quite see what an attacker can usefully do by modifying messages in transit. If they message was already signed (say by ebay), then the attacker must somehow get ebay to sign a message with a useful (to him) text in its body. So what is the benefit to him of making it appear From: someone who is not Ebay (except maybe to ensure that replies get sent to him - since I assume that MUAs that only display the first header will also Reply-To that header)? An attacker could compose a message from some other domain with a good reputation, and add a From header indicating it's really authored by someone at a different domain (say by ebay). Even if ebay has an ADSP record, it's possible that the invisible (originally) From address would be used to in the author signature check, which would pass. Exactly so, but that does not involve any modifying messages in transit, and people seem to be fixated on modifying in transit and on replay attacks, whereas the nastiest scams do not, AFAICS, involve either of those. That was why I asked the question, and I have not seen a really satisfactory answer to it yet. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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: 4871bis-02 - Section 8.14 comments
On Wed, 13 Oct 2010 18:13:43 +0100, Jim Fenton fen...@cisco.com wrote: My inclination is that the spec should say something like: - The verifier SHOULD consider the signature invalid if a signed header field occurs an inappropriate number of times in the message header according to section 3.6 of RFC 5322. - The verifier MAY consider the signature invalid if it detects other message syntax violations of RFC 5322. - (??) The verifier SHOULD consider the signature invalid if the List-Id header field is signed and occurs more than once in violation of RFC 2919. I think the first SHOULD needs to be a MUST (especially as it is a fairly simple test to implement). The MAY is fine. The second SHOULD is fine, except that it should be a blanket coverage of all other standards that define header fields limited to one occurrence. We can't expect implementers to keep up-to-date with EVERY such standard, but they should try to do as much as they can. If SHOULD is too strong for that sort of approach, then I would make it a MAY with an encouragement do you as much as they can. Obvious candidates are the List-* headers and RFC204[56]. The last provision worries me a bit because it opens the door to other specifications that define header fields. On the other hand, I can picture an attack involving insertion of a bogus List-Id header field in order to influence the handling of the message. See above. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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: 4871bis-02 - Section 8.14 comments
On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton fen...@cisco.com wrote: Here's some text I propose for section 8.14, in place of the current text. Bear in mind that this is in the context of the Security Considerations section of the spec, so it is really a discussion of the threat and how it is dealt with, rather than normative text. OK, we're gradually moving towards an acceptable text, but we're not there yet. ... Most of this is good advice, but section 5.3 is in the context of section 5, Signer Actions, and is therefore the wrong place to add normative language for verifiers. So I have added a new section 6.1.1 ... +1 8.14. Attacks Involving Addition of Header Fields Many email implementations do not strictly enforce the message syntax specified in [RFC5322]. One potentially exploitable consequence of this is that an attacker who is capable of modifying a message in transit could insert additional header fields that, if properly placed, could be rendered to the recipient in preference to the originally signed header fields. I don't quite see what an attacker can usefully do by modifying messages in transit. If they message was already signed (say by ebay), then the attacker must somehow get ebay to sign a message with a useful (to him) text in its body. So what is the benefit to him of making it appear From: someone who is not Ebay (except maybe to ensure that replies get sent to him - since I assume that MUAs that only display the first header will also Reply-To that header)? So I think there is a wide range of possible attacks involving duplicated headers, and the text needs to be general enough to cover them. According to [RFC5322] ... signed header fields occurs. Multiple occurrences ... as discussed in Section 3.5. Suggested update to paragraph 2 of section 5.3: Similarly, a message not compliant with [RFC5322], [RFC2045], and [RFC2047] can be subject to attempts by intermediaries to correct or interpret such content. See the Section 8 of [RFC4409] for examples of changes that are commonly made. Such corrections may break DKIM signatures or have other undesirable effects. Therefore, a DKIM signer SHOULD confirm that a message is compliant with those specifications prior to processing. /t +1 Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.): 6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. I have a problem with meticulously validate. That is so hard to do that most implepemters will take advantage of that SHOULD and omit the tests. Much better to specify a less meticulous validation (header counting for example) and then elevate that SHOULD to a MUST. Here is an alternative text that I published on Oct 6th (and on which nobody commented). It is intended to go in section 6.1.1, presumably after the paragraph beginning If the h= tag ...: If the h= tag includes any header field for which, according to [RFC5322], the maximum number within the header section is limited to 1, and if more than 1 occurrence of that header field is present in the message, the verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (multiple occurrences of XXX header field). Moreover, it SHOULD so treat any header field defined in any other standards track document to have a maximum occurrence of 1. If you think that is a bit too vicious, here is a slightly more permnissive version: If the h= tag includes any header field for which, according to [RFC5322], the maximum number within the header section is limited to 1, and if the number of occurrences of that header field present in the message exceeds its number of occurrences in the h= tag, ... -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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: 4871bis-02 - Section 8.14 comments
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, October 15, 2010 9:06 AM To: DKIM Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton fen...@cisco.com wrote: Here's some text I propose for section 8.14, in place of the current text. Bear in mind that this is in the context of the Security Considerations section of the spec, so it is really a discussion of the threat and how it is dealt with, rather than normative text. OK, we're gradually moving towards an acceptable text, but we're not there yet. ... Most of this is good advice, but section 5.3 is in the context of section 5, Signer Actions, and is therefore the wrong place to add normative language for verifiers. So I have added a new section 6.1.1 ... +1 8.14. Attacks Involving Addition of Header Fields Many email implementations do not strictly enforce the message syntax specified in [RFC5322]. One potentially exploitable consequence of this is that an attacker who is capable of modifying a message in transit could insert additional header fields that, if properly placed, could be rendered to the recipient in preference to the originally signed header fields. I don't quite see what an attacker can usefully do by modifying messages in transit. If they message was already signed (say by ebay), then the attacker must somehow get ebay to sign a message with a useful (to him) text in its body. So what is the benefit to him of making it appear From: someone who is not Ebay (except maybe to ensure that replies get sent to him - since I assume that MUAs that only display the first header will also Reply-To that header)? The particular danger that comes to my mind would be where the signing domain uses l= (yes, I know there is a warning against doing this why don't we just deprecate l=?). If evil ne'er-do-well can get a short, somewhat generic signed email from a low level person at an organization then they can potentially leverage this with the multiple headers to generate a spear phishing attack. I have not trod to far down this path to construct a proof of concept but a google for DKIM + l= yielded examples (Assuming you are willing to wade through a bunch of results) of domains using l=, most likely out of ignorance (a fertile breeding ground for abuse). Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote: why don't we just deprecate l=? Yes. Please. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
In article 201010151013.26823.ietf-d...@kitterman.com you write: On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote: why don't we just deprecate l=? Yes. Please. Agreed. Has anyone ever found it useful for its nominal purpose of messages transiting MLMs? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 15/Oct/10 17:13, John Levine wrote: In article201010151013.26823.ietf-d...@kitterman.com you write: On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote: why don't we just deprecate l=? Yes. Please. Agreed. Has anyone ever found it useful for its nominal purpose of messages transiting MLMs? For me, it works as advertised: I can verify my own messages when they come back from a list that just adds footers. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/15/10 6:06 AM, Charles Lindsey wrote: On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fentonfen...@cisco.com wrote: 8.14. Attacks Involving Addition of Header Fields Many email implementations do not strictly enforce the message syntax specified in [RFC5322]. One potentially exploitable consequence of this is that an attacker who is capable of modifying a message in transit could insert additional header fields that, if properly placed, could be rendered to the recipient in preference to the originally signed header fields. I don't quite see what an attacker can usefully do by modifying messages in transit. If they message was already signed (say by ebay), then the attacker must somehow get ebay to sign a message with a useful (to him) text in its body. So what is the benefit to him of making it appear From: someone who is not Ebay (except maybe to ensure that replies get sent to him - since I assume that MUAs that only display the first header will also Reply-To that header)? An attacker could compose a message from some other domain with a good reputation, and add a From header indicating it's really authored by someone at a different domain (say by ebay). Even if ebay has an ADSP record, it's possible that the invisible (originally) From address would be used to in the author signature check, which would pass. I'm also concerned about other header fields, like Subject, where a one-line spam could be substituted as the visible subject line for a signed message. So I think there is a wide range of possible attacks involving duplicated headers, and the text needs to be general enough to cover them. Agree. Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.): 6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. I have a problem with meticulously validate. That is so hard to do that most implepemters will take advantage of that SHOULD and omit the tests. Much better to specify a less meticulous validation (header counting for example) and then elevate that SHOULD to a MUST. We can drop the meticulously part. It was put there for consistency with the validation of the signature header field (current section 6.1.1) but I agree, probably isn't a practical requirement. Here is an alternative text that I published on Oct 6th (and on which nobody commented). It is intended to go in section 6.1.1, presumably after the paragraph beginning If the h= tag ...: If the h= tag includes any header field for which, according to [RFC5322], the maximum number within the header section is limited to 1, and if more than 1 occurrence of that header field is present in the message, the verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (multiple occurrences of XXX header field). Moreover, it SHOULD so treat any header field defined in any other standards track document to have a maximum occurrence of 1. If you think that is a bit too vicious, here is a slightly more permnissive version: If the h= tag includes any header field for which, according to [RFC5322], the maximum number within the header section is limited to 1, and if the number of occurrences of that header field present in the message exceeds its number of occurrences in the h= tag, ... The header field limitations are more complex than that (see Resent-Sender). I prefer to more simply refer to the appropriate section of RFC 5322 and say that it must be adhered to. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Friday, October 15, 2010 2:13 AM To: Barry Leiba Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments Because of the SHOULD, existing verifiers can still be considered compliant. Thus, it may still make sense for a signer to still put h=from:from. Why did Jim remove that advice? It's a specific example of a more general statement, and the general statement is still there in what Jim said. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/15/10 2:12 AM, Alessandro Vesely wrote: On 14/Oct/10 20:40, Barry Leiba wrote: 6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. -1 If we go for changing the protocol in order to avoid the exploit, we should explicitly enumerate the header fields whose duplication verifiers MUST check. SHOULD meticulously validate + MUST return PERMFAIL make for a fuzzy protocol. I think this is clear in Jim's text, and not contradictory or fuzzy at all. They SHOULD check. If they check and the message violates the checks, they MUST return a PERMFAIL. Where's the contradiction or confusion? Fuzziness stems from the fact that a signature on a given message may either verify or not depending on how meticulously the verifier interprets that SHOULD. The MUST immediately following it is deceptive because it conveys the false impression that a signature is REQUIRED to fail in case a particular header field is added after signing. Because of the SHOULD, existing verifiers can still be considered compliant. Thus, it may still make sense for a signer to still put h=from:from. Why did Jim remove that advice? I wanted it to be clear that it's the verifier's job to detect the duplication, not the signer's job to work around the problem. Recall that SHOULD means, roughly Do it unless you have a valid reason not to, and have considered the implications. Besides, as Mark Delany said yesterday, having to do h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id strikes me as an ugly hack. The spec should also state whether duplicated fields invalidate a signature even when they are duly signed. It does. A message that has two From lines, for example, is in violation of RFC 5322. It makes no difference whether it's signed or not. RFC 5322 (and the other specs) doesn't know about the signature and doesn't care, and anything that checks compliance with it doesn't care either. MUAs often disallow writing a From with multiple mailboxes, thus a sender may happen to end up with two From fields after hacking in an attempt to recognize authorship to a second mailbox. Are you saying that there are MUAs that disallow a From: with multiple addresses, but support the addition of multiple From: header fields? If so, I hope it's not a popular MUA that's doing this. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 15/Oct/10 18:59, Jim Fenton wrote: On 10/15/10 2:12 AM, Alessandro Vesely wrote: Fuzziness stems from the fact that a signature on a given message may either verify or not depending on how meticulously the verifier interprets that SHOULD. The MUST immediately following it is deceptive because it conveys the false impression that a signature is REQUIRED to fail in case a particular header field is added after signing. Because of the SHOULD, existing verifiers can still be considered compliant. Thus, it may still make sense for a signer to still put h=from:from. Why did Jim remove that advice? I wanted it to be clear that it's the verifier's job to detect the duplication, not the signer's job to work around the problem. Recall that SHOULD means, roughly Do it unless you have a valid reason not to, and have considered the implications. The implications are that instead of having a signature that is either valid or not we'll have signatures that verify according to a variable percentage of existing verifiers, as it is for virus detection. Why not mandate to fail verification if the signed body contains a virus? To clarify, I'm not against changing DKIM. However, if we do, we better integrate the change in the original design. First of all, it should be in section 5.4. Second, it has to be an explicit list of header fields, rather than generic references to RFC 5322, RFC 2919, etcetera. Third, the spec should state that any repetition of such fields in the h tag, e.g. h=from:to:from:to, has to be regarded as a backward compatible guard, and new implementations must discard duplicated names retaining their first occurrence only. Then, it can derive the implication that signers cannot produce a valid signature of a message whose header actually contains multiple instances of any listed field... Lots of work and some semantic change... Besides, as Mark Delany said yesterday, having to do h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id strikes me as an ugly hack. But then the whole DKIM-Signature is an ugly hack :-) MUAs often disallow writing a From with multiple mailboxes, thus a sender may happen to end up with two From fields after hacking in an attempt to recognize authorship to a second mailbox. Are you saying that there are MUAs that disallow a From: with multiple addresses, but support the addition of multiple From: header fields? If so, I hope it's not a popular MUA that's doing this. One can always find ways or extensions to add /any/ header field more easily than for modifying existing ones. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 14/Oct/10 00:22, Jim Fenton wrote: Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.): 6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. -1 If we go for changing the protocol in order to avoid the exploit, we should explicitly enumerate the header fields whose duplication verifiers MUST check. SHOULD meticulously validate + MUST return PERMFAIL make for a fuzzy protocol. The spec should also state whether duplicated fields invalidate a signature even when they are duly signed. Finally, it does make sense to duplicate fields in h= as stated in -02's 8.14, because that's the only way to guard against the exploit in case the destination's verifier is coded according to the previous protocol version. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 12/Oct/10 17:47, Barry Leiba wrote: 3) Philosophical conflictive parenthetical sentence: (This can also be taken as a demonstration that DKIM is not designed to support author validation.) Yeh, that's the only part I agree on (though not with the reasoning that follows). I'm ambivalent about having that parenthetical statement in there. I'd like to see some consensus about whether to leave it or keep it. +1 for leaving it, it is just distracting in that context. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
3) Philosophical conflictive parenthetical sentence: (This can also be taken as a demonstration that DKIM is not designed to support author validation.) Yeh, that's the only part I agree on (though not with the reasoning that follows). I'm ambivalent about having that parenthetical statement in there. I'd like to see some consensus about whether to leave it or keep it. +1 for leaving it, it is just distracting in that context. Clarifying an error I made in the original message: it should say I'd like to see some consensus about whether to REMOVE it or keep it. And it looks like Alessandro is on the side of removing (leaving) it. Sorry for the confusing typo. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. -1 If we go for changing the protocol in order to avoid the exploit, we should explicitly enumerate the header fields whose duplication verifiers MUST check. SHOULD meticulously validate + MUST return PERMFAIL make for a fuzzy protocol. I think this is clear in Jim's text, and not contradictory or fuzzy at all. They SHOULD check. If they check and the message violates the checks, they MUST return a PERMFAIL. Where's the contradiction or confusion? Is this, perhaps, an issue that's confusing to non-native English speakers? If so, we should make sure we take that into account in how we phrase it. The spec should also state whether duplicated fields invalidate a signature even when they are duly signed. It does. A message that has two From lines, for example, is in violation of RFC 5322. It makes no difference whether it's signed or not. RFC 5322 (and the other specs) doesn't know about the signature and doesn't care, and anything that checks compliance with it doesn't care either. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
Subject: Buy fake watches at fakewatch.example.com! Will some clients display the second subject line? I suspect some will. Do we need to recommend that signers also add a protective second subject: to their h= value? Or do we need to require that verifiers make sure that any header fields that are signed and aren't supposed to be duplicated, aren't? I'm not sure, but right now I'm leaning toward the latter. I went through pretty much the same thought process and came to the same conclusion. It seems to me that there are some fairly cheap extra checks tht a verifier can make that will defend against malformed mail that would be likely to display confusingly in an MUA. Yes, it's technically not DKIM's job to verifiy 5322 conformance of incoming mail, but as Barry noted, it's not anyone else's job, either. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/13/10 8:04 AM, John Levine wrote: Subject: Buy fake watches at fakewatch.example.com! Will some clients display the second subject line? I suspect some will. Do we need to recommend that signers also add a protective second subject: to their h= value? Or do we need to require that verifiers make sure that any header fields that are signed and aren't supposed to be duplicated, aren't? I'm not sure, but right now I'm leaning toward the latter. I went through pretty much the same thought process and came to the same conclusion. It seems to me that there are some fairly cheap extra checks tht a verifier can make that will defend against malformed mail that would be likely to display confusingly in an MUA. Yes, it's technically not DKIM's job to verifiy 5322 conformance of incoming mail, but as Barry noted, it's not anyone else's job, either. My inclination is that the spec should say something like: - The verifier SHOULD consider the signature invalid if a signed header field occurs an inappropriate number of times in the message header according to section 3.6 of RFC 5322. - The verifier MAY consider the signature invalid if it detects other message syntax violations of RFC 5322. - (??) The verifier SHOULD consider the signature invalid if the List-Id header field is signed and occurs more than once in violation of RFC 2919. The last provision worries me a bit because it opens the door to other specifications that define header fields. On the other hand, I can picture an attack involving insertion of a bogus List-Id header field in order to influence the handling of the message. The overall philosophy here is to strongly encourage verifiers to watch for this attack while not making current DKIM implementations obsolete, but without requiring essentially open-ended syntax checking of message by DKIM verifiers. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
+1. Barry, as the original issue submitter and I only provided suggested text to jump start WG input with better text, I am very happy with Jim Fenton's text. It doesn't lay blame and straight to the key points. Folks, this is really a simple solution and in my opinion, DKIM can gain from this issue resolution with a powerful new marketing angle in how DKIM raises the bar for Email Compliancy to further protect against current spoofing and phishing of user mail agents than any other email technology since the annals of electronic mail. This is something that I can add to my technical marketing of DKIM for our customers. It provides a payoff for customers to support DKIM and to upgrade their software to further harden it. A win win for all. Thanks Jim for stepping in and providing excellent text I hope everyone can compromise and agree with. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Jim Fenton wrote: On 10/12/10 7:58 PM, Murray S. Kucherawy wrote: You're right, it's not limited to From:, but 8.14 only uses that as an example. It does also contain a more general description of the issue. If the diff from RFC4871 doesn't say the right thing, can you propose alternate text? Here's some text I propose for section 8.14, in place of the current text. Bear in mind that this is in the context of the Security Considerations section of the spec, so it is really a discussion of the threat and how it is dealt with, rather than normative text. I went back and looked at the corrected text Dave Crocker sent for section 5.3. Most of this is good advice, but section 5.3 is in the context of section 5, Signer Actions, and is therefore the wrong place to add normative language for verifiers. So I have added a new section 6.1.1 that adds the requirement for message syntax checking to verifiers. I'm open to suggestions on the strength of the verification requirement; I made it a SHOULD, but perhaps it should be a MUST. I'm reluctant, however, to point at three sizable specifications and say that the verifier MUST check everything; that sounds like an unverifiable requirement. I'm open to ideas. = 8.14. Attacks Involving Addition of Header Fields Many email implementations do not strictly enforce the message syntax specified in [RFC5322]. One potentially exploitable consequence of this is that an attacker who is capable of modifying a message in transit could insert additional header fields that, if properly placed, could be rendered to the recipient in preference to the originally signed header fields. According to [RFC5322] section 3.6, certain header fields, including From and Subject, MUST appear a maximum of once per message. It is therefore possible for a verifier to detect the insertion and as discussed in Section 6.1.2, DKIM verifiers are expected to return a verification failure when the invalid insertion of signed header fields occurs. Multiple occurrences of other header fields are not similarly constrained. Should the signer wish to render a signature invalid if a particular header field is added, the signer has the option of listing the name of that header field (or an additional instance of it) in the h= value as discussed in Section 3.5. = Suggested update to paragraph 2 of section 5.3: Similarly, a message not compliant with [RFC5322], [RFC2045], and [RFC2047] can be subject to attempts by intermediaries to correct or interpret such content. See the Section 8 of [RFC4409] for examples of changes that are commonly made. Such corrections may break DKIM signatures or have other undesirable effects. Therefore, a DKIM signer SHOULD confirm that a message is compliant with those specifications prior to processing. /t = Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.): 6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
-Original Message- From: Jim Fenton [mailto:fen...@cisco.com] Sent: Wednesday, October 13, 2010 3:22 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments Here's some text I propose for section 8.14, in place of the current text. Bear in mind that this is in the context of the Security Considerations section of the spec, so it is really a discussion of the threat and how it is dealt with, rather than normative text. [...] It seems to me you're saying the same thing bis-02 is saying, but with perhaps less terse language. In particular, bis-02 says SHOULD NOT validate something that's malformed, while you're saying SHOULD validate format before processing. Those sound the same to me, but if people like this expression of it better then I'm also happy with it. You're right about splitting the verifier advice out to Section 6. Good point. And your rewrite of 8.14 is cleaner than what we have now. I agree that using a MUST is too strong; not only is it a very hard requirement to achieve but it wanders into the realm of making DKIM modules responsible for 5322 enforcement, and I don't like that at all. Thus I think SHOULD is appropriate, and MAY is even more so (but I'll settle for the former). A minor point: I would like your proposed 5.3 and 6.1.1 (should that be 6.1.2?) text to contain something like See Section 8.14 for further discussion. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/13/10 4:32 PM, Murray S. Kucherawy wrote: It seems to me you're saying the same thing bis-02 is saying, but with perhaps less terse language. In particular, bis-02 says SHOULD NOT validate something that's malformed, while you're saying SHOULD validate format before processing. Those sound the same to me, but if people like this expression of it better then I'm also happy with it. Correct; I had problems with the wording and organization but not the intent. You're right about splitting the verifier advice out to Section 6. Good point. And your rewrite of 8.14 is cleaner than what we have now. I agree that using a MUST is too strong; not only is it a very hard requirement to achieve but it wanders into the realm of making DKIM modules responsible for 5322 enforcement, and I don't like that at all. Thus I think SHOULD is appropriate, and MAY is even more so (but I'll settle for the former). A minor point: I would like your proposed 5.3 and 6.1.1 (should that be 6.1.2?) text to contain something like See Section 8.14 for further discussion. I'm fine with that. You may have picked up an inconsistency in section numbers between 6.1.1 and 6.1.2 because I was having trouble deciding whether to put this new section before or after the existing 6.1.1. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
In the new section 8.14, I believe there is many statements that are hardly true, but subjective and written by someone begging to pass the buck with conflictive arguments. DKIM is part of the SYSTEM, DKIM is NOT the SYSTEM. Lets play fair with all parties. 1) Contradiction Many email implementations do not enforce [RFC5322] with strictness. As discussed in Section 5.3 DKIM processing is predicated on a valid mail message as its input. If DKIM designers knew there were many email implementations with less than strict enforcement and strictness was an requirement, then DKIM started with a problem it ignored to address. Either it was ignorant or poor engineering. Reword this. 2) There is no intent. With the intent of providing a better user experience, many agents tolerate these violations and deliver the message anyway. There is no intent by anyone to allow violations. This isn't a game. People have commercial systems and do not just say Hell, lets not follow rules. There are just things that are not expected just like DKIM didn't expect it. Also keep in mind, many systems do reject or flag bad RFC 822/8222/5322 messages. The issue here is that DKIM was a loophole even against compliant RFC5322 checking systems as the President Obama message shown. Reword this. 3) Philosophical conflictive parenthetical sentence: (This can also be taken as a demonstration that DKIM is not designed to support author validation.) It demonstrated the opposite. Please, DKIM *does not reduce* the long historical power of author of the message in any shape or form. The AUTHOR will always be a powerful part of the message. DKIM does validate the author and this requirement is reaffirmed by its special consideration - the only REQUIRED header binding. Until the 5322.From binding is made optional, it will always continue to be very important. In addition, the statement is protocol inconsistent with other existing and new internet protocols that do and continue to make the author a powerful part of the message. Please STOP trying to disassociate the 5322.From from the long time email message communication between parties. Please remove this Oh by the way.. parenthetical statement. Here is my reworded text. I would not give the How to Exploit. Let the bad guy figure it out. No blaming anyone. 8.14. Attacks Involving Addition of Header Fields Historically, email implementations have been tolerant of less than 100% strict RFC822, RFC2822 and RFC5322 formatted messages. There are certain elements within DKIM predicated on having a valid RFC 5322 messages. For example, a message with a single From: header field is expected and required by DKIM. Having more than one From: header violates Section 3.6 of [RFC5322] and should be rejected or flagged by receiving MTA systems and not passed on to DKIM signing engines. A signer wishing to be resistant to any specific multiple header attacks can include in the signed header field list an additional instance of each field that was present at signing. For example, a proper message with one From: field could be signed using h=From:From:... Because of the way header fields are canonicalized for input to the hash function, this would prevent additional fields from being added, after signing, as this would render the signature invalid. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
Hector says... If DKIM designers knew there were many email implementations with less than strict enforcement and strictness was an requirement, then DKIM started with a problem it ignored to address. Either it was ignorant or poor engineering. That's not true at all. It's common and reasonable for newer protocols to tighten things up and require stricter adherence to the older protocols. New features often make it unwise or incorrect to treat earlier requirements loosely. This is one of those cases, and in earlier versions of DKIM work there was certainly wording about requiring valid RFC 2822 (at the time) messages. 2) There is no intent. There is, quite often. It's very often the case that things on the receiving side tolerate malformed messages *specifically* to avoid rejecting more messages than necessary. With the intent of providing a better user experience, is absolutely correct in a great many cases. And we're telling verifiers that when you add DKIM, that tolerance might now be unwise. 3) Philosophical conflictive parenthetical sentence: (This can also be taken as a demonstration that DKIM is not designed to support author validation.) Yeh, that's the only part I agree on (though not with the reasoning that follows). I'm ambivalent about having that parenthetical statement in there. I'd like to see some consensus about whether to leave it or keep it. Here is my reworded text. I would not give the How to Exploit. Let the bad guy figure it out. No blaming anyone. -1; I like the wording that's there. I also look at the description of the attack not as helping bad guys, but as giving a clear explanation of what the problem is, so implementers understand the problem, and the difficulty that tolerating multiple instances of single-instance fields can create. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
The next post with the example DKIM bypass exemplifies the point that it is about DKIM fitting into the system, not the other way around. The current text tries to too hard to pass the buck on other systems when in fact, hate to say it, its about DKIM faults not anyone else. This is especially the case when it states it knows that many email implementations violates RFC5322 and thats simply not true. This offends developers quite frankly. Lets stop rationalization and lets call it for what it is. This issue fell through the (Threat Analysis) crack. If we realized it back in 2005/206 during the TA work, I think it is pretty safe to say we would of closed this loop more above and beyond just simply saying Requires RFC 5322 compliance IMO, it really has nothing to do with user experiences per se, although that might be the end result. Many, if not most, existing systems do already check for valid 822, 2822/5322 messages, especially ones that are blatant as this double 5322.From issue. I'm sure even the better ones missed this one. But many systems also do corrections, like add a missing Date: (a violations) or even a To:. All that does is make sure things are correct. Other systems might not like having a missing Date for example. The point is this is par for the course and DKIM should recognized it to fit into it, not for others to fit into DKIM. -- HLS Barry Leiba wrote: Hector says... If DKIM designers knew there were many email implementations with less than strict enforcement and strictness was an requirement, then DKIM started with a problem it ignored to address. �Either it was ignorant or poor engineering. That's not true at all. It's common and reasonable for newer protocols to tighten things up and require stricter adherence to the older protocols. New features often make it unwise or incorrect to treat earlier requirements loosely. This is one of those cases, and in earlier versions of DKIM work there was certainly wording about requiring valid RFC 2822 (at the time) messages. 2) There is no intent. There is, quite often. It's very often the case that things on the receiving side tolerate malformed messages *specifically* to avoid rejecting more messages than necessary. With the intent of providing a better user experience, is absolutely correct in a great many cases. And we're telling verifiers that when you add DKIM, that tolerance might now be unwise. 3) Philosophical conflictive parenthetical sentence: � (This can also be taken as a �demonstration that DKIM is not designed � �to support author validation.) Yeh, that's the only part I agree on (though not with the reasoning that follows). I'm ambivalent about having that parenthetical statement in there. I'd like to see some consensus about whether to leave it or keep it. Here is my reworded text. I would not give the How to Exploit. Let the bad guy figure it out. �No blaming anyone. -1; I like the wording that's there. I also look at the description of the attack not as helping bad guys, but as giving a clear explanation of what the problem is, so implementers understand the problem, and the difficulty that tolerating multiple instances of single-instance fields can create. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Barry Leiba Sent: Tuesday, October 12, 2010 8:48 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments Hector says... If DKIM designers knew there were many email implementations with less than strict enforcement and strictness was an requirement, then DKIM started with a problem it ignored to address. Either it was ignorant or poor engineering. That's not true at all. It's common and reasonable for newer protocols to tighten things up and require stricter adherence to the older protocols. New features often make it unwise or incorrect to treat earlier requirements loosely. This is one of those cases, and in earlier versions of DKIM work there was certainly wording about requiring valid RFC 2822 (at the time) messages. Indeed, the advancement from PS to DS is the perfect time to tighten up requirements. It's not any kind of re-engineering. 2) There is no intent. There is, quite often. It's very often the case that things on the receiving side tolerate malformed messages *specifically* to avoid rejecting more messages than necessary. With the intent of providing a better user experience, is absolutely correct in a great many cases. And we're telling verifiers that when you add DKIM, that tolerance might now be unwise. Concur here as well. Be liberal in what you accept, be strict in what you send has some very clear intent behind it. 3) Philosophical conflictive parenthetical sentence: (This can also be taken as a demonstration that DKIM is not designed to support author validation.) Yeh, that's the only part I agree on (though not with the reasoning that follows). I'm ambivalent about having that parenthetical statement in there. I'd like to see some consensus about whether to leave it or keep it. Also +0. Here is my reworded text. I would not give the How to Exploit. Let the bad guy figure it out. No blaming anyone. -1; I like the wording that's there. Concur; -1 on the change. I furthermore submit that we are compelled to describe the known attack, as that's precisely what we are supposed to include in Security Considerations. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
Dave CROCKER d...@dcrocker.net wrote: On 10/12/2010 11:21 AM, Murray S. Kucherawy wrote: -1; I like the wording that's there. Concur; -1 on the change. I furthermore submit that we are compelled to describe the known attack, as that's precisely what we are supposed to include in Security Considerations. We should keep in mind that DKIM's job is to deliver a validated domain name. I believe none of the attacks that have been discussed have anything to do with that task. Instead, they pertain to other forms of attack on perceived message content validity, which is entirely outside of DKIM's scope. Seriously. -1. Seriously. DKIM also attempts to provide assurance that content is unmodified. Without that the identity assurance is meaningless. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/12/10 12:01 PM, Dave CROCKER wrote: On 10/12/2010 11:21 AM, Murray S. Kucherawy wrote: ... I furthermore submit that we are compelled to describe the known attack, as that's precisely what we are supposed to include in Security Considerations. We should keep in mind that DKIM's job is to deliver a validated domain name. I believe none of the attacks that have been discussed have anything to do with that task. Instead, they pertain to other forms of attack on perceived message content validity, which is entirely outside of DKIM's scope. Disagree. DKIM is to provide an authenticated domain _associated_ with message content, since the DKIM signature is _not_ visible to recipients. As such, only the From header field is _required_ to be covered by the DKIM signature and is used to select which signature is to be verified. While DKIM does not make any assertions of content validity, it offers a strong association between the From header field and the DKIM signature! As such, it is of paramount importance that spoofed header fields affect the disposition of the message. It is unfortunate the base specification failed to stipulate message rejection whenever singular header fields are found pre-pended to a signed message where these are fields illegally redundant, and yet likely displayed instead of the signed header fields actually associated with the DKIM signature. Declaring the signature to be invalid when policy is often lacking is unlikely to represent a reasonable status able to properly control the disposition of the message. As such, the added paragraph describing the attack falls short of offering an appropriate remedy. Here is alternative text: ,--- For example, a message with multiple From: header fields violates Section 3.6 of [RFC5322]. With the intent of providing a better user experience, many agents tolerate these violations and deliver the message anyway. An MUA then might elect to render to the user the value of the last, or top, From: field. This may also be done simply out of the expectation that there is only one, where a find first algorithm would have the same result. A pre-pended From header field above one signed is an indication of likely malicious intent, where the message SHOULD be refused. A signer wishing to be resistant to this specific attack can include in the signed header field list an additional instance of each field that was present at signing. For example, a proper message with one From: field could be signed using h=From:From:... Because of the way header fields are canonicalized for input to the hash function, this would prevent additional fields from being added, after signing, as this would render the signature invalid. '--- There is no reason to suggest a strong association of the From header field with the DKIM signature is somehow diminished by the protocol not authenticating the From header field separately. It is important to _refuse_ messages when a From header field is likely to be confused with an attempt to spoof the recipient. If this means setting back progress of RFC advancement, retentions of the desired protections will make any delay well worth it. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
Sounds like you agree with me. :) Its incomplete security analysis and if you going to touch base with it regarding one attack method you need to take about the others, like I shown here: http://mipassoc.org/pipermail/ietf-dkim/2010q4/014802.html This shows its not only a matter of bad messages, but also bypassing existing RFC 5322 checking. Is this not important? It clearly shows that DKIM needs to check its own DKIM requirements and not rely on other layer. Verification is not even mentioned in this new section. Why not? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/12/10 7:58 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Jim Fenton Sent: Tuesday, October 12, 2010 5:29 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments The problem isn't limited to From, I suspect. One attack that we had considered early on was the modification of Subject, since it is prominently displayed to the user. We don't require signing of Subject, but it is recommended in section 5.5. Suppose an attacker adds an additional Subject header field, like: Subject: Buy fake watches at fakewatch.example.com! Will some clients display the second subject line? I suspect some will. Do we need to recommend that signers also add a protective second subject: to their h= value? Or do we need to require that verifiers make sure that any header fields that are signed and aren't supposed to be duplicated, aren't? I'm not sure, but right now I'm leaning toward the latter. Doesn't the text added to Section 5.3, which ends with a verifier SHOULD NOT validate a message that is not conformant, and the text added as Section 8.14, make it clear that some agents forgive such malformations with detrimental side effects, especially in MUAs, and thus admonish verifiers not to validate such messages? I'm not clear on what you're saying is missing here. I had trouble understanding that paragraph. I couldn't parse the first sentence at all. Then I got distracted by the mixed use of compliant and conformant and tried to guess whether those were the same thing. So I wasn't paying attention to this. I'll be sending out a last call response in a little while, and those comments are included there. Section 5.3's new text warns everyone, but especially verifiers, to check for these abnormalities. Section 8.14 goes into detail about the issue, and provides signers with a mechanism for guarding against it in case there are verifiers that are not so careful. So it seems to be both ends are addressed by the proposed text. As you point out, both 5.3 and 8.14 address this issue, but they're in separate places in the document. 8.14 refers to 5.2 and says that DKIM processing is predicated on a valid email message which, yes, says that signature verification should fail, but IMO not nearly clearly enough. Instead 8.14 goes into detail about how to force verification to fail if a duplicate header field is inserted (which is also covered in the description of h= in section 3.5). The attack doesn't really have anything to do with the fact that the From header field must be signed; the attack can be done on any signed header field that must be unique. I think the case you reference as latter here is actually the enforcement of RFC5322 validity, and I agree that this should be done by anything that handles the message. You're right, it's not limited to From:, but 8.14 only uses that as an example. It does also contain a more general description of the issue. I missed the for example at the beginning of the paragraph. It's easy to jump to the conclusion that From is the only special case because it's the only header field required to be signed. If the diff from RFC4871 doesn't say the right thing, can you propose alternate text? I'll write something tomorrow. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Jim Fenton Sent: Tuesday, October 12, 2010 9:48 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments I had trouble understanding that paragraph. I couldn't parse the first sentence at all. Then I got distracted by the mixed use of compliant and conformant and tried to guess whether those were the same thing. So I wasn't paying attention to this. I'll be sending out a last call response in a little while, and those comments are included there. As Dave mentioned, a small block of words were accidentally omitted which does make it look strange. I think he posted what was supposed to be there. The mixed use of words is a fair complaint. I think we can safely just switch one of those to the other one to make it consistent. As you point out, both 5.3 and 8.14 address this issue, but they're in separate places in the document. 8.14 refers to 5.2 and says that DKIM processing is predicated on a valid email message which, yes, says that signature verification should fail, but IMO not nearly clearly enough. Instead 8.14 goes into detail about how to force verification to fail if a duplicate header field is inserted (which is also covered in the description of h= in section 3.5). That was intentional, inasmuch as Section 5 contains normative stuff while 8.14 describes the attack in detail and then talks about how one might mitigate it if the enforcement of standard mail format can't be achieved at one end or the other. The partitioning into definition (what you have to do to be compliant) and discussion (what you could do when compliance might not be possible) seemed to make sense there. The attack doesn't really have anything to do with the fact that the From header field must be signed; the attack can be done on any signed header field that must be unique. Quite right. We could mention exactly that in 8.14 as well, just to make it explicit. Thanks, -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/13/2010 1:02 AM, Murray S. Kucherawy wrote: The mixed use of words is a fair complaint. I think we can safely just switch one of those to the other one to make it consistent. gad. you guys have no literary sensibility at all. sigh. a shame this is a spec, which makes you guys right and the current text confusing. sigh. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
