Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> It should be perfectly fine to say DKIM expects valid input, for > whatever definition of that we want to invent, and also state that > handing it anything else has either undefined results or specific bad > results. We seem to be talking past each other here. I don't see anyone proposing a deep dive into 5322 validation. But 4871 already says you MUST sign the From: header. Why is that OK, but saying you MUST NOT sign or validate something with two From: headers is not? We're not suggesting anything that would invalidate existing bits on the wire, after all. DKIM is full of layer violations where it tells people how to sign and verify robustly. Sec. 5.3 tells signers to downcode 8-bit MIME, 6.1.2 has some fairly dubious assumptions about the structure of the DNS, 6.1.3 even tells verifiers to rewrite MIME separators. This seems an odd place to draw a line in the sand, and an unfortunate one if you believe that an important use of DKIM should be to whitelist mail from trusted signers. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 10/14/2010 10:17 AM, John R. Levine wrote: > I don't see anyone proposing a deep dive into 5322 validation. But 4871 > already says you MUST sign the From: header. Why is that OK, but saying > you MUST NOT sign or validate something with two From: headers is not? > We're not suggesting anything that would invalidate existing bits on the > wire, after all. > > DKIM is full of layer violations where it tells people how to sign and > verify robustly. Protocol specifications should require all of that actions that are essential to correct operation and none of the actions that are not. A DKIM signature verifies or it doesn't. It delivers a signing domain or it doesn't. What is essential is that it perform the task of validating and delivering a signing domain that is associated with a collection of bits. Anything that defines how to do this is essential. Anything that can make this break needs to be covered, especially if there are ways to protect against the breakage. Perhaps surprisingly, having redundant header fields does not make DKIM break. And it is an issue outside of DKIM and, therefore, need not be "protected against" by DKIM. Also surprisingly, the same holds for more general message conformance checking. The checking does not make DKIM work, and it does not make it work better or worse. So it isn't needed. 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] layer violations, was detecting header mutations after signing
> What is essential is that it perform the task of validating and delivering a > signing domain that is associated with a collection of bits. Anything that > defines how to do this is essential. Anything that can make this break needs > to > be covered, especially if there are ways to protect against the breakage. But isn't the problem that the signing domain is being incorrectly associated with a different collection of bits? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote: > > What is essential is that it perform the task of validating and delivering > > a > > signing domain that is associated with a collection of bits. Anything that > > defines how to do this is essential. Anything that can make this break > > needs to > > be covered, especially if there are ways to protect against the breakage. > > But isn't the problem that the signing domain is being incorrectly > associated with a different collection of bits? And just to elaborate on my own point. We went thru a lot of hand-wringing over canonicalization and the l= tag and so forth precisely because we were concerned about associating a signing domain with the wrong bits. But now it seems that making the wrong association is not treated with as much concern. If it is true that the DKIM effort is about associating an identifier with a collection of bits, it equally must be true that we want to make a similar effort to ensure that identifier is not associated with an unrelated collection of bits. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
Perhaps surprisingly, having redundant header fields does not make DKIM break. We must have some vastly different definition of "break". If allowing through modified messages that render very differently isn't broken, shouldn't we remove the advice against signing with l=0? The advice in favor of signing Subject: and To: fields? None of those has any technical effect on the ability of a verifier to compute and compare hashes. If not, what's the difference, other than the fact that we thought of some of them several years ago and just noticed these last week? Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 10/14/2010 07:58 AM, John R. Levine wrote: >> Perhaps surprisingly, having redundant header fields does not make >> DKIM break. > > We must have some vastly different definition of "break". > > If allowing through modified messages that render very differently isn't > broken, shouldn't we remove the advice against signing with l=0? The > advice in favor of signing Subject: and To: fields? None of those has > any technical effect on the ability of a verifier to compute and compare > hashes. There is an enormous difference between the situations with DKIM and, say, TLS+X509. With TLS, you take the output of the checks and use THAT ALONE to decide to deliver the bits or not. DKIM has *never* been such a protocol: there is a vast backstop of security infrastructure where DKIM is a just helper. Like I said, give spam/phishing filter writers some credit. They are not idiots. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 10/14/2010 07:56 AM, Mark Delany wrote: > On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote: >>> What is essential is that it perform the task of validating and delivering a >>> signing domain that is associated with a collection of bits. Anything that >>> defines how to do this is essential. Anything that can make this break >>> needs to >>> be covered, especially if there are ways to protect against the breakage. >> >> But isn't the problem that the signing domain is being incorrectly >> associated with a different collection of bits? > > And just to elaborate on my own point. We went thru a lot of > hand-wringing over canonicalization and the l= tag and so forth > precisely because we were concerned about associating a signing domain > with the wrong bits. > > But now it seems that making the wrong association is not treated with > as much concern. > > If it is true that the DKIM effort is about associating an identifier > with a collection of bits, it equally must be true that we want to > make a similar effort to ensure that identifier is not associated with > an unrelated collection of bits. Mark, with a signed bunch of bits you get two prizes for the price of one: you know which bits are signed, and then you know which bits aren't. There is no ambiguity in the spec about which bits are signed, so we're quibbling about the ones that aren't. Isn't this where we want to have people's secret sauce take over? That is, we want MTA, MDA, and MUA's to take those two piece of information and make better decisions about, oh say, rendering? We already know that the DKIM spec alone is not going to force the hand of recalcitrant or uncaring MUA's, but it is potentially quite helpful to ones that are receptive. Unless there's *really* something they can't figure out without protocol help, I'm not sure what the point of this is. This double added From thing is trivial to detect with the current spec. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Mark Delany > Sent: Thursday, October 14, 2010 7:38 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > But isn't the problem that the signing domain is being incorrectly > associated with a different collection of bits? By the verifier, or by the MUA? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> Unless there's *really* something they can't figure out without protocol > help, I'm not sure what the point of this is. This double added From thing > is trivial to detect with the current spec. Well, yeah. That's why I don't understand why people are so opposed to a SHOULD saying they should. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of John R. Levine > Sent: Thursday, October 14, 2010 7:59 AM > To: dcroc...@bbiw.net > Cc: DKIM List > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > If allowing through modified messages that render very differently > isn't broken, shouldn't we remove the advice against signing with l=0? > The advice in favor of signing Subject: and To: fields? None of those > has any technical effect on the ability of a verifier to compute and > compare hashes. > > If not, what's the difference, other than the fact that we thought of > some of them several years ago and just noticed these last week? The difference is that the Subject:, To: and l= advice don't dabble in the area of having to tell a DKIM implementer to enforce parts of other protocols. Adding a second From: makes the message format illegal. The other ones don't. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 10/14/2010 09:45 AM, John R. Levine wrote: >> Unless there's *really* something they can't figure out without protocol >> help, I'm not sure what the point of this is. This double added From thing >> is trivial to detect with the current spec. > > Well, yeah. That's why I don't understand why people are so opposed to a > SHOULD saying they should. Because the audience who ought to be dealing with the larger problem has little to nothing to do with the audience that would have to deal with that MUST/SHOULD. It's a useless requirement to put on DKIM. If you really think this is such a great big problem, maybe you should be banging the drums at MAAWG or other venues where the correct set of ears is potentially listening. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> The difference is that the Subject:, To: and l= advice don't dabble in the > area of having to tell a DKIM implementer to enforce parts of other protocols. > > Adding a second From: makes the message format illegal. The other ones don't. We're still talking past each other. You're right, it makes the message format illegal, but so what? Historically, there has been no reason for MUAs to enforce format compliance on incoming messages. I get the impression that people expect that to change. But why would it? "To catch stuff that DKIM chose not to" isn't very compelling. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> If you really think this is such a great big problem, maybe you should be > banging the drums at MAAWG or other venues where the correct set of ears > is potentially listening. I would rather not have to run a session at MAAWG entitled "How to fix the security holes in DKIM", but I certainly could. Am I really the only person who wants to be able to whitelist mail signed with known good signatures, drop it into user inboxes and expect reasonable results with existing MUAs? This is basically the same model as X509, except that X509 builds the credibity test into the protocol via CAs, rather than externally via something like VBR. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Thursday, October 14, 2010 10:07 AM > To: Murray S. Kucherawy > Cc: DKIM List > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > > Adding a second From: makes the message format illegal. The other > > ones don't. > > We're still talking past each other. You're right, it makes the > message format illegal, but so what? That makes it invalid input to any module that requires input to comply with RFC5322, pure and simple. > Historically, there has been no reason for MUAs to enforce format > compliance on incoming messages. I get the impression that people expect > that to change. But why would it? "To catch stuff that DKIM chose not > to" isn't very compelling. I think if it becomes well-known that users of MUA 1 are easier to phish than users of MUA 2, a lot of people will gravitate to the safer implementation, don't you? I sure would. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 10/14/2010 10:15 AM, John R. Levine wrote: >> If you really think this is such a great big problem, maybe you should be >> banging the drums at MAAWG or other venues where the correct set of ears >> is potentially listening. > > I would rather not have to run a session at MAAWG entitled "How to fix the > security holes in DKIM", but I certainly could. > > Am I really the only person who wants to be able to whitelist mail signed > with known good signatures, drop it into user inboxes and expect > reasonable results with existing MUAs? I would hope so because this would be a really stupid thing to do. Without the next line of defense -- virus, malware, spam, phishing -- you'd be setting your users up for big problems. Just because it's DKIM signed from a good source doesn't mean it's not still evil. That's why all of this hand wringing is silly. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of John R. Levine > Sent: Thursday, October 14, 2010 10:15 AM > To: DKIM List > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > Am I really the only person who wants to be able to whitelist mail signed > with known good signatures, drop it into user inboxes and expect > reasonable results with existing MUAs? Not only do I want that, I did that. But the DKIM/ADSP module of that system is purely DKIM/ADSP. The module that sits between the MTA and the DKIM/ADSP module does the header count enforcement we're talking about, knowing there's the potential for invalid mush in there. You don't have to do it that way in the source code to make it work properly if some other design makes sense for you, but that is the delineation that should appear in the normative parts of protocol specifications. I'm talking purely about specification here. I'm totally fine with one omnibus implementation that does everything from SMTP server right up to a webmail rendering if that's what you want to do. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> That makes it invalid input to any module that requires input to comply with > RFC5322, pure and simple. Well, OK, with the stipulation that no existing MUA I have ever seen is such a module. > I think if it becomes well-known that users of MUA 1 are easier to phish than users of MUA 2, a lot of people will gravitate to the safer implementation, don't you? I sure would. Aw, come on. How many millions of people still use Outlook Express on Windows XP? Switching MUAs is painful, people rarely do it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Thursday, October 14, 2010 10:45 AM > To: Murray S. Kucherawy > Cc: DKIM List > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > > I think if it becomes well-known that users of MUA 1 are easier to phish > > than users of MUA 2, a lot of people will gravitate to the safer > > implementation, don't you? I sure would. > > Aw, come on. How many millions of people still use Outlook Express on > Windows XP? Switching MUAs is painful, people rarely do it. ...meaning MUA developers won't bother to do something about it once the attack is plainly visible and they're used as examples, because since users won't switch anyway, there's no motivation? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> Not only do I want that, I did that. But the DKIM/ADSP module of that > system is purely DKIM/ADSP. The module that sits between the MTA and > the DKIM/ADSP module does the header count enforcement we're talking about, > knowing there's the potential for invalid mush in there. Well, now we're back to my question to Dave, what's the advantage of leaving that as folklore rather than putting it in the spec other than the warm theological feeling of somewhat preserving layer distinctions, except for all the places we already didn't? We're still not talking about changing the bits on the wire, nor of the handling of any valid 5322 message. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Thursday, October 14, 2010 10:50 AM > To: Murray S. Kucherawy > Cc: DKIM List > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > Well, now we're back to my question to Dave, what's the advantage of > leaving that as folklore rather than putting it in the spec other than the > warm theological feeling of somewhat preserving layer distinctions, except > for all the places we already didn't? Why does it have to be normative? Authentication-Results has no normative "watch out for weird input" SHOULDs or MUSTs, but instead has an extensive discussion of possible issues in its Security Considerations section. That's what secdir asked for, and I was fine with that. (It actually does have some normative MUA advice. Wonder how that happened.) Nobody's saying this has to be relegated to "folklore". We can put a gigantic treatise on this in an informative appendix making this the biggest RFC ever if it will make people feel better. I just don't think it can be reasonably made normative. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 10/14/2010 10:47 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: John R. Levine [mailto:jo...@iecc.com] >> Sent: Thursday, October 14, 2010 10:45 AM >> To: Murray S. Kucherawy >> Cc: DKIM List >> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations >> after signing >> >>> I think if it becomes well-known that users of MUA 1 are easier to phish >>> than users of MUA 2, a lot of people will gravitate to the safer >>> implementation, don't you? I sure would. >> >> Aw, come on. How many millions of people still use Outlook Express on >> Windows XP? Switching MUAs is painful, people rarely do it. > > ...meaning MUA developers won't bother to do something about it once the > attack is plainly visible and they're used as examples, because since users > won't switch anyway, there's no motivation? Not to mention the false dilemma that this needs to be handled in the MUA exclusively. It doesn't. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
>> Well, now we're back to my question to Dave, what's the advantage of >> leaving that as folklore rather than putting it in the spec other than the >> warm theological feeling of somewhat preserving layer distinctions, except >> for all the places we already didn't? > > Why does it have to be normative? I'd be perfectly happy with Jim's language which as I recall says something like signers SHOULD decline to sign messages with redundant headers and verifiers SHOULD decline to verify messages with unsigned redundant headers. This is an attack on DKIM, not on MUAs, so it's reasonable for DKIM to at least take a crack at dealing with it. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
--On 14 October 2010 09:27:35 -0700 Michael Thomas wrote: > Unless there's *really* something they can't figure out without protocol > help, I'm not sure what the point of this is. This double added From thing > is trivial to detect with the current spec. Well, it took us a few years to spot the problem, and that's because some MUA exhibits it. Surely a little guidance wouldn't go amiss? -- 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] layer violations, was detecting header mutations after signing
--On 14 October 2010 10:23:21 -0700 Michael Thomas wrote: > On 10/14/2010 10:15 AM, John R. Levine wrote: >>> If you really think this is such a great big problem, maybe you should >>> be banging the drums at MAAWG or other venues where the correct set of >>> ears is potentially listening. >> >> I would rather not have to run a session at MAAWG entitled "How to fix >> the security holes in DKIM", but I certainly could. >> >> Am I really the only person who wants to be able to whitelist mail signed >> with known good signatures, drop it into user inboxes and expect >> reasonable results with existing MUAs? > > I would hope so because this would be a really stupid thing to do. > Without the next line of defense -- virus, malware, spam, phishing -- > you'd be setting your users up for big problems. Just because it's > DKIM signed from a good source doesn't mean it's not still evil. I think the emphasis in John's email was on "expect reasonable results with existing MUAs" If DKIM is any part of the evaluation process, then that's all thrown away if MUAs are showing the wrong email address as authenticated. > That's why all of this hand wringing is silly. > > Mike > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html -- 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] layer violations, was detecting header mutations after signing
--On 14 October 2010 13:44:40 -0400 "John R. Levine" wrote: >> That makes it invalid input to any module that requires input to comply >> with RFC5322, pure and simple. > > Well, OK, with the stipulation that no existing MUA I have ever seen is > such a module. Nor MTA, either. Exim has a "verify = header_syntax" ACL option, which checks the syntax of headers that contain addresses, but it doesn't count headers, so it doesn't spot this problem. A bug report has been filed, so this conversation has helped there. >> I think if it becomes well-known that users of MUA 1 are easier to phish >> than users of MUA 2, a lot of people will gravitate to the safer >> implementation, don't you? I sure would. > > Aw, come on. How many millions of people still use Outlook Express on > Windows XP? Switching MUAs is painful, people rarely do it. Too true. When I started working here in 1999, Siren Mail had just ceased development. We've only just (in the last few months) got Siren Mail out of the hands of the last user hanging on. And the motivation there was that Siren Mail didn't do authenticated SMTP! -- 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] layer violations, was detecting header mutations after signing
Ian Eiloart wrote: > > I think the emphasis in John's email was on "expect reasonable results with > existing MUAs" If DKIM is any part of the evaluation process, then that's > all thrown away if MUAs are showing the wrong email address as > authenticated. > MUAs are like children. They eat what we feed them and they can't exist without a backend. -- 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] layer violations, was detecting header mutations after signing
Murray S. Kucherawy wrote: >> Levine wrote: >> Aw, come on. How many millions of people still use Outlook Express on >> Windows XP? Switching MUAs is painful, people rarely do it. > ...meaning MUA developers won't bother to do something about > it once the attack is plainly visible and they're used as > examples, because since users won't switch anyway, there's no motivation? The backend will address it first before the MUA needs too. Murray, most people are not haters and don't draw a line between good and bad because one isn't perfect and therefore begin to "switch" software like cheap wine. Since DKIM is betting its future on increase mail integrity and verified identities, it is a fundamental requirement that it checks key parts to make sure the integrity stays in tack. Passing the buck (or assuming others are better suited to deal with it) is not practical and bad PR for DKIM. In reality, all parts need to check for this, the MUAs, the backends and above all because of the extra special needs for trust - DKIM. The backends can't presume all the different MUAs used will address this, so it needs to address it. The DKIM components can't assume the backend or MUAs will address it, so it needs to address it itself. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On Thu, 14 Oct 2010 15:17:15 +0100, John R. Levine wrote: > We seem to be talking past each other here. > > I don't see anyone proposing a deep dive into 5322 validation. But 4871 > already says you MUST sign the From: header. Why is that OK, but saying > you MUST NOT sign or validate something with two From: headers is not? > We're not suggesting anything that would invalidate existing bits on the > wire, after all. +1 -- 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] layer violations, was detecting header mutations after signing
On Thu, 14 Oct 2010 17:45:39 +0100, John R. Levine wrote: > Well, yeah. That's why I don't understand why people are so opposed to a > SHOULD saying they should. Or even a MUST saying they must. -- 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] layer violations, was detecting header mutations after signing
On Thu, 14 Oct 2010 18:01:25 +0100, Michael Thomas wrote: > Because the audience who ought to be dealing with the larger problem has > little to > nothing to do with the audience that would have to deal with that > MUST/SHOULD. > It's a useless requirement to put on DKIM. So which two audiences do you have in mind? The primary audience is the people who write verifiers for boundaries. The end users are hardly an audience at all since they are not listening directly to us, and they are likely using software that is 10 years old, and are unlikely to change. -- 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] layer violations, was detecting header mutations after signing
On Thu, 14 Oct 2010 18:23:21 +0100, Michael Thomas wrote: > I would hope so because this would be a really stupid thing to do. > Without the next line of defense -- virus, malware, spam, phishing -- > you'd be setting your users up for big problems. Just because it's > DKIM signed from a good source doesn't mean it's not still evil. Have you ever seen an evil message from Ebay? And yet the current protocol will allow an evil mail _apparently_ from Ebay to appear, with no means for the recipient to detect the difference. And as regards using current malware detection software, can you please explain to us how that is supposed to catch an eveil mail signed by a brand-new throwaway domain that has not yet had time to acquire any reputation, good or bad? > > That's why all of this hand wringing is silly. We are not hand wringing. We are pointing out a protocol that, when applied in the current (and likely future) Real World, fails to deliver what it was intended to deliver. -- 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] layer violations, was detecting header mutations after signing
On Thu, 14 Oct 2010 18:30:38 +0100, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org >> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine >> Sent: Thursday, October 14, 2010 10:15 AM >> To: DKIM List >> Subject: Re: [ietf-dkim] layer violations, was detecting header >> mutations after signing >> >> Am I really the only person who wants to be able to whitelist mail >> signed >> with known good signatures, drop it into user inboxes and expect >> reasonable results with existing MUAs? > > Not only do I want that, I did that. But the DKIM/ADSP module of that > system is purely DKIM/ADSP. The module that sits between the MTA and > the DKIM/ADSP module does the header count enforcement we're talking > about, knowing there's the potential for invalid mush in there. Which module does which bit of the counting/DKIM/ADSP is a minor implemention detail. Any DKIM verifier MUST be associated with a counting mechanism, and whether this is done within itself or by some other module within the overall MTA is neither here nor there. And ADSP also needs to make it clear which From header it needs to look at; and until that is fixed we MUST assume that it will look at whichever From header gives the worst outcome. -- 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] layer violations, was detecting header mutations after signing
On 10/15/2010 06:51 AM, Charles Lindsey wrote: > On Thu, 14 Oct 2010 18:23:21 +0100, Michael Thomas wrote: > >> I would hope so because this would be a really stupid thing to do. >> Without the next line of defense -- virus, malware, spam, phishing -- >> you'd be setting your users up for big problems. Just because it's >> DKIM signed from a good source doesn't mean it's not still evil. > > Have you ever seen an evil message from Ebay? s/Ebay/Yahoo!, etc, yes. > And yet the current protocol will allow an evil mail _apparently_ from > Ebay to appear, with no means for the recipient to detect the difference. They're not apparently from them. They *are* from them. DKIM is not any indication of whether the content is evil or not, per se. It just says who to complain to if it is evil. > And as regards using current malware detection software, can you please > explain to us how that is supposed to catch an eveil mail signed by a > brand-new throwaway domain that has not yet had time to acquire any > reputation, good or bad? Irrelevant for the current discussion. Mike >> >> That's why all of this hand wringing is silly. > > We are not hand wringing. We are pointing out a protocol that, when > applied in the current (and likely future) Real World, fails to deliver > what it was intended to deliver. > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Charles Lindsey > Sent: Friday, October 15, 2010 6:58 AM > To: DKIM > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > Which module does which bit of the counting/DKIM/ADSP is a minor > implemention detail. Any DKIM verifier MUST be associated with a counting > mechanism, and whether this is done within itself or by some other module > within the overall MTA is neither here nor there. This continues to conflate specification with implementation. You're talking about the latter, I'm talking about the former. > And ADSP also needs to make it clear which From header it needs to look > at; and until that is fixed we MUST assume that it will look at > whichever > From header gives the worst outcome. The current effort has everything to do with moving DKIM to draft standard, and nothing at all to do with handling ADSP issues. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Charles Lindsey > Sent: Friday, October 15, 2010 6:52 AM > To: DKIM > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > > That's why all of this hand wringing is silly. > > We are not hand wringing. We are pointing out a protocol that, when > applied in the current (and likely future) Real World, fails to deliver > what it was intended to deliver. This to me says you still believe DKIM's ultimate payload is something other than a validated identifier, in this case a domain name. We're thus not on the same page. If instead we do agree that that's its sole intended purpose (and consensus on the errata RFC was achieved, thus confirming this), then you also have to agree that DKIM already does that. The MUAs simply fail to make use of it, and that's the real problem. DKIM does not purport to guarantee delivery of something that an MUA is incapable of misrepresenting. The proposed changes don't improve this. And since we're all insisting MUA developer and user inertia is here to stay, then even all the fixes we're talking about aren't going to make the enforcement of header field counts visible to end users; the sum and substance of the impact will be that the Authentication-Results header field (or other annotation) will change from "fail" to "pass", but this is rarely rendered to end users, and so the problem remains. RFC5451 says an Authentication-Results field shouldn't include in its authentication summary any data that wasn't authenticated. Blocking presentation of unauthenticated data, or highlighting it as dubious, or outright obstruction of its delivery, are the right ways to deal with this. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Murray S. Kucherawy > Sent: Friday, October 15, 2010 10:04 AM > To: DKIM > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > And since we're all insisting MUA developer and user inertia is here to > stay, then even all the fixes we're talking about aren't going to make > the enforcement of header field counts visible to end users; the sum > and substance of the impact will be that the Authentication-Results > header field (or other annotation) will change from "fail" to "pass", > but this is rarely rendered to end users, and so the problem remains. That should be "pass" to "fail", of course. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On Fri, 15 Oct 2010 17:45:22 +0100, Michael Thomas wrote: > On 10/15/2010 06:51 AM, Charles Lindsey wrote: >> And yet the current protocol will allow an evil mail _apparently_ from >> Ebay to appear, with no means for the recipient to detect the >> difference. > > They're not apparently from them. They *are* from them. No they are not. Clearly you have failed to understand the scam that I am concerned about, though I have explained in often enough. >> And as regards using current malware detection software, can you please >> explain to us how that is supposed to catch an eveil mail signed by a >> brand-new throwaway domain that has not yet had time to acquire any >> reputation, good or bad? > > Irrelevant for the current discussion. On the contrary, that is precisely the attack of interest, so it is supremely relevant. You claim it can be thwarted by other means, but have failed to explain exactly how those "other means" would work. -- 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] layer violations, was detecting header mutations after signing
On Fri, 15 Oct 2010 18:04:22 +0100, Murray S. Kucherawy wrote: > This to me says you still believe DKIM's ultimate payload is something > other than a validated identifier, in this case a domain name. We're > thus not on the same page. > > If instead we do agree that that's its sole intended purpose (and > consensus on the errata RFC was achieved, thus confirming this), then > you also have to agree that DKIM already does that. The MUAs simply > fail to make use of it, and that's the real problem. But we DON'T agree that. It may have been a commonly held opinion at some time, but recent contributions to these threads indicate a considerable opinion otherwise. The best opinion seems to be Mark's "What you see is what they sent". -- 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] layer violations, was detecting header mutations after signing
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Charles Lindsey > Sent: Monday, October 18, 2010 4:24 AM > To: DKIM > Subject: Re: [ietf-dkim] layer violations, was detecting header mutations > after signing > > > Irrelevant for the current discussion. > > On the contrary, that is precisely the attack of interest, so it is > supremely relevant. You claim it can be thwarted by other means, but have > failed to explain exactly how those "other means" would work. On the contrary, none of this is within the prescribed scope of DKIM. ADSP and reputation (the latter of which is explicitly out of scope) are predicated on DKIM's output, not part of its input or its mechanics. These topics are distractions from the effort of solidifying the DKIM specification for advancement along the standards track. That's what I believe he means by "irrelevant for the current discussion". ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Charles Lindsey >> Sent: Monday, October 18, 2010 4:24 AM >> To: DKIM >> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations >> after signing >> >>> Irrelevant for the current discussion. >> On the contrary, that is precisely the attack of interest, so it is >> supremely relevant. You claim it can be thwarted by other means, but have >> failed to explain exactly how those "other means" would work. > > On the contrary, none of this is within the prescribed scope of DKIM. ADSP > and reputation (the latter of which is explicitly out of scope) are > predicated on DKIM's output, not part of its input or its mechanics. From an IETF "standpoint" it might not be, but from an engineering standpoint, I beg to differ. > These topics are distractions from the effort of solidifying the DKIM > specification for advancement along the standards track. That's what I > believe he means by "irrelevant for the current discussion". We need to stop blaming others. Borrowing an old QA engineering motto: "Getting it Right. The First Time!" Otherwise, you get what you have today. Note, that is not about "perfection," but rather proper engineering to minimize customer issues even it if means a little more upfront cost. In my view, a good bit of the issue was manifested by the on-going out of scope design considerations with a) defocusing of Policy and b) greater allowance for unrestricted resigners and participants were providing input that there was an engineering problem with this. -- 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] layer violations, was detecting header mutations after signing
On Mon, 18 Oct 2010 21:19:18 +0100, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org >> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey >> Sent: Monday, October 18, 2010 4:24 AM >> To: DKIM >> Subject: Re: [ietf-dkim] layer violations, was detecting header >> mutations after signing >> >> > Irrelevant for the current discussion. >> >> On the contrary, that is precisely the attack of interest, so it is >> supremely relevant. You claim it can be thwarted by other means, but >> have >> failed to explain exactly how those "other means" would work. > > On the contrary, none of this is within the prescribed scope of DKIM. > ADSP and reputation (the latter of which is explicitly out of scope) are > predicated on DKIM's output, not part of its input or its mechanics. > > These topics are distractions from the effort of solidifying the DKIM > specification for advancement along the standards track. That's what I > believe he means by "irrelevant for the current discussion". The scam I have described involves the use, by the phisher, of a DKIM-signed (by himself) email with two From: headers, which is intended to fool verifiers into not spotting that the first signature should have triggered an ADSP lookup which would have revealed that the first From: was 'discardable'. Naturally, the phisher signs with a throaway domain that has not yet acquired any reputation, good or bad. Since the scam involves the use of DKIM, and since the only fix I am aware of requires a change to the DKIM standard, then it is highly relevant to the current discussion. -- 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] layer violations, was detecting header mutations after signing
On 20/Oct/10 13:23, Charles Lindsey wrote: > On Mon, 18 Oct 2010 21:19:18 +0100, Murray S. Kucherawy > wrote: >> These topics are distractions from the effort of solidifying the DKIM >> specification for advancement along the standards track. That's what I >> believe he means by "irrelevant for the current discussion". > > The scam I have described involves the use, by the phisher, of a > DKIM-signed (by himself) email with two From: headers, which is intended > to fool verifiers into not spotting that the first signature should have > triggered an ADSP lookup which would have revealed that the first From: > was 'discardable'. > > Naturally, the phisher signs with a throaway domain that has not yet > acquired any reputation, good or bad. > > Since the scam involves the use of DKIM, and since the only fix I am aware > of requires a change to the DKIM standard, then it is highly relevant to > the current discussion. IMHO, this issue has to be addressed refining the signing spec. For example, the initial paragraph of section 5.4 could be modified so as to read: The From header field MUST be signed; that is, it MUST be included at least once in the "h=" tag of the resulting DKIM-Signature header field, and SHOULD be included twice (see Section 8.14). In addition, the signer MUST ensure that at most one instance of the From field actually exists in the header. The current PS silently assumes that there is a single From, and I guess most interoperability and testing has been done in such conditions. Hence an amendment like the text above can be understood as a clarification --rather than a change-- of the protocol. Verifiers would then discard any From field after the first one, whether signed or not. Of course, a combo-verifier is always free to return some error due to bad message syntax, even if all signatures verify (although I'd consider it cleaner to return non-DKIM errors for non-DKIM failures.) JM2C ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 10/20/10 7:27 AM, Alessandro Vesely wrote: > On 20/Oct/10 13:23, Charles Lindsey wrote: >> The scam I have described involves the use, by the phisher, of a >> DKIM-signed (by himself) email with two From: headers, which is intended >> to fool verifiers into not spotting that the first signature should have >> triggered an ADSP lookup which would have revealed that the first From: >> was 'discardable'. >> >> Naturally, the phisher signs with a throaway domain that has not yet >> acquired any reputation, good or bad. >> >> Since the scam involves the use of DKIM, and since the only fix I am aware >> of requires a change to the DKIM standard, then it is highly relevant to >> the current discussion. > IMHO, this issue has to be addressed refining the signing spec. For > example, the initial paragraph of section 5.4 could be modified so as > to read: > > The From header field MUST be signed; that is, it MUST be included > at least once in the "h=" tag of the resulting DKIM-Signature > header field, and SHOULD be included twice (see Section 8.14). In > addition, the signer MUST ensure that at most one instance of the > From field actually exists in the header. > > The current PS silently assumes that there is a single From, and I > guess most interoperability and testing has been done in such > conditions. Hence an amendment like the text above can be understood > as a clarification --rather than a change-- of the protocol. > > Verifiers would then discard any From field after the first one, > whether signed or not. Of course, a combo-verifier is always free to > return some error due to bad message syntax, even if all signatures > verify (although I'd consider it cleaner to return non-DKIM errors for > non-DKIM failures.) Alessandro, While this represents a defensive posture that might be used prior to DKIM reliably returning PERMFAIL when multiple From header fields are contained within the message, it only thwarts half of the threat created by multiple From header fields. As both Charles and I have illustrated: From accou...@big-bank.com From some...@big-ips.com Subject: Audit notification This message could be sent directly, or distributed by replaying it to millions of recipients. Nothing Big-Bank.com might do with their signing mitigates this variant of the double From header field attack. The ONLY sure method is to ensure DKIM always returns PERMFAIL when multiple From header fields are detected, whether both or one of them are signed. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On Wed, 20 Oct 2010 15:27:16 +0100, Alessandro Vesely wrote: > On 20/Oct/10 13:23, Charles Lindsey wrote: >> The scam I have described involves the use, by the phisher, of a >> DKIM-signed (by himself) email with two From: headers, which is intended >> to fool verifiers into not spotting that the first signature should have >> triggered an ADSP lookup which would have revealed that the first From: >> was 'discardable'. >> >> Naturally, the phisher signs with a throaway domain that has not yet >> acquired any reputation, good or bad. >> >> Since the scam involves the use of DKIM, and since the only fix I am >> aware >> of requires a change to the DKIM standard, then it is highly relevant to >> the current discussion. > > IMHO, this issue has to be addressed refining the signing spec. For > example, the initial paragraph of section 5.4 could be modified so as > to read: But that does not address this particular scam (though it does address some other scams involving duplicated headers). Notice that in my scam it is the Bad Guy that generates the signature, and you cannot assume that a Bad Guy will obey ANY requirement imposes by 4871-bis if he believes that generating a message thsat violates that requirement will enable him to fool somebody of some sysyem somewhere. > Verifiers would then discard any From field after the first one, > whether signed or not. Of course, a combo-verifier is always free to > return some error due to bad message syntax, even if all signatures > verify (although I'd consider it cleaner to return non-DKIM errors for > non-DKIM failures.) Yes, verifiers are the only place where this scam can be caught, and they must be mandated to catch it. The precise means of catching it can be discussed, and whether they catch it on the grounds that 5322 has been violated or on the grounds that some other provision of 4871-bis has been violated is just a matter of semantics. If it makes people happier to word it so that it is not perceived as a "layering violation" then I suppose making it appear as a 4871-bis violation would be better; but I do not really like technical solutions being dictated by purely political arguments. -- 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] layer violations, was detecting header mutations after signing
On 20/Oct/10 19:48, Douglas Otis wrote: > On 10/20/10 7:27 AM, Alessandro Vesely wrote: >> For example, the initial paragraph of section 5.4 could be >> modified so as to read: >> >> The From header field MUST be signed; that is, it MUST be included >> at least once in the "h=" tag of the resulting DKIM-Signature >> header field, and SHOULD be included twice (see Section 8.14). In >> addition, the signer MUST ensure that at most one instance of the >> From field actually exists in the header. >> >> [...] >> Verifiers would then discard any From field after the first one, >> whether signed or not. > > While this represents a defensive posture that might be used prior to > DKIM reliably returning PERMFAIL when multiple From header fields are > contained within the message, it only thwarts half of the threat > created by multiple From header fields. As both Charles and I have > illustrated: > DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)... > From accou...@big-bank.com > From some...@big-ips.com > Subject: Audit notification > > > This message could be sent directly, or distributed by replaying it to > millions of recipients. In my hypothesis, a verifier would discard the 2nd "From accou...@big-bank.com", at least for hashing purposes. If they were both signed, PERMFAIL would result from a mismatch in the header-hash. If Big-Bank had been added after signing, verifiers are already authorized to delete that field from the message, according to the current PS. Isn't that enough? Further thwarts can be specified in some ADSPbis, eventually. In particular: DKIM-Signature: d=Big-IPS.com; h=from; ... From: some...@big-ips.com, accou...@big-bank.com Subject: Audit notification ... (missing Sender) > Nothing Big-Bank.com might do with their signing mitigates this variant > of the double From header field attack. The ONLY sure method is to > ensure DKIM always returns PERMFAIL when multiple From header fields are > detected, whether both or one of them are signed. I don't think the spec should impose surplus security. The minimal layer violation quoted above might be forgiven after considering the importance of the From field for DKIM. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
If Big-Bank had been added after signing, verifiers are already authorized to delete that field from the message, according to the current PS. Isn't that enough? I don't know any DKIM verifier that modifies the message, and I doubt that many people would want to use one. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 21/Oct/10 17:47, John R. Levine wrote: >> If Big-Bank had been added after signing, verifiers are already >> authorized to delete that field from the message, according to the >> current PS. Isn't that enough? > > I don't know any DKIM verifier that modifies the message, and I doubt > that many people would want to use one. Adding and removing Authentication-Results is probably the most common modification. Removing header garbage may also be fairly popular, dunno. Why do you think it's bad? At any rate, the paragraph I was referring to is The verifier MAY treat unsigned header fields with extreme skepticism, including marking them as untrusted or even deleting them before display to the end user. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> Adding and removing Authentication-Results is probably the most common > modification. Removing header garbage may also be fairly popular, dunno. > Why do you think it's bad? Adding A-R is fine. Messing with the message otherwise is more help than I want from DKIM. > At any rate, the paragraph I was referring to is > > The verifier MAY treat unsigned header fields with extreme > skepticism, including marking them as untrusted or even deleting them > before display to the end user. That's an example of the bad advice that I think we should drop from 4871bis. It does nothing to improve robustness or interoperability, just offers unsolicited advice to MUA developers. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On Oct 21, 2010, at 11:13 AM, John R. Levine wrote: >> The verifier MAY treat unsigned header fields with extreme >> skepticism, including marking them as untrusted or even deleting them >> before display to the end user. > > That's an example of the bad advice that I think we should drop from > 4871bis. It does nothing to improve robustness or interoperability, just > offers unsolicited advice to MUA developers. As this conversation has continued, I'm increasingly convinced that the only sane path forwards is to have a separate Informational or BCP document containing MUA considerations. The only question is whether that'd be restricted to considerations we've discovered while discussing DKIM (in which case it might fit in this WG), or open to all the stupid MUA tricks this community has seen since rfc733 (which should probably be a new WG.) Either way, I'd be interested in participating in the effort. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On Thu, 21 Oct 2010 16:17:18 +0100, Alessandro Vesely wrote: > DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)... >> From accou...@big-bank.com >> From some...@big-ips.com >> Subject: Audit notification >> >> > In my hypothesis, a verifier would discard the 2nd "From > accou...@big-bank.com", at least for hashing purposes. If they were > both signed, PERMFAIL would result from a mismatch in the header-hash. > If Big-Bank had been added after signing, verifiers are already > authorized to delete that field from the message, according to the > current PS. Isn't that enough? I am am not clear what you are suggesting here. Please clarify. Do you actually want to pass on to the recipient a message that was different (i.e. lacked a header) from what came in. If so -1. Or if you are saying that the varifier should hash the first From: (contrary to 4871 with requires it to hash the second), thus triggering a PERMFAIL, then you are indeed getting the right answer, but by some very weird means. > > Further thwarts can be specified in some ADSPbis, eventually. In > particular: > >DKIM-Signature: d=Big-IPS.com; h=from; ... >From: some...@big-ips.com, accou...@big-bank.com >Subject: Audit notification >... (missing Sender) Isn't that already required to have signatures from each, according to 4871? -- 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] layer violations, was detecting header mutations after signing
On 22/Oct/10 18:06, Charles Lindsey wrote: > On Thu, 21 Oct 2010 16:17:18 +0100, Alessandro Vesely > wrote: > >> DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)... >>> From accou...@big-bank.com >>> From some...@big-ips.com >>> Subject: Audit notification >>> >>> >> In my hypothesis, a verifier would discard the 2nd "From >> accou...@big-bank.com", at least for hashing purposes. If they were >> both signed, PERMFAIL would result from a mismatch in the header-hash. >>If Big-Bank had been added after signing, verifiers are already >> authorized to delete that field from the message, according to the >> current PS. Isn't that enough? > > I am am not clear what you are suggesting here. Please clarify. Do you > actually want to pass on to the recipient a message that was different > (i.e. lacked a header) from what came in. If so -1. That's one possibility. What I have in mind is an MTA filter, not a MUA extension. The same program may be authorized to silently drop whole messages to honor "discardable" policies, so I don't think it is a desecration to drop a spoofed header field when it finds one. I'd never mandate such behavior, though. It may be made available as an option when users will solicit it, if ever. > Or if you are saying that the verifier should hash the first From: > (contrary to 4871 with requires it to hash the second), thus triggering a > PERMFAIL, then you are indeed getting the right answer, but by some very > weird means. I mean first, second in a bottom-up sense. Since the verifier knows there can only be a single From, it hashes empty strings for any further one. Of course, if the verification fails, there is no way to try and discern signed fields... >> DKIM-Signature: d=Big-IPS.com; h=from; ... >> From: some...@big-ips.com, accou...@big-bank.com >> Subject: Audit notification >> ... (missing Sender) > > Isn't that already required to have signatures from each, according to > 4871? No, the signature isn't tied to the domain in the From field(s). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
