Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On Fri, 15 Oct 2010 17:47:24 +0100, Jim Fenton 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 Fri, 15 Oct 2010 15:48:05 +0100, Ian Eiloart 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 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 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
> -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 6:06 AM, Charles Lindsey wrote: > On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton 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
On 15/Oct/10 17:13, John Levine wrote: > 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? 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 15 October 2010 14:06:16 +0100 Charles Lindsey 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)? You've answered your own question here. Given that a successful phisher would have access to my Sent Messages mailbox > 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. 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. 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. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ 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 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
> -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 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 Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton 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. +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
On Wed, 13 Oct 2010 18:13:43 +0100, Jim Fenton 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 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? >> 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. The reason why such a message may be questioned is not relevant to the signature validation algorithm. Contrast that with Signatures MAY be considered invalid if the verification time at the verifier is past the expiration date. ___ 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
>>> 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
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
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 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
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
+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. > = > > 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
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. = 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
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: Wednesday, October 13, 2010 10:14 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments > > 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. Does it make sense to be weaker about other things we haven't anticipated yet that might actually be worse? 5.3 covers everything by requiring general compliance; 8.14 points out the specific header-centric issue. Since the normative part of 5.3 says SHOULD, I think this covers it nicely. > 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. I agree; I'd rather leave it at the above two. ___ 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 Tue, 12 Oct 2010 14:21:31 +0100, Hector Santos wrote: > 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 Even though I might not agree with all of Hector's suggested rewordings. -- 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 Tue, 12 Oct 2010 21:41:18 +0100, Scott Kitterman wrote: > DKIM also attempts to provide assurance that content is unmodified. > Without that the identity assurance is meaningless. +1 And also assurance that other headers than From are unmodified. -- 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 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
>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/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
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/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 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. 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. 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. If the diff from RFC4871 doesn't say the right thing, can you propose alternate text? -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
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 11:21 AM, Murray S. Kucherawy wrote: > (Barry Leiba said:) >> -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. I'm somewhere in the middle; I don't agree with Hector and I don't like the wording that's there either. Let's consider what a Bad Actor might try to do and what the result might be. Suppose that a Bad Actor successfully inserted a second From header field in such a way that the user's MUA displayed it in place of the original, signed, From header field. If the added From header field is from a different domain than the SDID, then the advice in section 6.3 paragraph 5 applies: "If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader." (I'm seeing a problem with this wording now too, but I digress.) Presumably this applies to whatever From header field is going to be displayed. If the added From header field is from the same domain as the SDID, there's a different problem. Perhaps the message had an Author Signature and the attacker intended to masquerade as a different user in that domain. But since we don't use the local part to establish what is and isn't an Author Signature (i.e., we don't look at the local part of i=) that's not a problem that DKIM is designed to address. 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. -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 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
"Dave CROCKER" 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
Murray S. Kucherawy wrote: >> -Original Message- >> 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. I don't see how this applies because its about being less tolerant. See below. >>> 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. Sure, but only when you work out all the security issues and due to time and the rush to rubber stamp this bis, it hasn't completely been done. The text statement is not complete because the issue is not only when mail is not compliant but when a receiver system is indeed compliant but not by DKIM. Only one solution was provided. I showed this in the message: http://mipassoc.org/pipermail/ietf-dkim/2010q4/014802.html indicating how ready systems can be RFC5322 checking ready but somehow with DKIM this is bypassed. Only DKIM can check for DKIM requirements and this is not stated in the text. There is no verifier statement. (Note to those who have written me off list about the lack of verifier statement; please just don't tell just me - post your opinion here too!) The TEXT should include something like: A verifier can be resistant to these exploits by invalidating messages with multiple From: header violations. The current text is a first good effort, got lost on blaming others, but itself for lack of proper verifying its messages. Why? Because if this was discovered during the WG TA efforts, rest assured we would have the 5322.From Exception Trapping Logic added to the verification and signing logic. Add it correctly so we can be done with this please. -- 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/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. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
Barry, The main gist is not that: "many email implementations violates RFC5322" but that there exist (how much, we don't know) email implementations who do not check for "100% correct" RFC5322 messages. So I agree when you say: And we're telling verifiers that when you add DKIM, that tolerance might now be unwise. but as shown in my example DKIM bypass: http://mipassoc.org/pipermail/ietf-dkim/2010q4/014802.html The receiver already did have a valid RFC 5322 checker and it held the faulty message for approval. If however, the faulty message was signed by my system and resubmitted, the mipassoc.org list will have accepted it. Thats a DKIM implementation related issue perhaps but the text should indicate it needs to check for this stuff as well. Not pass it on to other layers and expect the best outcome. -- HLS Hector Santos wrote: > 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
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
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
