Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/6/2010 1:57 PM, MH Michael Hammer (5304) wrote: > > Apologies all for top posting. Having to use a different client due to > technical difficulties. > > Murray, I'm violently agreeing with you that it is not strictly > speaking a 4871 issue. > > Having said that, I believe that it is an issue that begs the > question... where should it land? You are correct that this is the > difference between implementation and standards. Either way, we need > to look at the outcomes of what we do. > > I'm agreeing with you that IETF-DKIM may not be the place to address > it...assuming there is a beleif that it is a problem at all. So the > first question is whether this is a problem, if the consensus is that > it isn't a problem, great...nothing more need be done. > > If the consensus is that it is a problem but not really a 4871 problem > then do we just walk away from it and leave it at that - "not our > problem"? Should we perhaps look for the place where the 5322 people > roost (I hear that working group shut down as part of IETF reorg) and > at least say... "hey, this came up in the context of 4871 and we > believe there may be some wider implications and it may be worth > considering whether 5322 should be considered in light of this". > One possibility is in a bis version of the Development, Deployment and Operations document. Tony Hansen t...@att.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
> "Dave CROCKER" wrote: >> In particular, it makes the multiple From: issue entirely >> irrelevant to DKIM. Scott Kitterman wrote: > In a normative sense, perhaps, but in real world terms, it doesn't. > Since this does away with "It's not valid 5322, so it can't > be valid DKIM", it puts the question of how implementors should > deal with such things back on the table. +1 > I'd like to see us include a general helpful note to > implementors about covering the case where a duplicate header > field is added after signing. Maybe this is an added item > for security considerations? +1. This is where I thought it would go. -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Oct 6, 2010, at 3:01 PM, Scott Kitterman wrote: > > > "Dave CROCKER" wrote: > >> >> >> On 10/6/2010 8:00 AM, Steve Atkins wrote: >>> It also changes what DKIM means, >> ... >>> Either the message has a valid DKIM signature, or it does not. If the >>> signature is valid, then the signing domain takes responsibility for the >>> message, subtly malformed or not. Just because the message lacks a Date: >>> header or has bare linefeeds doesn't mean that the signing domain isn't >>> responsible for it. >> >> THis is a particularly clean and precise attention to DKIM's job, nicely >> filtering out issues that are not part of DKIM's job. >> >> In particular, it makes the multiple From: issue entirely irrelevant to DKIM. >> > > In a normative sense, perhaps, but in real world terms, it doesn't. Since > this does away with "It's not valid 5322, so it can't be valid DKIM", it puts > the question of how implementors should deal with such things back on the > table. They can deal with it however they like - but as far as the DKIM validator is concerned there's either a valid DKIM signature, or there isn't, so it's the associated code (where DKIM plugs into the rest of the mail handling engine) that'll need to be aware of it. Were I writing the signer, though, or the code surrounding the validator I'd appreciate some mention of this gotcha in the spec so I know I need to deal with it. > I'd like to see us include a general helpful note to implementors about > covering the case where a duplicate header field is added after signing. +1 The more helpful the spec can be to implementors, the better, and this is a grubby corner. > Maybe this is an added item for security considerations? Likely, yes. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
"Dave CROCKER" wrote: > > >On 10/6/2010 8:00 AM, Steve Atkins wrote: >> It also changes what DKIM means, >... >> Either the message has a valid DKIM signature, or it does not. If the >> signature is valid, then the signing domain takes responsibility for the >> message, subtly malformed or not. Just because the message lacks a Date: >> header or has bare linefeeds doesn't mean that the signing domain isn't >> responsible for it. > >THis is a particularly clean and precise attention to DKIM's job, nicely >filtering out issues that are not part of DKIM's job. > >In particular, it makes the multiple From: issue entirely irrelevant to DKIM. > In a normative sense, perhaps, but in real world terms, it doesn't. Since this does away with "It's not valid 5322, so it can't be valid DKIM", it puts the question of how implementors should deal with such things back on the table. I'd like to see us include a general helpful note to implementors about covering the case where a duplicate header field is added after signing. Maybe this is an added item for security considerations? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Charles Lindsey wrote: > On Mon, 04 Oct 2010 23:24:11 +0100, President Obama > wrote: > >>THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE > > Interestingly, my MUA (Opera) displayed both of those From headers, But I > can quite well understand that many other MUAs don't, and even where they > do I would expect many phishees would not notice the second one. > Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=none author.d=whitehouse.gov signer.d=mipassoc.org; And for ADSP, our verifier picked up the first (top) 5322.From domain as well. Since I whitelist mipassoc.org, I get all its output. Mind you, that I had to do this twice to get a copy because I had already added a multiple 5322.From rejector script at the SMTP DATA session. I had to turn it off and repeat it to get a copy that I see here from spoofed "President Obama". So the 5321/5322 filtering layer approach works fine (but we lose interesting mail ). But I would not have done this if I was not made aware of this problem by Alt-N who discovered this security hole. And that is the main gist of this, and I don't care how the IETF cats wants to do this: Engineering AWARENESS must be added to the 4871bis. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Oct 6, 2010, at 1:22 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Mark Delany >> Sent: Tuesday, October 05, 2010 8:06 PM >> To: ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE >> >> There was an assertion in RFC4780 about "conforming emails" that must >> only have a single 2822.From header. That got lost in the translation >> to 4781 I guess. Unfortunately, 4780 failed to specify what >> "conforming" means explicitly. >> >> I also know that this WG has repeatedly stated that messages that are >> not within standard MUST fail verification. >> >> That this is not in 4871 seems to be mostly a WG assumption that >> should be made explicit. > > I think several of us thought it was in there, but on review it apparently > was indeed lost somewhere along the way. We've certainly, as I understand > it, been proceeding from that assumption for a very long time. > > I like the idea of saying so explicitly in 4871bis, and applying it both to > signers and to verifiers. +1 > I don't like the idea of being any more specific than that. That is, I don't > want to create specific text for specific cases we know about because that > means anything we don't list could be perceived as less critical. A blanket > admonishment to implementers is sufficient and appropriate. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-rfc4871bis
The diffs at http://dkim.org/specs/rfc4871-to-bis-diff.htm and the differences between 4871 and the -00 version of the draft, not the Last Call revision. Dave Crocker, can you update the diffs please? -Jim On 10/4/10 5:53 AM, Barry Leiba wrote: > Thus begins working group last call on the DKIM-base update, > draft-ietf-dkim-rfc4871bis-01: > http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis > The working group last call will run through Friday, 22 October, 2010. > > This is the version of the specification that will be advanced to > Draft Standard. Everyone please review it, and post comments/issues. > Please also post here if you've reviewed it and think it's ready to > go. > > There is one outstanding discussion on the -01 version: > http://mipassoc.org/pipermail/ietf-dkim/2010q4/014608.html > Please comment specifically on that, stating whether you agree with > the proposed change or prefer leaving the text as it is. Remember > that a change will NOT be made without support, so if you like the > change it's important to say so. > > Because this is moving the existing specification along the standards > track, substantive changes are explicitly out of scope unless someone > uncovers a serious error in the protocol. In scope are clarifications > and editorial issues. > > So: everyone please review draft-ietf-dkim-rfc4871bis-01, and comment > here by 22 October. Thanks. > > Barry, as chair > ___ > 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] signing and verifying invalid messages
On Oct 5, 2010, at 4:45 PM, Michael Thomas wrote: > On 10/05/2010 01:36 PM, John Levine wrote: >>> Still, though, it's a solution to deal with malformations to which >>> MUAs are susceptible, and not strictly a DKIM problem. >> >> Would it be a good idea to recommend in 4871bis that DKIM >> implementations should not sign or verify invalid messages? I >> cheerfully admit that I haven't thought out all the implications >> thereof. > > I'd suggest that it would be better to take that up with > rfc5822-bis since this is hardly a dkim-specific problem. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Apologies all for top posting. Having to use a different client due to technical difficulties. Murray, I'm violently agreeing with you that it is not strictly speaking a 4871 issue. Having said that, I believe that it is an issue that begs the question... where should it land? You are correct that this is the difference between implementation and standards. Either way, we need to look at the outcomes of what we do. I'm agreeing with you that IETF-DKIM may not be the place to address it...assuming there is a beleif that it is a problem at all. So the first question is whether this is a problem, if the consensus is that it isn't a problem, great...nothing more need be done. If the consensus is that it is a problem but not really a 4871 problem then do we just walk away from it and leave it at that - "not our problem"? Should we perhaps look for the place where the 5322 people roost (I hear that working group shut down as part of IETF reorg) and at least say... "hey, this came up in the context of 4871 and we believe there may be some wider implications and it may be worth considering whether 5322 should be considered in light of this". Mike -Original Message- From: ietf-dkim-boun...@mipassoc.org on behalf of Murray S. Kucherawy Sent: Wed 10/6/2010 8:13 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE > -Original Message- > From: MH Michael Hammer (5304) [mailto:mham...@ag.com] > Sent: Wednesday, October 06, 2010 12:20 AM > To: Murray S. Kucherawy; ietf-dkim@mipassoc.org > Subject: RE: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE > > So, my belief is that this is really more of a 5322 issue than a 4871 > issue. Having said that, I'm not comfortable kicking the can down the > road given that what we know, this potentially leads to abuse. I don't think that's a fair characterization. It is simply wrong to try to deal this problem in DKIM. For example, a bug in the TCP stack that causes malformed data to arrive in an application which in turn causes something visible and unexpected, possibly even something dangerous, to happen in that application is still a bug in the TCP stack and saying so puts the responsibility for resolving the problem where it belongs. There's also a practical difference between software engineering and specification. You'd be justified in deciding to make your MUA code resilient to this problem, but it's wrong for doing so to be mandated by a standards document that has nothing to do with defining the proper format of email. I believe this is a good example of a layering violation. > If the message is malformed and nonconforming then would it be > appropriate to treat the malformed message as no signature? This would > be one approach that appears consistent with 4871 yet this grinds on me > because it means we are saying that a malformed message with a > signature is the same as a conforming signature with no signature. I understand that concern, but it sounds a lot to me like trying to ascribe a different value to the former case than the latter when we don't know that they deserve different handling. (And that sounds a lot like the unresolved ADSP rathole.) To me, there's a clear boundary between what DKIM defines and what RFC5322 defines. This problem isn't on our side of that line. The RFC5322 part of the code in a verifier should detect and report that the message is malformed, and the DKIM part shouldn't even be invoked. ___ 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Wed, Oct 6, 2010 at 9:15 AM, Dave CROCKER wrote: > > > On 10/6/2010 8:00 AM, Steve Atkins wrote: >> It also changes what DKIM means, > ... >> Either the message has a valid DKIM signature, or it does not. If the >> signature is valid, then the signing domain takes responsibility for the >> message, subtly malformed or not. Just because the message lacks a Date: >> header or has bare linefeeds doesn't mean that the signing domain isn't >> responsible for it. > > THis is a particularly clean and precise attention to DKIM's job, nicely > filtering out issues that are not part of DKIM's job. > > In particular, it makes the multiple From: issue entirely irrelevant to DKIM. If you put back this piece of what Steve said: To comply with that MUST every DKIM verifier would have to include a full 5322 verifier. That's a fairly high bar. Do you come to the same conclusion? Steve, do you agree with Dave's conclusion? -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Dave CROCKER > Sent: Wednesday, October 06, 2010 7:02 AM > To: John R. Levine > Cc: DKIM List > Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE > > I find the simplicity and sufficiency of Steve's point pretty darn > appealing. > To emphasize: It's sufficient because it focuses on DKIM's actual goal > and does > not expand that scope. Can we get some proposed text? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/6/2010 9:17 AM, John R. Levine wrote: > Is it DKIM's job to make the verification fail, or is it an MUA's job to do > something reasonable with malformed messages? At one level, that's merely an implementation choice. At another level, it is a question of whether conformance enforcement MUST occur at all. The discussions have tended to assume that it MUST occur, by virtue of the DKIM requirement for 'conformant' messages. Steve's point cleverly suggests that DKIM itself can dodge the issue by -- once again -- having things simply rest on verification outcome. I find the simplicity and sufficiency of Steve's point pretty darn appealing. To emphasize: It's sufficient because it focuses on DKIM's actual goal and does not expand that scope. 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of John R. Levine > Sent: Wednesday, October 06, 2010 6:17 AM > To: Steve Atkins > Cc: DKIM List > Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE > > Recall that the original question was about a valid message with a > valid signature, which the attacker mutated by adding an extra header > that makes it an invalid message with a signature that still > mechanically verifies. > Who's responsible for it now? > > Is it DKIM's job to make the verification fail, or is it an MUA's job > to do something reasonable with malformed messages? Yeah, this just occurred to me as well. Any application (signer/verifier, spam filter, MLM, user agent, whatever, even if it has nothing to do with DKIM) that bases its actions on header fields but doesn't check for valid format first may have this vulnerability in some form. For example, an MLM that authenticates a poster based on one From: field while MUAs might render a different one has the very same problem. Trying to deal with this in 4871bis almost seems pointless when the issue is scaled that far. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
> I don't think that's a fair characterization. It is simply wrong to try to > deal this problem in DKIM. For example, a bug in the TCP stack that causes > malformed data to arrive in an application which in turn causes something > visible and unexpected, possibly even something dangerous, to happen in that > application is still a bug in the TCP stack and saying so puts the > responsibility for resolving the problem where it belongs. Yeahbut. Isn't that conflating detection with fixing? Lots of protocols have end-to-end or layer-to-layer verification to detect intervening bugs. You also well know that treating all external input with the greatest suspicion *almost* goes without saying in any programming endeavour, but particularly so in this one. I agree that a full 2822 parser is over the top and something that is unlikely to exist near verification code, but we do need to instruct verifiers to be suspicious and untrusting. What's the middle ground? Serendipitously, my early implementation refused to verify an email that had a From: prior to the signature header. The general problem is that applying authentication results to the whole payload is wrong. I don't argue this, but one could consider removing or denaturing all payload outside of the signature... Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
> -Original Message- > From: Dave CROCKER [mailto:d...@dcrocker.net] > Sent: Wednesday, October 06, 2010 6:12 AM > To: Murray S. Kucherawy > Cc: DKIM > Subject: Re: [ietf-dkim] New Version Notification for draft-ietf-dkim- > mailinglists-03 > > I suggest saying "the holder of the message is requested to discard > it". That paragraph now reads: Use of restrictive domain policies such as [ADSP] "discardable" presents an additional challenge. In that case, when a message is unsigned or the signature can no longer be verified, discarding of the message is requested. There is no exception in the policy for a message that may have been altered by an MLM, nor is there a reliable way to identify such mail. Receivers are thus advised to honor the policy and disallow the message. Does that work for people? > I'm not a huge fan of having "pro & con" in a title. > > Perhaps simply: "Signature Removal Issues". Done. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Either the message has a valid DKIM signature, or it does not. If the signature is valid, then the signing domain takes responsibility for the message, subtly malformed or not. Just because the message lacks a Date: header or has bare linefeeds doesn't mean that the signing domain isn't responsible for it. Recall that the original question was about a valid message with a valid signature, which the attacker mutated by adding an extra header that makes it an invalid message with a signature that still mechanically verifies. Who's responsible for it now? Is it DKIM's job to make the verification fail, or is it an MUA's job to do something reasonable with malformed messages? R's, John 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/6/2010 8:00 AM, Steve Atkins wrote: > It also changes what DKIM means, ... > Either the message has a valid DKIM signature, or it does not. If the > signature is valid, then the signing domain takes responsibility for the > message, subtly malformed or not. Just because the message lacks a Date: > header or has bare linefeeds doesn't mean that the signing domain isn't > responsible for it. THis is a particularly clean and precise attention to DKIM's job, nicely filtering out issues that are not part of DKIM's job. In particular, it makes the multiple From: issue entirely irrelevant to DKIM. 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] New Version Notification for draft-ietf-dkim-mailinglists-03
On 10/6/2010 8:23 AM, Murray S. Kucherawy wrote: >> Of the points I raised, I see that 4.3 still contains "the verifier is >> requested to discard the message". It is, of course, the receiver that >> actually does any discarding. > > I don't agree, at least not in the architecture I have in mind. The verifier > (e.g. a mail plugin of some kind, or an internal function of an MTA) is in a > position to conduct rejections as it sits very near the SMTP portion of a > delivery. The receiver, more likely an MUA or such, is less likely to have > any direct influence. The verifier might legitimately not be touching the message, nevermind have the authority to discard the message. Just as signing can be done by an independent service that "contracts with" the author, sender or the like, so can verifying. I suggest saying "the holder of the message is requested to discard it". >> Also, section 5.6 is still entitled "Pros and Cons of Signature Removal", >> and yet the body of that section contains no "Cons". > > The first paragraph describes a "pro" of leaving them in (i.e., enabling > preservation of chain of responsibility), and the second describes a "con" > (i.e., if that's a goal, now the MLM might have to change its behavior to do > so). The next paragraph describes a "pro" of removing them, etc. I'm not a huge fan of having "pro & con" in a title. Perhaps simply: "Signature Removal Issues". 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Oct 6, 2010, at 1:47 AM, Mark Delany wrote: >>> That this is not in 4871 seems to be mostly a WG assumption that >>> should be made explicit. >> >> I think several of us thought it was in there, but on review it apparently >> was indeed lost somewhere along the way. We've certainly, as I understand >> it, been proceeding from that assumption for a very long time. >> >> I like the idea of saying so explicitly in 4871bis, and applying it both to >> signers and to verifiers. > > Agreed. Though frankly I couldn't care less about signers. It's always > the verifier that really counts. > >> I don't like the idea of being any more specific than that. That >> is, I don't want to create specific text for specific cases we know >> about because that means anything we don't list could be perceived >> as less critical. A blanket admonishment to implementers is >> sufficient and appropriate. > > Right. We could attempt to enumerate the 1,000 edge-cases we know > today and then re-bis 4871 for the additional 1,000 edge-cases we > learn tomorrow, or we could simply say that invalid 2822 messages > MUST never verify and call it a day. To comply with that MUST every DKIM verifier would have to include a full 5322 verifier. That's a fairly high bar. It also changes what DKIM means, operationally, as I know that most email nodes don't check for well-formed emails today rather they parse them with a fairly robust parser. Either the message has a valid DKIM signature, or it does not. If the signature is valid, then the signing domain takes responsibility for the message, subtly malformed or not. Just because the message lacks a Date: header or has bare linefeeds doesn't mean that the signing domain isn't responsible for it. I don't see how adding all that functionality and cost to a DKIM verifier does anything at all to add any value. If anything, it seems it'll just increase the rate at which a DKIM verifier fails to verify a DKIM signature contrary to the expectations of both sender and recipient. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Mark Delany:
> > > That this is not in 4871 seems to be mostly a WG assumption that
> > > should be made explicit.
> >
> > I think several of us thought it was in there, but on review it apparently
> > was indeed lost somewhere along the way. We've certainly, as I understand
> > it, been proceeding from that assumption for a very long time.
> >
> > I like the idea of saying so explicitly in 4871bis, and applying it both to
> > signers and to verifiers.
>
> Agreed. Though frankly I couldn't care less about signers. It's always
> the verifier that really counts.
>
> > I don't like the idea of being any more specific than that. That
> > is, I don't want to create specific text for specific cases we know
> > about because that means anything we don't list could be perceived
> > as less critical. A blanket admonishment to implementers is
> > sufficient and appropriate.
>
> Right. We could attempt to enumerate the 1,000 edge-cases we know
> today and then re-bis 4871 for the additional 1,000 edge-cases we
> learn tomorrow, or we could simply say that invalid 2822 messages
> MUST never verify and call it a day.
+1. This makes more sense to me than trying to enumerate all the
possible effects of malformed messages on naive programs.
An explicit example may help to motivate the reader ("Invalid
messages must never verify; for example messages with multiple
Subject:, From: or To: header fields").
Wietse
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Charles Lindsey > Sent: Wednesday, October 06, 2010 3:47 AM > To: DKIM > Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple > 5322.From > > And note that pious exhortations to ensure that RFC5322 be followed, or > that MUAs should be fixed to solve this problem, are no solution. We live > in the Real World (TM), and neither of those things is going to happen, > desirable as they might be. If we can't rely on people to provide valid input when admonished to do so, then there's no point in continuing any of this work. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Charles Lindsey > Sent: Wednesday, October 06, 2010 4:36 AM > To: DKIM > Subject: Re: [ietf-dkim] New Version Notification for > draft-ietf-dkim-mailinglists-03 > > Of the points I raised, I see that 4.3 still contains "the verifier is > requested to discard the message". It is, of course, the receiver that > actually does any discarding. I don't agree, at least not in the architecture I have in mind. The verifier (e.g. a mail plugin of some kind, or an internal function of an MTA) is in a position to conduct rejections as it sits very near the SMTP portion of a delivery. The receiver, more likely an MUA or such, is less likely to have any direct influence. > Also, section 5.6 is still entitled "Pros and Cons of Signature > Removal", > and yet the body of that section contains no "Cons". The first paragraph describes a "pro" of leaving them in (i.e., enabling preservation of chain of responsibility), and the second describes a "con" (i.e., if that's a goal, now the MLM might have to change its behavior to do so). The next paragraph describes a "pro" of removing them, etc. > And also, in 5.7 s/The MLM could re-evaluate exisiting signatures/The > MLM > could re-evaluate existing signatures/. Fixed for the next version. > Evidently, my draft to allow changing the From: has not been > incorporated. > Would it be worthwhile calling a straw poll on that one? It didn't appear to have the support of rough consensus, so it wasn't included. You could indeed request such a poll to see if that's changed. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 06/Oct/10 01:59, Julian Mehnle wrote: > As I've written in my previous mail I think there's a better way to solve > this (non-)issue. Just s/Comments/From/ in that INFORMATIVE NOTE on page > 41 of 4871bis-01. +1, I quote the resulting text INFORMATIVE NOTE: A header field name need only be listed once more than the actual number of that header field in a message at the time of signing in order to prevent any further additions. For example, if there is a single From header field at the time of signing, listing From twice in the "h=" tag is sufficient to prevent any number of From header fields from being appended; it is not necessary (but is legal) to list From three or more times in the "h=" tag. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
> -Original Message- > From: MH Michael Hammer (5304) [mailto:mham...@ag.com] > Sent: Wednesday, October 06, 2010 12:20 AM > To: Murray S. Kucherawy; ietf-dkim@mipassoc.org > Subject: RE: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE > > So, my belief is that this is really more of a 5322 issue than a 4871 > issue. Having said that, I'm not comfortable kicking the can down the > road given that what we know, this potentially leads to abuse. I don't think that's a fair characterization. It is simply wrong to try to deal this problem in DKIM. For example, a bug in the TCP stack that causes malformed data to arrive in an application which in turn causes something visible and unexpected, possibly even something dangerous, to happen in that application is still a bug in the TCP stack and saying so puts the responsibility for resolving the problem where it belongs. There's also a practical difference between software engineering and specification. You'd be justified in deciding to make your MUA code resilient to this problem, but it's wrong for doing so to be mandated by a standards document that has nothing to do with defining the proper format of email. I believe this is a good example of a layering violation. > If the message is malformed and nonconforming then would it be > appropriate to treat the malformed message as no signature? This would > be one approach that appears consistent with 4871 yet this grinds on me > because it means we are saying that a malformed message with a > signature is the same as a conforming signature with no signature. I understand that concern, but it sounds a lot to me like trying to ascribe a different value to the former case than the latter when we don't know that they deserve different handling. (And that sounds a lot like the unresolved ADSP rathole.) To me, there's a clear boundary between what DKIM defines and what RFC5322 defines. This problem isn't on our side of that line. The RFC5322 part of the code in a verifier should detect and report that the message is malformed, and the DKIM part shouldn't even be invoked. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
On Mon, 04 Oct 2010 22:16:48 +0100, Murray S. Kucherawy wrote: > This version consolidates all of the minor corrections submitted to > date, as well as the more substantive things that appeared to have > consensus. Of the points I raised, I see that 4.3 still contains "the verifier is requested to discard the message". It is, of course, the receiver that actually does any discarding. Also, section 5.6 is still entitled "Pros and Cons of Signature Removal", and yet the body of that section contains no "Cons". And also, in 5.7 s/The MLM could re-evaluate exisiting signatures/The MLM could re-evaluate existing signatures/. Evidently, my draft to allow changing the From: has not been incorporated. Would it be worthwhile calling a straw poll on that one? Many of the people opposed to that seem to be imagining that I have proposes an obligatory feature for all MLMs, which my draft carefully avoided doing. Or they oppose it because then prefer their own pet solution, whereas I have proposed an additional tool for use when the pet solutions have been ignored. Also, I am still unaware of any additional security issue raised by my proposal which was not already present without it. -- 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 - Security Loop hole with Multiple 5322.From
On Mon, 04 Oct 2010 23:24:11 +0100, Hector Santos wrote: > I propose the following addition text by adding to 48721bis to address > this serious issue; > >Special Consideration for Verifying and Signing From: Header > >As an exception, header hash verification MUST be done for all >5322.From fields and not just the last one. Signing MUST be done >for all 5322.From fields found, even though RFC5322 recommends >only one 5322.From should be used. This will mitigate any >replay that prepends a new 5322.From header to a DKIM signature >valid message. Some MUAs have should to display only the first >5322.From header found. I think you need stronger wording than that. And while you are fixing the problem for From: headers, you might as well fix it for the other once-only headers (such as Subject:) while you are at it. But the prime place to fix it is in the verification. I therefore suggest the following 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, ..". Having fixed the verification process, one could then add similar wording to the signing process. NOTE that this is a serious security issue, and the present draft cannot proceed until this problem is fixed. If that means progression to Draft Standard gets delayed, then so be it. And note that pious exhortations to ensure that RFC5322 be followed, or that MUAs should be fixed to solve this problem, are no solution. We live in the Real World (TM), and neither of those things is going to happen, desirable as they might be. -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Mon, 04 Oct 2010 23:24:11 +0100, President Obama wrote: >THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE Interestingly, my MUA (Opera) displayed both of those From headers, But I can quite well understand that many other MUAs don't, and even where they do I would expect many phishees would not notice the second one. -- 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] Working group last call on draft-ietf-dkim-rfc4871bis
At 05:53 04-10-10, Barry Leiba wrote: >Thus begins working group last call on the DKIM-base update, >draft-ietf-dkim-rfc4871bis-01: The document should obsolete both RFC 4871 and RFC 5672. Please update the RFC 2821 and RFC 2822 references to RFC 5321 and RFC 5322 respectively. The reference for OpenPGP should be RFC 4880. The reference for RFC 4234 should be changed to RFC 5234. In Section 3.3: "In general, sha256 should always be used whenever possible." That text was in RFC 4871 too as part of the informative note. Could it be removed to avoid any dilution of the SHOULD in the "Signers MUST implement and SHOULD sign using rsa-sha256" sentence? In Section 3.5 for the d= tag: "Internationalized domain names MUST be encoded as described in [RFC3490]." And i= tag: "Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the "ToASCII" function." I suggest updating the first reference to RFC 5890 and RFC 5891. The second reference could be replaced by RFC 5891. I would have been more comfortable with a review for Internationalization considerations. That would expand the scope of the work to move RFC 4871 to Draft Standard though. In Section 3.6: 's= Service Type (plain-text; OPTIONAL; default is "*").' Are the SIP folks using this? :-) Section 3.6.1.1 is about compatibility with DomainKeys. Can that section be removed? In Section 7, please change the reference to RFC 5226. The initial entries in the registries come from RFC 4871. I suggest asking IANA to update the registries to point to this document. There might be a nit about the "example.podunk.ca.us" example in Section 8.13. Please update the OpenPGP reference in Section 8.4. Please use RFC 5751 as a reference for S/MIME. RFC 5451 should be a normative reference because of Section 6.2. The "X-Authentication-Results" header in Appendix A.3 should be changed. I suggest changing the 192.168.1.1 IPv4 address to 198.51.100.1. BTW, are the spaces necessary for the "h=" tags in the examples? In Appendix B.1.3: "If neither of these are possible, these roaming users will not be able to send mail signed using their own domain key." I suggest a minor change: If neither of these are possible, these roaming users will not be able to send mail signed using a signing identity associated with their domain. In Section B.1.4: "Receiving sites often wish to provide their end users with information about mail that is mediated in this fashion. Although the real efficacy of different approaches is a subject for human factors usability research, one technique that is used is for the verifying system to rewrite the From header field, to indicate the address that was verified. For example: From: John Doe via n...@news-site.com . (Note that such rewriting will break a signature, unless it is done after the verification pass is complete.)" I suggest removing that paragraph. Section 6.2 mentions how results of verification can be communicated. I suggest removing Appendix B.2.3 if the working group is of the opinion that it can produce an informational document about mailing list considerations. "signatures inside parts" should not be processed. Is it ludicrous to believe that one of the participants in this working group is the president of an unnamed country? If it is the opinion of this working group that such participation may harm the unnamed country, I suggest adding text to the Security Considerations section about messages that are not RFC 5322 compliant. On an unrelated note, unconfirmed figures slate global DKIM deployment at 19.3% and usage within the IETF at around 6.8%. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
I've cogitated on this a bit and spoken with a few knowledgeable people. I'm an operations guy and only marginally a standards wonk. So, my belief is that this is really more of a 5322 issue than a 4871 issue. Having said that, I'm not comfortable kicking the can down the road given that what we know, this potentially leads to abuse. If the message is malformed and nonconforming then would it be appropriate to treat the malformed message as no signature? This would be one approach that appears consistent with 4871 yet this grinds on me because it means we are saying that a malformed message with a signature is the same as a conforming signature with no signature. We also have to consider that verifier may be an MTA or an MUA. The implications (operationally) are different for each case. It has also been pointed out to me that a mail implementation may try to fix a malformed message. Regardless of my belief that this is a 5322 issue, my personal preference would be for DKIM verifiers to not validate malformed messages with an outcome of something along the lines of "unable to validate due to malformed message". I view this as different than DKIM none. This is perhaps more of an operations perspective. Just a few poorly expressed thoughts and lacking a concrete recommendation that is actionable. Mike > -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy > Sent: Wednesday, October 06, 2010 1:22 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE > > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Mark Delany > > Sent: Tuesday, October 05, 2010 8:06 PM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE > > > > There was an assertion in RFC4780 about "conforming emails" that must > > only have a single 2822.From header. That got lost in the translation > > to 4781 I guess. Unfortunately, 4780 failed to specify what > > "conforming" means explicitly. > > > > I also know that this WG has repeatedly stated that messages that are > > not within standard MUST fail verification. > > > > That this is not in 4871 seems to be mostly a WG assumption that > > should be made explicit. > > I think several of us thought it was in there, but on review it apparently > was indeed lost somewhere along the way. We've certainly, as I understand > it, been proceeding from that assumption for a very long time. > > I like the idea of saying so explicitly in 4871bis, and applying it both > to signers and to verifiers. > > I don't like the idea of being any more specific than that. That is, I > don't want to create specific text for specific cases we know about > because that means anything we don't list could be perceived as less > critical. A blanket admonishment to implementers is sufficient and > appropriate. > > ___ > 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
