Re: [ietf-dkim] detecting header mutations after signing
--On 20 October 2010 15:42:32 -0700 Douglas Otis do...@mail-abuse.org wrote: But, hey, I'm on your side here. I think we should put a warning in the RFC so that vendors are informed that they need to be sure they're highlighting the correct header. Why? There would not be a problem when DKIM verification results return PERMFAIL when there is any doubt which From header field might be selected when more than one exists. Well, that would be even better. But that's a change to the spec. If the spec were changed, I'd be happy about that. In the mean time, we need to warn implementers about the security risks that we've identified. -Doug ___ 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] detecting header mutations after signing
On Wed, 20 Oct 2010 18:32:44 +0100, John R. Levine jo...@iecc.com wrote: A reputation service can only say that a domain is BAD GOOD or NO EVIDENCE AVAILABLE EITHER WAY. I think the last case has to be treated pretty much like GOOD, otherwise newcomers to the internet will never even get their messages accepted. Heck, no. Treat it like there's no signature at all, and filter it like one does now. So if I (being a perfectly honest citizen) create some brand new internet service, which needs to be secure; and if I secure it by signing all emails sent to my clients plus declaring an ADSP policy of 'discardable', then you want all messages sent to my clients on day 1 of the service to be discarded at my clients' boundaries because, not yet having established any reputation, my messages are to be treated as unsigned, and hence discarded in accordance with my ADSP setting And it the reputation services discover that all mails sent from my domain are being discarded, they will start to create a Bad reputation for me, instead of the Good one that I hoped to acquire as my new service became known. No, lack of reputation has to be treated as entirely neutral. Bad reputations have to be earned by performing Bad deeds. -- 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] detecting header mutations after signing
On Tue, 19 Oct 2010 16:23:39 +0100, John R. Levine jo...@iecc.com wrote: good signature - good message. Don't you mean Good signature - authenticated message (that is, someone accepts responsibility) I think it needs to mean Good signature - authenticated message (that is, someone accepts responsibility, where someone is identifiable at least to the extent of being or not being the domain in whatever From: is shown). When I said good, I meant credible, not just one that mechanically validates. I hope that we all agree that a signature from a domain about which one knows nothing is not usefully different from no signature at all. A reputation service can only say that a domain is BAD GOOD or NO EVIDENCE AVAILABLE EITHER WAY. I think the last case has to be treated pretty much like GOOD, otherwise newcomers to the internet will never even get their messages accepted. There might be some merit in a repuation service responding with DOMAIN CREATED WITHIN THE LAST 15 MINUTES although even that should have been Domain first used within the last 15 minutes, except I cannot see how a reputation service coulr know that. -- 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] detecting header mutations after signing
On Tue, 19 Oct 2010 14:18:45 +0100, Wietse Venema wie...@porcupine.org wrote: My preference would be to enforce this within the existing protocol (that is: send h=from:from:subject:subject...), But that only copes with some of the scams that are possible; for full protection you need ... but I could live with hard-coded checks for unsigned single-instance RFC 5322 and MIME headers (that is: no DKIM PASS for unsigned extra From, Subject, MIME-Version, Content-type, etc. headers). -- 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] detecting header mutations after signing
--On 20 October 2010 15:12:47 +0100 Charles Lindsey c...@clerew.man.ac.uk wrote: When I said good, I meant credible, not just one that mechanically validates. I hope that we all agree that a signature from a domain about which one knows nothing is not usefully different from no signature at all. A reputation service can only say that a domain is BAD GOOD or NO EVIDENCE AVAILABLE EITHER WAY. Actually, a reputation service could offer a score that's more subtle than good/bad. And, it could offer address reputation rather than domain reputation. That would be far more suitable for domains like the large email service providers, which have a mix of good and bad users. http://www.dkim-reputation.org/start/ offers address based reputation service. I've not used the service, so can't vouch for it. -- 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] detecting header mutations after signing
--On 19 October 2010 07:31:58 -0700 Michael Thomas m...@mtcc.com wrote: On 10/19/2010 06:18 AM, Wietse Venema wrote: valid signature + good signer + no suspicious unsigned content - good message Has nobody learned that good signers from good authors can still be evil? I mean come on, people, bot'd machines? This is horrible advice. s/unsigned/; and this works. Mike Well, everything's relative. If we can get to the point where a bot'd machine can only send email From: it's real owner, that'll be a huge improvement on the current situation. At that point, we can start to pressure the real owner into fixing their machine (say, by emailing them or their domain support, or by blacklisting their email) -- 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] detecting header mutations after signing
--On 19 October 2010 11:35:53 -0400 John R. Levine jo...@iecc.com wrote: True, but there already are UI designs that indicate when a From header is DKIM verified. So you're saying that all a spammer has to do is to put on a throwaway domain's signature, and the MUA will highlight at least parts of the message with green goodness? Surely our understanding of domain reputation is better than that. I believe that's the basis of this whole discussion, isn't it. The point is that the MUA tells you whether the header was signed, and leaves you to apply the domain or address reputation. I think that's a step forward. At least, it is when I know the purported author. And, surely I'm better at assigning reputation to -say- my brother than any automated system is. But, hey, I'm on your side here. I think we should put a warning in the RFC so that vendors are informed that they need to be sure they're highlighting the correct header. Any chance you can tell me which MUAs have this misfeature, so I can tell people to return them and ask for a refund? R's, John -- 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] detecting header mutations after signing
A reputation service can only say that a domain is BAD GOOD or NO EVIDENCE AVAILABLE EITHER WAY. I think the last case has to be treated pretty much like GOOD, otherwise newcomers to the internet will never even get their messages accepted. Heck, no. Treat it like there's no signature at all, and filter it like one does now. I hope the difference between whitelisting and filtering doesn't require further explanation. 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] detecting header mutations after signing
On 10/20/10 8:10 AM, Ian Eiloart wrote: --On 19 October 2010 11:35:53 -0400 John R. Levine jo...@iecc.com wrote: True, but there already are UI designs that indicate when a From header is DKIM verified. So you're saying that all a spammer has to do is to put on a throwaway domain's signature, and the MUA will highlight at least parts of the message with green goodness? Surely our understanding of domain reputation is better than that. I believe that's the basis of this whole discussion, isn't it. The point is that the MUA tells you whether the header was signed, and leaves you to apply the domain or address reputation. I think that's a step forward. At least, it is when I know the purported author. And, surely I'm better at assigning reputation to -say- my brother than any automated system is. DKIM does not authenticate the From header field, however it provides authenticated DKIM domains that are, at a minimum, bound with the From header field. When the DKIM domain is Big-Bank.com, and you or your system trusts this domain, there should also be less concern related to whether a From header field containing accou...@big-bank.com offers deceptive information. But, hey, I'm on your side here. I think we should put a warning in the RFC so that vendors are informed that they need to be sure they're highlighting the correct header. Why? There would not be a problem when DKIM verification results return PERMFAIL when there is any doubt which From header field might be selected when more than one exists. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John Levine wrote: OTOH, we already have a SHOULD that tells MUA writers to splatter the d= field somewhere in the GUI where the user can't ignore it Ugh, you're right. Now that I look at it, I'd like to completely delete Appendix D, since it says some things that are just wrong, i.e. language that implies that the signature contains someone's email address, and some stuff that hasn't been implemented and quite possibly never will be, e.g., highlighting the signed parts of the message. Personally, I have no idea which signing domains are credible and which aren't, and I have no interest in my MUA showing them to me so I can try and guess. That's much better handled in the MTA or MDA, using something like VBR to check the signer's credibility. John, Please take a step back (into the balcony) to reflect on what you are saying here. I personally appreciated your recent input in the threads hitting the right notes. I think Appendix D touches base with some impractical MUA considerations regarding different bits - its either good or bad. I've written several (long) drafts of a response and concluded with something I believe we already discussed in years past: MUA trust of the Backend Information provided. Its a simplistic statement but hopefully one can see based on the realistic backend/MUA operations. Overall, we have two types of MUAs: - Online MUA with complete backend control of what is rendered based on a suite of backend available information. - Offline MUA where the backend has to pass information to the MUA in a common standard data format we call RFC 5322. Lets use gmail or yahoo as an example as you once reference these as quick ways to test verify signature generations. These were online MUA methods and both systems had control on how to convey valid DKIM signatures with their online GUI display. But as you are aware, the user can also setup his account to pick yup mail via POP3 (or IMAP) for users who wish to use an RFC-based offline mail reader (like Outlook, Thunderbird, etc). In this case, we have yet to developed a way to convey the same online experience in a time-shifted offline manner. Gmail can only pass the A-R (Authentication-Results) header. But I believe we concluded long ago the general MUA can not trust headers like A-R. The offline MUA developer is not going adding support for A-R unless he is 100% sure it is a trusted header generated by the back end host. ISP, ESP, etc. If the offline MUA does not get what is needed from an authenticated mail pickup, then it may redundantly repeat the DKIM verification. It might do this anyway to cover the market of non-DKIM supportive mail pickup host. Overall, the point is the backend has complete control of what to display for its online access user interfaces. But for the offline MUA, there wasn't muuc we done to give them trust and avoid repeating the DKIM verification. -- 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] detecting header mutations after signing
On 19/Oct/10 04:55, John Levine wrote: There's a strong correlation between badly structured emails (SMTP, MIME, HTML) and email that the recipient doesn't want to see. You're right, but I think that's largely orthogonal to DKIM. If a message has a good signature from a credible signer, I expect I'd want to show it to the user even if it had structure problems. I'd like to make the trust model as simple as possible, preferably good signature - good message rather than good signature + tidy SMTP + correct headers + unobjectionable HTML + favorable phase of moon - good message +1. That's why I don't think much of Jim's SHOULD language, recommending stiff syntax validation in response to a threat whose only known trait is technical feasibility. Verifiers are already authorized to react with extreme skepticism. We can better their diagnostic capabilities, but cannot recommend a therapy that we never tried. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of John Levine Sent: Monday, October 18, 2010 10:55 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing There's a strong correlation between badly structured emails (SMTP, MIME, HTML) and email that the recipient doesn't want to see. You're right, but I think that's largely orthogonal to DKIM. If a message has a good signature from a credible signer, I expect I'd want to show it to the user even if it had structure problems. I'd like to make the trust model as simple as possible, preferably good signature - good messsage Look further down the email at your comment Personally, I have no idea which signing domains are credible and which aren't... and then explain the leap to good signature - good message. Don't you mean Good signature - authenticated message (that is, someone accepts responsibility) rather than good signature + tidy SMTP + correct headers + unobjectionable HTML + favorable phase of moon - good message If a message doesn't have a credible signature, then you still use the structure heuristics. OTOH, we already have a SHOULD that tells MUA writers to splatter the d= field somewhere in the GUI where the user can't ignore it Ugh, you're right. Now that I look at it, I'd like to completely delete Appendix D, since it says some things that are just wrong, i.e. language that implies that the signature contains someone's email address, and some stuff that hasn't been implemented and quite possibly never will be, e.g., highlighting the signed parts of the message. Personally, I have no idea which signing domains are credible and which aren't, and I have no interest in my MUA showing them to me so I can try and guess. That's much better handled in the MTA or MDA, using something like VBR to check the signer's credibility. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/19/2010 06:18 AM, Wietse Venema wrote: valid signature + good signer + no suspicious unsigned content - good message Has nobody learned that good signers from good authors can still be evil? I mean come on, people, bot'd machines? This is horrible advice. s/unsigned/; and this works. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
good signature - good message. Don't you mean Good signature - authenticated message (that is, someone accepts responsibility) When I said good, I meant credible, not just one that mechanically validates. I hope that we all agree that a signature from a domain about which one knows nothing is not usefully different from no signature at all. 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] detecting header mutations after signing
True, but there already are UI designs that indicate when a From header is DKIM verified. So you're saying that all a spammer has to do is to put on a throwaway domain's signature, and the MUA will highlight at least parts of the message with green goodness? Surely our understanding of domain reputation is better than that. Any chance you can tell me which MUAs have this misfeature, so I can tell people to return them and ask for a refund? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: John Levine [mailto:jo...@iecc.com] Sent: Monday, October 18, 2010 5:50 PM To: ietf-dkim@mipassoc.org Cc: Murray S. Kucherawy Subject: Re: [ietf-dkim] detecting header mutations after signing Why do we think such a sorting module can't/won't have the intelligence to do the RFC5322 Section 3.6 checks? Sheesh, I think I've answered this at least three times now. Well gosh, I sure do appreciate your patience in dealing with the rest of us fools that might not share your view or have something else to offer. In the absence of a DKIM signature, there is no reason to worry about doubled headers since there is no reason to think one is real and the other fake. They're only a threat when they provide a way to make a DKIM signed message render differently from what the signer expected. But some agents, maybe even many of them, do via some mechanism decide that one is the real one and make a filtering decision based on it. It might be as simple as an MUA electing to render the first one it finds, for some value of first. As I've also said before, either DKIM has a SHOULD about doubled headers, or the equivalent advice goes into the folklore about what you have to do make DKIM useful. Personally, I think the latter would be a cruel joke on future implementors, but apparently other people feel differently. And just like when you said it the first time, I still don't share your view that a Security Considerations section of a Draft Standard document can be classified as folklore. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: i...@sussex.ac.uk [mailto:i...@sussex.ac.uk] Sent: Tuesday, October 19, 2010 2:59 AM To: John R. Levine; Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing True, but there already are UI designs that indicate when a From header is DKIM verified. Hopefully, the indicator will only be displayed with the correct From header, and only when at least a substantial part of the body is verified, along with the other displayed headers. Yeah. Now if only there was a place in the RFC that would be appropriate to contain informative advice about how to process DKIM results... ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Sheesh, I think I've answered this at least three times now. Well gosh, I sure do appreciate your patience in dealing with the rest of us fools that might not share your view or have something else to offer. Sorry. But I could swear we had this exact exchange before. In the absence of a DKIM signature, there is no reason to worry about doubled headers since there is no reason to think one is real and the other fake. They're only a threat when they provide a way to make a DKIM signed message render differently from what the signer expected. But some agents, maybe even many of them, do via some mechanism decide that one is the real one and make a filtering decision based on it. It might be as simple as an MUA electing to render the first one it finds, for some value of first. Aha! We did have this discussion. I reported that tried a few MUAs and found that some MUAs render the first one, some render the last. Each MUA appears to be internally consistent but there's no consistency from one MUA to another. To me this says that at this point nobody's considered doubled headers to be other than a bug, since they haven't provided a way to do anything antisocial--they don't evade filters and they don't crash MUAs. It's only a threat when, well, you know. Re Security Considerations, it's better than nothing, but it would be nice to put in concrete advice rather than a general warning, i.e., verifiers SHOULD NOT verify a signature on a message that contains a mix of signed and unsigned copies of a header that is supposed to occur only once, rather than bad guys can do bad things by adding extra headers to signed messages. I believe the SHOULD NOT plugs the hole without changing DKIM's behavior on any valid message, but I want to finish coding it and try it for a while to see what else I've missed. 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] detecting header mutations after signing
On 10/19/2010 1:33 PM, John R. Levine wrote: Re Security Considerations, it's better than nothing, Not necessarily. The current issue is part of a much larger one. We will not be dealing with that larger set of security details because it is out of scope. Dealing with a narrow piece of it, in a very narrow specification, gives the patina of dealing with something, without the substance. So it establishes a false sense of resolving a security issue. 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] detecting header mutations after signing
What we have is a reproducible issue that can add stuff without breaking an existing signature (if I am following along correctly) so that an email CAN show up in a MUA and be heralded as a DKIM VALIDATED signature as well as promote the added stuff My opinion is to look at how to not allow a signature to validate after someone has added stuff and making sure that the DKIM current validators are aware of this exploit until a fix is proposed thanks, Bill On Oct 19, 2010, at 1:25 PM, Murray S. Kucherawy wrote: -Original Message- From: John Levine [mailto:jo...@iecc.com] Sent: Monday, October 18, 2010 5:50 PM To: ietf-dkim@mipassoc.org Cc: Murray S. Kucherawy Subject: Re: [ietf-dkim] detecting header mutations after signing Why do we think such a sorting module can't/won't have the intelligence to do the RFC5322 Section 3.6 checks? Sheesh, I think I've answered this at least three times now. Well gosh, I sure do appreciate your patience in dealing with the rest of us fools that might not share your view or have something else to offer. In the absence of a DKIM signature, there is no reason to worry about doubled headers since there is no reason to think one is real and the other fake. They're only a threat when they provide a way to make a DKIM signed message render differently from what the signer expected. But some agents, maybe even many of them, do via some mechanism decide that one is the real one and make a filtering decision based on it. It might be as simple as an MUA electing to render the first one it finds, for some value of first. As I've also said before, either DKIM has a SHOULD about doubled headers, or the equivalent advice goes into the folklore about what you have to do make DKIM useful. Personally, I think the latter would be a cruel joke on future implementors, but apparently other people feel differently. And just like when you said it the first time, I still don't share your view that a Security Considerations section of a Draft Standard document can be classified as folklore. ___ 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] detecting header mutations after signing
On 10/19/10 1:45 PM, Dave CROCKER wrote: On 10/19/2010 1:33 PM, John R. Levine wrote: Re Security Considerations, it's better than nothing, Not necessarily. The current issue is part of a much larger one. We will not be dealing with that larger set of security details because it is out of scope. Dealing with a narrow piece of it, in a very narrow specification, gives the patina of dealing with something, without the substance. So it establishes a false sense of resolving a security issue. Ignoring pre-pended From headers in DKIM's verification process has demonstrated trust established by a DKIM signature can then be exploited. This ONLY affects the DKIM trust being established. While this issue should not be resolved with /just/ changes to Security Considerations, any update to DKIM must correct this serious deficiency. DKIM does not permit assignment of negative reputations for undesired messages when RCPT TO parameters are not apparent within the message. This leaves the narrow use of DKIM being for establishing trust from known good sources. This trust MUST NOT be extended to messages having pre-pended From header fields, where the wrong field might be selected for filtering or display. After all, ONLY the From header field is assured by DKIM as being bound to the message. Consumers of DKIM results should not need to understand the intricacies of the DKIM process with respect to the From header field. In addition, the Subject of this thread is not correct. The issue is not related to either header or body mutations. The issue is related to a From header fields being pre-pended to a signed message, where evaluations of such a message can ONLY safely return PERMFAIL. Returning anything else is likely to provide recipients a false sense of security. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Fri, 15 Oct 2010 17:50:33 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, October 15, 2010 7:30 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing And if we are not going to fix ADSP (yet), then the only way we can stop that particular exploit is to fix DKIM. Arguing that ADSP is a completely separate discussion will achieve nothing. If that's consensus, then we're on the slippery slope of fixing DKIM to deal with flaws at all layers above it. And we'll never be done. If you want to fix ADSP first, then let us hear your proposals, and when we have fixed it we can then go back to finalizing 4871-bis. But may I ramind you that you alreade said: On Fri, 15 Oct 2010 17:46:56 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: The current effort has everything to do with moving DKIM to draft standard, and nothing at all to do with handling ADSP issues. In which case we have no option but to fix it in DKIM. -- 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] detecting header mutations after signing
On 10/18/2010 3:31 AM, Ian Eiloart wrote: --On 15 October 2010 11:53:51 -0400 Dave CROCKERd...@dcrocker.net wrote: On 10/15/2010 11:40 AM, Mark Delany wrote: Well, if you want to introduce semantic changes why not just change the meaning of h=from:to: to be semantically identical to h=from:from:to:to: This would mean that it is /never/ ok to add a listed header field after signing. Adding would /always/ break the signature. I assumed that the proposal applied only to headers rfc5322 says cannot be duplicated. That is a constraint that was not stated. Specifications do not allow assuming. As offered, the modification would have the effect that I stated and /not/ the one you state. 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] detecting header mutations after signing
On Mon, Oct 18, 2010 at 06:07:15AM -0700, Dave CROCKER allegedly wrote: On 10/18/2010 3:31 AM, Ian Eiloart wrote: --On 15 October 2010 11:53:51 -0400 Dave CROCKERd...@dcrocker.net wrote: On 10/15/2010 11:40 AM, Mark Delany wrote: Well, if you want to introduce semantic changes why not just change the meaning of h=from:to: to be semantically identical to h=from:from:to:to: This would mean that it is /never/ ok to add a listed header field after signing. Adding would /always/ break the signature. I assumed that the proposal applied only to headers rfc5322 says cannot be duplicated. That is a constraint that was not stated. It is now. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Well, if you want to introduce semantic changes why not just change the meaning of h=from:to: to be semantically identical to h=from:from:to:to: ... I assumed that the proposal applied only to headers rfc5322 says cannot be duplicated. That is a constraint that was not stated. It is now. This probably requires a substantive change to the specification. I'm not clear whether it would force the spec to re-cycle at Proposed. 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] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of MH Michael Hammer (5304) Sent: Saturday, October 16, 2010 10:43 AM To: Wietse Venema; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing We are left in the realm of the operation was a success but the patient died. If this where we want to be? That's a pretty neat framing of the question. What is the value proposition that DKIM offers that incentivizes people to adopt it? I'll take a crack at that: DKIM offers the MUA enough data to know what parts of a message to be rendered can be considered valid inasmuch as someone (the signer) took responsibility for it. How it's rendered is up to the MUA. We certainly, and probably should, provide some advice in this area to MUA implementations, but we haven't the teeth to demand it. I am not suggesting that we boil the ocean. I am suggesting that we can realistically address this class of problem without having to fix the world. Failure to address it significantly alters the value proposition of DKIM. in a negative manner. Since we're all big on analogies, how about: Experian can give you the rating of someone applying for credit. Whether or not you pay attention to that information in making your credit decision is entirely up to you. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
What is the value proposition that DKIM offers that incentivizes people to adopt it? I'll take a crack at that: DKIM offers the MUA enough data to know what parts of a message to be rendered can be considered valid inasmuch as someone (the signer) took responsibility for it. I have to disagree. DKIM offers the ability for a domain to take responsibility for a message. A signing domain with any sense will sign messages in a way that ensures that they don't get smashed between the time they're signed and the time they're rendered, so the whole thing is valid. While it's certainly possible to create signatures that don't include the To:, Date: or Subject: lines and have l=0, I doubt that a signer who did that would earn a reputation good enough for anyone to care whether they signed a message or not. Also, although I certainly do not purport to be a whiz at UI design, it's hard to think of a more pessimal UI design than one that tries to tell Grandma what parts of a message to believe with changing colors or fonts in various parts of the message window. She can barely grasp the difference between a green bar SSL page and one with no SSL. I don't want to mess with the MUA at all, but rather use DKIM to help decide what messages to show her and which messages to consign to the junk folder. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Monday, October 18, 2010 5:25 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Also, although I certainly do not purport to be a whiz at UI design, it's hard to think of a more pessimal UI design than one that tries to tell Grandma what parts of a message to believe with changing colors or fonts in various parts of the message window. She can barely grasp the difference between a green bar SSL page and one with no SSL. I don't want to mess with the MUA at all, but rather use DKIM to help decide what messages to show her and which messages to consign to the junk folder. Why do we think such a sorting module can't/won't have the intelligence to do the RFC5322 Section 3.6 checks? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
difference between a green bar SSL page and one with no SSL. I don't want to mess with the MUA at all, but rather use DKIM to help decide what messages to show her and which messages to consign to the junk folder. Why do we think such a sorting module can't/won't have the intelligence to do the RFC5322 Section 3.6 checks? Sheesh, I think I've answered this at least three times now. In the absence of a DKIM signature, there is no reason to worry about doubled headers since there is no reason to think one is real and the other fake. They're only a threat when they provide a way to make a DKIM signed message render differently from what the signer expected. No DKIM - no threat - no special treatment. I don't know how to make this any clearer. That's why sorting modules don't worry about it now. As I've also said before, either DKIM has a SHOULD about doubled headers, or the equivalent advice goes into the folklore about what you have to do make DKIM useful. Personally, I think the latter would be a cruel joke on future implementors, but apparently other people feel differently. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Oct 18, 2010, at 5:50 PM, John Levine wrote: difference between a green bar SSL page and one with no SSL. I don't want to mess with the MUA at all, but rather use DKIM to help decide what messages to show her and which messages to consign to the junk folder. Why do we think such a sorting module can't/won't have the intelligence to do the RFC5322 Section 3.6 checks? Sheesh, I think I've answered this at least three times now. In the absence of a DKIM signature, there is no reason to worry about doubled headers since there is no reason to think one is real and the other fake. They're only a threat when they provide a way to make a DKIM signed message render differently from what the signer expected. A threat isn't the only way to consider this. There's a strong correlation between badly structured emails (SMTP, MIME, HTML) and email that the recipient doesn't want to see. No DKIM - no threat - no special treatment. I don't know how to make this any clearer. That's why sorting modules don't worry about it now. As I've also said before, either DKIM has a SHOULD about doubled headers, or the equivalent advice goes into the folklore about what you have to do make DKIM useful. Personally, I think the latter would be a cruel joke on future implementors, but apparently other people feel differently. I think even a SHOULD might be a bit strong, but it's certainly worth mentioning as something that an architectural module either upstream or downstream of the DKIM verifier should be aware of. OTOH, we already have a SHOULD that tells MUA writers to splatter the d= field somewhere in the GUI where the user can't ignore it, so we're a long way away from anything like a sensible separation of responsibility in the DKIM spec already. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
There's a strong correlation between badly structured emails (SMTP, MIME, HTML) and email that the recipient doesn't want to see. You're right, but I think that's largely orthogonal to DKIM. If a message has a good signature from a credible signer, I expect I'd want to show it to the user even if it had structure problems. I'd like to make the trust model as simple as possible, preferably good signature - good messsage rather than good signature + tidy SMTP + correct headers + unobjectionable HTML + favorable phase of moon - good message If a message doesn't have a credible signature, then you still use the structure heuristics. OTOH, we already have a SHOULD that tells MUA writers to splatter the d= field somewhere in the GUI where the user can't ignore it Ugh, you're right. Now that I look at it, I'd like to completely delete Appendix D, since it says some things that are just wrong, i.e. language that implies that the signature contains someone's email address, and some stuff that hasn't been implemented and quite possibly never will be, e.g., highlighting the signed parts of the message. Personally, I have no idea which signing domains are credible and which aren't, and I have no interest in my MUA showing them to me so I can try and guess. That's much better handled in the MTA or MDA, using something like VBR to check the signer's credibility. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Wietse Venema Sent: Friday, October 15, 2010 5:10 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing MH Michael Hammer (5304): -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Friday, October 15, 2010 11:59 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I'm sure this was discussed before, but perhaps a refresher helps. How would the DKIM validator know the difference between: A: The message had a valid signature, but it was broken after signing. B: The message is a forgery with a bogus signature. If the DKIM validator cannot make that distinction, then the bad guys will do B and the validator will treat it as A. Wietse Multiple headers are a specific class of problem. The signature is not, in fact, broken. It validates. The described attack actually leverages this. We are left in the realm of the operation was a success but the patient died. If this where we want to be? How often do we see multiple From headers where the From was added (as opposed to the original From was modified) after the message was signed? How often do we see this without malicious intent in the wild? Same question for other headers? What is the value proposition that DKIM offers that incentivizes people to adopt it? I remember similar discussions back in the 2004 timeframe when we didn't have practical experience with DKIM. This theme was in fact touched on at the Marketing DKIM dinner that Dave organized after the FTC workshop in DC. I am not suggesting that we boil the ocean. I am suggesting that we can realistically address this class of problem without having to fix the world. Failure to address it significantly alters the value proposition of DKIM. in a negative manner. I've never been happy with the choice to have fails to validate == no signature. This is what invites your question about A or B. Your question A begs the question of how the signature was broken. If we never see a certain type of brokenness in the wild in normal usage but only (potentially) see it in abusive usage, why would we not recognize and address this? Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Thu, 14 Oct 2010 19:01:17 +0100, Alessandro Vesely ves...@tana.it wrote: On 13/Oct/10 20:45, Scott Kitterman wrote: On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote: If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem? If the DKIM signature doesn't verify after signed headers have been altered, then it's not. Correct. And the way that it fails to verify is h=from:from. That only works when the signature is created by the Good Guys. When the Bad Guys create signatures (using a throwaway domain), they will conveniently forget to do h=from:from. The only way that DKIM can consistently account for this exploit is by amending section 5.5 Recommended Signature Content, and spell what fields MUST/SHOULD be duplicated in the h= tag. No, the only way is to amend DKIM so that the verifiers MUST/SHOULD take the right action. -- 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] detecting header mutations after signing
On Thu, 14 Oct 2010 17:30:42 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Thursday, October 14, 2010 7:32 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing But if there is no valid DKIM signature, the verifier will proceed to do ADSP checks, and will reject the message if it sees that ebay.com is 'discardable'. ADSP is a completely separate discussion. We're talking about advancing DKIM here, not both of them. ADSP is largely the cause of our troubles. But since we are not going to change it (just yet), we have to make DKIM work as well as it can with the current ADSP. And the Bad Guys are perfectly well aware of what ADSP does and how it is deployed by the Good Guys. And so if they find they can circumvent ADSP by signing messages with their own throwaway domains, then they will do so. And if we are not going to fix ADSP (yet), then the only way we can stop that particular exploit is to fix DKIM. Arguing that ADSP is a completely separate discussion will achieve nothing. -- 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] detecting header mutations after signing
On 14/Oct/10 20:09, Mark Delany wrote: On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote: On 13/Oct/10 20:45, Scott Kitterman wrote: On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote: If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem? If the DKIM signature doesn't verify after signed headers have been altered, then it's not. Correct. And the way that it fails to verify is h=from:from. Which strikes me as an ugly hack. Given that most headers should only occur once and given that a lot of signers sign most headers doesn't this suggestion degenerate to h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id? Yes, it does. The only question is to devise normative statements correctly, e.g. MUST duplicate From, SHOULD duplicate the rest. This is _not_ a kludge. It is how DKIM signing works (Section 5.4). Are we worried about wasting 100~200 bytes per signature? (I get ~4Kb headers nowadays, so that is about 3% of it.) Introducing an abbreviation --e.g. an h2 tag-- is considerably clearer from an algorithm developer's POV. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 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 7:30 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing And if we are not going to fix ADSP (yet), then the only way we can stop that particular exploit is to fix DKIM. Arguing that ADSP is a completely separate discussion will achieve nothing. If that's consensus, then we're on the slippery slope of fixing DKIM to deal with flaws at all layers above it. And we'll never be done. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Oct 15, 2010, at 9:50 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, October 15, 2010 7:30 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing And if we are not going to fix ADSP (yet), then the only way we can stop that particular exploit is to fix DKIM. Arguing that ADSP is a completely separate discussion will achieve nothing. If that's consensus, then we're on the slippery slope of fixing DKIM to deal with flaws at all layers above it. And we'll never be done. +1. Any bug fixes for ADSP need to be done at the ADSP level. If there's a bug that needs fixing at the DKIM level then if should be something that clearly needs fixing based on DKIM usage. (And I think that the very narrow case of messages that violate 5322 through multiple headers *may* be such, but any justification of that relying on ADSP isn't helpful). Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Steve, I believe its about protocol consistency. While the main focus is DKIM progress, its issues and resolutions are related to ADSP as well as its a WG product as well. For example, ADSP implementations now know that they need to make there is only one 5322.From as well. Like most software, when it has a header = GetMailHeader(From:) it is not expected to return a list of headers, but a single entry and that generally done by finding the first one. In short, we have marked this on the WG to-do list for ADSP updates if any, and implementations now know what they need to add to their ADSP support. Its all about synergism. We can't just completely ignore it and then miss something that needs to be done later. -- HLS Steve Atkins wrote: On Oct 15, 2010, at 9:50 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, October 15, 2010 7:30 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing And if we are not going to fix ADSP (yet), then the only way we can stop that particular exploit is to fix DKIM. Arguing that ADSP is a completely separate discussion will achieve nothing. If that's consensus, then we're on the slippery slope of fixing DKIM to deal with flaws at all layers above it. And we'll never be done. +1. Any bug fixes for ADSP need to be done at the ADSP level. If there's a bug that needs fixing at the DKIM level then if should be something that clearly needs fixing based on DKIM usage. (And I think that the very narrow case of messages that violate 5322 through multiple headers *may* be such, but any justification of that relying on ADSP isn't helpful). Cheers, Steve ___ 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] detecting header mutations after signing
Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... On Oct 15, 2010, at 11:53 AM, Dave CROCKER wrote: On 10/15/2010 11:40 AM, Mark Delany wrote: Well, if you want to introduce semantic changes why not just change the meaning of h=from:to: to be semantically identical to h=from:from:to:to: This would mean that it is /never/ ok to add a listed header field after signing. Adding would /always/ break the signature. That's a very powerful semantic change. I've no idea that it's completely safe. It seems like it ought to be, but I worry about corner cases. d/ ps. I would expect such a semantic change to require re-cycling the spec at Proposed. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Friday, October 15, 2010 11:59 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I recognize what Murray and Dave have said on this point but it grates. The reason we are going through the exercise of creating a stable identifier associated with a signing domain is because we perceive some value whether it be policy associated with the stable identifier or reputation associated with the stable identifier. To simply ignore this and say it is the same as if it wasn't signed is kind of like saying 0=1. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Oct 15, 2010, at 1:51 PM, MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Friday, October 15, 2010 11:59 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. How can the system be gamed by breaking a signature in a way that it can't be by removing the signature? A concrete example might make it clearer what the concern is. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. Nobody is saying it should be ignored, I don't think. Rather the bit of code that should be objecting to it is not the DKIM verifier. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of MH Michael Hammer (5304) Sent: Friday, October 15, 2010 1:52 PM To: Bill Oxley @ Cox; dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I think the problem is it's hard to tell using an algorithm. A human can perhaps look at a modification and qualify it as an operational side-effect or something deliberate intending to deceive, but it's pretty hard to codify that kind of logic, especially without some foreknowledge about what downstream agents are going to do with the message (which would make such an algorithm heinously big). I recognize what Murray and Dave have said on this point but it grates. I think it's an unfortunate reality as well; absent a way to tell the difference, it seems the best option is to act like there isn't any difference. Interestingly, I think the same logic applies to domain reputation: It's easy to shed a bad reputation by changing domains, so in the end I expect a bad reputation will be the same as no reputation. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/15/10 1:51 PM, MH Michael Hammer (5304) wrote: On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote: To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I recognize what Murray and Dave have said on this point but it grates. The reason we are going through the exercise of creating a stable identifier associated with a signing domain is because we perceive some value whether it be policy associated with the stable identifier or reputation associated with the stable identifier. To simply ignore this and say it is the same as if it wasn't signed is kind of like saying 0=1. Agreed. Having the specification suggest multiple From header fields should not report a valid signature is not enough. It will be years before software will reliably deal with the resulting exploits. The best method to handle DKIM related exploits at the MTA would be to recommend message refusal. It is hard to understand the reluctance in having a SHOULD refuse. Citing a layer violation makes little sense. With DKIM, the message body does not stand on its own. DKIM binds elements related to the RFC5322 header fields with the message body, for the purpose of extending favorable message handling, such as white-listing. Since DKIM has this property, citing layer violations lacks any basis. The h=from:from is also not an effective solution, as this only deals with one mode of exploitation! There are two. John and Mark are right. It is wrong to consider the DKIM signature some type of academic exercise devoid of how DKIM might be exploited. The WG should step up and deal with this assumed compliance vulnerability. Without DKIM, this vulnerability would not exist. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/15/10 10:58 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of MH Michael Hammer (5304) Sent: Friday, October 15, 2010 1:52 PM To: Bill Oxley @ Cox; dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. The problem is: when is a broken signature an intentionally broken signature and how do we detect that at the verifier side? For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. -1. At the end of the day, giving a negative score to an invalidated signature will/may affect the reputation of the owner of the domainname or better said: it will influence the way the assessor will interpret the authentication results provided by the verifier. Apart from the problem of how to determine the 'nature of the invalidation'. I think the problem is it's hard to tell using an algorithm. A human can perhaps look at a modification and qualify it as an operational side-effect or something deliberate intending to deceive, but it's pretty hard to codify that kind of logic, especially without some foreknowledge about what downstream agents are going to do with the message (which would make such an algorithm heinously big). I recognize what Murray and Dave have said on this point but it grates. I think it's an unfortunate reality as well; absent a way to tell the difference, it seems the best option is to act like there isn't any difference. Interestingly, I think the same logic applies to domain reputation: It's easy to shed a bad reputation by changing domains, so in the end I expect a bad reputation will be the same as no reputation. +1 Like DNSBLs and IPv6: at some point it will be more effective to whitelist known 'good' IP addresses than to blacklist the ever changing IP addresses of the bad guys. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/15/10 8:40 AM, Mark Delany wrote: h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id? Yes, it does. The only question is to devise normative statements correctly, e.g. MUST duplicate From, SHOULD duplicate the rest. This is _not_ a kludge. It is how DKIM signing works (Section 5.4). Are we worried about wasting 100~200 bytes per signature? (I get ~4Kb headers nowadays, so that is about 3% of it.) Introducing an abbreviation --e.g. an h2 tag-- is considerably clearer from an algorithm developer's POV. Well, if you want to introduce semantic changes why not just change the meaning of h=from:to: to be semantically identical to h=from:from:to:to: Old verifiers still work as well as they do today, new verifiers work better and virtually all existing signers still work (excepting those that sign a subset of legitimately repeating headers - which must be rare). In either cases, the implementation changes are about the same, but the spec is simpler. Agreed. But use of the h=from:from prevents one mode of exploitation, because this requirement until now had not been made explicit. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
MH Michael Hammer (5304): -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Friday, October 15, 2010 11:59 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I'm sure this was discussed before, but perhaps a refresher helps. How would the DKIM validator know the difference between: A: The message had a valid signature, but it was broken after signing. B: The message is a forgery with a bogus signature. If the DKIM validator cannot make that distinction, then the bad guys will do B and the validator will treat it as A. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
MH Michael Hammer (5304) wrote: And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I recognize what Murray and Dave have said on this point but it grates. The reason we are going through the exercise of creating a stable identifier associated with a signing domain is because we perceive some value whether it be policy associated with the stable identifier or reputation associated with the stable identifier. To simply ignore this and say it is the same as if it wasn't signed is kind of like saying 0=1. I view this from a Fault Analysis standpoint and the first thing to establish are your boundary conditions and it is difficult to have boundary conditions without a policy framework (or process expectations). Part of the modeling do include invalid signatures and we have shown that you can fold many of these invalid signature conditions into a single never signed condition. This why I continue to have a problem with the 4871 policy of transforming an invalid state point to never signed state point. It was fine when POLICY was still part of the framework. When we insisted on separating the two, that 4871 inherent policy should of been removed. This is not the first time, but I would love to re-issue the suggestion to remove that statement from 4871 iff we want to continue to separate policy into another layer. In that case, the higher layer needs all trace information available. The difference is that there is higher weight with deterministic boundary conditions when there is no real signature vs the indeterminate conditions with failed signatures. But depending on the domain expectation, these failed conditions can be folder to the no signature condition. I always come back to an image of an old patented idea of using a perfect circle to represent the optimal boundary conditions for a process. When that circle is skewed, you are off the optimal plane. It may not represent an emergency, but there is a shape or limits that tells you something is not right and alerts need to be signaled. For DKIM, we can only do this with Domain Expectations to help verifiers and local policy be molded. -- 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] 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: Wednesday, October 13, 2010 10:49 PM To: dcroc...@bbiw.net Cc: DKIM List Subject: Re: [ietf-dkim] detecting header mutations after signing What you are calling for would be good to have. It should be done. Just not in the signing spec. Correct me if I'm wrong, but I hear you saying that if one creates or verifies the DKIM signature on a message, one should also do the double header check somewhere in the mail processing path, but rather than saying so in the spec, it'll just be our private bit of folklore. I'm completely okay with providing informative guidance to signers and verifiers, or even to receivers and MUAs, maybe even right in the bis document. But once it becomes normative, and especially if we want to put a MUST in there, we're requiring the work of enforcing the terms of a non-DKIM RFC into DKIM. Any way you slice it, that just sounds like bad engineering to me. If we accept the model that DKIM is a layer that sits on top of the mail layer (and by that I mean RFC5322; SMTP is a layer below that even), then what crosses the layer boundary should only be valid, in the same way that only valid IP packets get passed up to the TCP layer, or only valid and sequenced TCP packet payloads make it up into a socket's read buffer, or only a valid SMTP command sequence can cause something to land in your inbox. The mail layer shouldn't pass crap upwards; and in this case that means an MTA shouldn't invoke a DKIM library/function/whatever unless the data it's about to pass across that line is known to be valid for that transition. The mail layer is where RFC5322 is implemented, so it has the code to do what you called the full body cavity search already, and so any lightweight header counting is thus by definition not only cheap, but actually redundant. 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. I can point out dozens of UNIX man pages that say the same thing. It's not a new idea. In a C program, if I ask you to hand me a valid string, I'm saying something that has a specific, unambiguous, well-documented meaning. If despite that you hand me something that may or may not be a valid string, it's unreasonable for you to expect me or other possible handlers of that data to do something valid or safe with it every time. Indeed, the result could often be catastrophic. That MUAs or post-DKIM filtering agents might make weak, lazy or foolish rendering decisions is certainly unfortunate, perhaps even terrible, but I'm not convinced that all (or any) of the layers below that need to do normative things that compensate for, accommodate, or fix everything that might make it up that far, protecting them from themselves, only to have them come up with yet another new way to be vulnerable later. As I said in another message, I realize once you're actually writing an application to do all of this then the interface lines can get quite mushy. But I don't believe the IETF should be in the business of producing standards track protocol specifications that define interface lines which are intentionally mushy. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John R. Levine jo...@iecc.com writes: DKIM support in an MUA? Yuck. It's likely to be a long time before any MUA I use does anything with DKIM, since I am not a fan of filtering mail while reading it. An MUA does not have to do filtering in order to support DKIM. It could display the Authentication Results header, or take some action depending on whether there is a valid DKIM signature - in a similar way that some web browsers will turn the URL bar green when the site presents a valid 'extended validation' certificate. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Wed, 13 Oct 2010 17:34:32 +0100, Charles Lindsey c...@clerew.man.ac.uk wrote: But full 100% RFC5322 checking is extremely tedious, and is more that we actually need. What we want is more like CHECK DKIM CHECK RFC5322 headers included in h= tag -- ACCEPT where at least the CHECK RFC5322 counts the number of occurrences, perhaps a little more, but not worry about the more obscure checks such as LFCR instead of CRLF. On further thought, I would make that: CHECK DKIM CHECK RFC5322 headers included in h= tag -- ACCEPT ELSE CHECK FOR ADSP DISCARDABLE (maybe for ALL) where the ADSP should check ALL the From headers that are found (so I guess we need an RFC5617-bis too, since 5617 takes no account of multiple From headers. -- 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] detecting header mutations after signing
On Wed, 13 Oct 2010 17:54:23 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Wednesday, October 13, 2010 9:12 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing The bad guy (the phisher) provides two From headers, but only signs one which, as DKIM is currently defined, has to be the second one. His two headers are: From: i...@ebay.com From: i...@phisher.com BUT many/most MUAs currently display only the first From header if two are provided. There is no reason why the verifier at the boundary should report an invalid signature, so the message gets through to the intended victim who just sees what his MUA shows him, which apparently is a message from the genuine ebay address. This is true if the message is not DKIM-signed at all. The rendering choice you're highlighting here already exists in many/most MUAs. But if there is no valid DKIM signature, the verifier will proceed to do ADSP checks, and will reject the message if it sees that ebay.com is 'discardable'. Note that RFC5617 is ambiguous as to which of the two From headers it will use to establish the Author Domain, so we are going to need a 5617-bis to fix that. If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem? Since the phisher is trying to bypass that ADSP 'discardable' for ebay.com (and he thinks ADSP checkers might use the first address), it is in his interest to DKIM-sign the message himself (so that ADSP is never consulted). And that is why it is a DKIM problem, and why the loophole must be closed. -- 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] detecting header mutations after signing
On Wed, 13 Oct 2010 19:27:29 +0100, Jeff Macdonald macfisher...@gmail.com wrote: If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem? I agree with this. And even if there was a DKIM signature, it is the BAD GUY'S signature, which should cause it to go into the SPAM folder, with a large phishing warning. No, the Bad Guy has used a throwaway domain which has not yet made its way into any blacklist the SPAM checker might have been using. rant Count me as one of those who was confused early on about what DKIM provides. DKIM seems to make assurances to message integrity. But it doesn't. I think the reason why many think it does is because of the body hash. It is trying to do to much. It should just provide an identifier that can be verified. Instead of using the body for hashing, use the Message-ID header along with the Date header and just hash that. That way most folks would understand DKIM is just providing an Identifier. /rant I have much sympathy with this rant; I think the body could have been handled much better. But it ain't going to change, and Barry has now declared it OT. -- 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] 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: Thursday, October 14, 2010 7:32 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing This is true if the message is not DKIM-signed at all. The rendering choice you're highlighting here already exists in many/most MUAs. But if there is no valid DKIM signature, the verifier will proceed to do ADSP checks, and will reject the message if it sees that ebay.com is 'discardable'. ADSP is a completely separate discussion. We're talking about advancing DKIM here, not both of them. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 13/Oct/10 20:45, Scott Kitterman wrote: On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote: If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem? If the DKIM signature doesn't verify after signed headers have been altered, then it's not. Correct. And the way that it fails to verify is h=from:from. The only way that DKIM can consistently account for this exploit is by amending section 5.5 Recommended Signature Content, and spell what fields MUST/SHOULD be duplicated in the h= tag. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote: On 13/Oct/10 20:45, Scott Kitterman wrote: On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote: If we can extract DKIM from the equation entirely and the problem remains, how is it a DKIM problem? If the DKIM signature doesn't verify after signed headers have been altered, then it's not. Correct. And the way that it fails to verify is h=from:from. Which strikes me as an ugly hack. Given that most headers should only occur once and given that a lot of signers sign most headers doesn't this suggestion degenerate to h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Alessandro Vesely wrote: Correct. And the way that it fails to verify is h=from:from. The only way that DKIM can consistently account for this exploit is by amending section 5.5 Recommended Signature Content, and spell what fields MUST/SHOULD be duplicated in the h= tag. -0.5. This is a kludge. Its good to help, possibly, existing systems that is capable of defining the N+1 h=from values in their setup. The problem is you don't know if they can. The real solution is to fix up section 5.4 general paragraph regarding signing and verifying the last header because it ignored the exception in regards to 5322.From which fundamentally there can only be one. It needs to add the exception clause to that paragraph or in a follow up paragraph. Both verifiers and signers MUST make sure its DKIM input, especially the headers it will bind, are technically correct. Only DKIM can do that to close legacy loopholes. The h=from:from kludge should be seen as a temporary solution until verifiers and signers catch up with the Double From problem. It can't depend on other mail bots to do this. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Oct 13, 2010, at 1:59 PM, Mark Delany wrote: On Wed, Oct 13, 2010 at 04:09:34PM -0400, MH Michael Hammer (5304) allegedly wrote: Having said that, if an MUA is going to present an indication of DKIM PASS to the enduser, then a reasonable person would expect some relationship between what is passed and what is presented to the enduser. That makes sense. And at least one MUA already renders DKIM verified mail differently. I would think such an MUA could take the additional step of rendering verified payload differently too. I know we're not in the MUA business, but if DKIM makes no difference to what an end-user finally sees, then it serves a very limited purpose indeed. I'm looking forward to a draft on MUA considerations for DKIM. With all these opinions on the matter being expressed so adamantly, somebody must have already started one...right? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Tue, 12 Oct 2010 14:36:42 +0100, Hector Santos hsan...@isdg.net wrote: What it means for most systems that they need to change a model based on this: CHECK DKIM PASS -- ACCEPT CHECK RFC5322 BAD -- REJECT BREAK RESIGN DISTRIBUTE To this: CHECK RFC5322 BAD -- REJECT CHECK DKIM PASS -- ACCEPT BREAK RESIGN DISTRIBUTE But full 100% RFC5322 checking is extremely tedious, and is more that we actually need. What we want is more like CHECK DKIM CHECK RFC5322 headers included in h= tag -- ACCEPT where at least the CHECK RFC5322 counts the number of occurrences, perhaps a little more, but not worry about the more obscure checks such as LFCR instead of CRLF. -- 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] detecting header mutations after signing
On Mon, 11 Oct 2010 23:05:13 +0100, Wietse Venema wie...@porcupine.org wrote: Charles Lindsey: When the bad guy sends mail with (multiple) forged headers, the best they can get is that naive mail programs render their forged header with an indication that THE BAD GUY'S DKIM SIGNATURE VERIFIED. Sending forged headers with bad guy's DKIM signatures is not an interesting attack on DKIM. On the contrary, it is an exceedingly interesting attack. Note that Wietse is replying to a message that I mistakenly sent to him offlist. I have now reposted that messqge for all to see. If you believe that sending mail with a valid bad guy signature is an interesting attack on DKIM, then that implies that you're willing to believe mail that is signed by arbitrary strangers. That is a problem that DKIM is not designed to solve. The average naive user never gets the chance to be willing or not to believe mail that is signed by arbitrary strangers, for the simple reason that his MUA does not routinely display any headers that mention signatures at all. All he sees is a message apparently From a known genuine ebay address (his MUA happens not to show the second From placed there by the phisher). Worse, he may be vaguely aware that his provider/boundary implements some amazing crypto stuff that purportedly guarantees that forged email From genuine ebay addresses will be stopped, and that will reinforce his belief that the message he saw is genuine. And yet the tests provided by his provider/boundary are 100% 4871 compliant. Surely this shows that there is something seriously wrong with 4871, which is clearly not providing the service it was supposed to. -- 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] detecting header mutations after signing
On 10/13/2010 2:27 PM, Jeff Macdonald wrote: DKIM seems to make assurances to message integrity. But it doesn't. I think the reason why many think it does is because of the body hash. It is trying to do to much. It should just provide an identifier that can be verified. Instead of using the body for hashing, use the Message-ID header along with the Date header and just hash that. That way most folks would understand DKIM is just providing an Identifier. my goodness, but your version of ranting is far too mild and reasonable. which is not to say i agree with you about tossing out the body hash. Although DKIM is not trying to protect the message, it /is/ trying to reduce the ability to take a valid use for one message and apply it to an invalid use with another. From a mathematical standpoint, your suggestion is quite reasonable, given that message ids are supposed to be unique, etc. But the question is whether a verifying can know whether a signature is being replayed -- that is whether it is being reapplied to a different message. Verifiers do not track message ids. So they can't detect a new use. Using the body hash is a convenient hack that is likely to make it nearly impossible to apply valid use of a DKIM identifier to different content. 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] detecting header mutations after signing
On Wed, Oct 13, 2010 at 2:40 PM, Dave CROCKER d...@dcrocker.net wrote: On 10/13/2010 2:27 PM, Jeff Macdonald wrote: DKIM seems to make assurances to message integrity. But it doesn't. I think the reason why many think it does is because of the body hash. It is trying to do to much. It should just provide an identifier that can be verified. Instead of using the body for hashing, use the Message-ID header along with the Date header and just hash that. That way most folks would understand DKIM is just providing an Identifier. my goodness, but your version of ranting is far too mild and reasonable. which is not to say i agree with you about tossing out the body hash. Although DKIM is not trying to protect the message, it /is/ trying to reduce the ability to take a valid use for one message and apply it to an invalid use with another. From a mathematical standpoint, your suggestion is quite reasonable, given that message ids are supposed to be unique, etc. But the question is whether a verifying can know whether a signature is being replayed -- that is whether it is being reapplied to a different message. Verifiers do not track message ids. So they can't detect a new use. Using the body hash is a convenient hack that is likely to make it nearly impossible to apply valid use of a DKIM identifier to different content. All valid points, but the implementation is being misunderstood. It is to late for this now, but if the initial criteria included prevent replay and not use the body, what implementation would of been thought up instead? No need to answer that, like I said, I was ranting. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Wed, Oct 13, 2010 at 2:47 PM, Scott Kitterman ietf-d...@kitterman.com wrote: On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote: And even if there was a DKIM signature, it is the BAD GUY'S signature, which should cause it to go into the SPAM folder, with a large phishing warning. No. That misses the point entirely. The problem here is that one can take a DKIM signed message that is signed by any entity and add additional From/Subjects and the message may still appear to be the one signed by the original entity even though it's been modified post-signature. Right. I had understood that and then forgot. If DKIM is just viewed as providing an identifier and nothing more, then this is a MUA problem. If DKIM is viewed as providing more than an identifier, then this is a DKIM problem. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Jeff Macdonald Sent: Wednesday, October 13, 2010 3:59 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing On Wed, Oct 13, 2010 at 2:47 PM, Scott Kitterman ietf-d...@kitterman.com wrote: On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote: And even if there was a DKIM signature, it is the BAD GUY'S signature, which should cause it to go into the SPAM folder, with a large phishing warning. No. That misses the point entirely. The problem here is that one can take a DKIM signed message that is signed by any entity and add additional From/Subjects and the message may still appear to be the one signed by the original entity even though it's been modified post-signature. Right. I had understood that and then forgot. If DKIM is just viewed as providing an identifier and nothing more, then this is a MUA problem. What is the value of an identifier vs a stable identifier? IF all you are willing to say about an identifier is yep, that's mine and nothing else, what is the value to an evaluator if the message body and various headers can be modified? I've always viewed DKIM as weak rather than strong but this reduces it to the edge of meaningless. If DKIM is viewed as providing more than an identifier, then this is a DKIM problem. This moves us in the direction of what is the use case for the identifier. I've said for a long time (from a phishing perspective) that if we let bad stuff (from a brand perspective) get to the enduser then it is game over (and yes, I realize that perfection is not necessarily achievable). This is why I am focused on the MTA rather than the MUA. Having said that, if an MUA is going to present an indication of DKIM PASS to the enduser, then a reasonable person would expect some relationship between what is passed and what is presented to the enduser. I understand the issues raised by Murray about the slippery slope. On the other hand, I would rather see an MUA present nothing about DKIM than give a false impression to endusers. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: John Levine [mailto:jo...@iecc.com] Sent: Wednesday, October 13, 2010 2:47 PM To: ietf-dkim@mipassoc.org Cc: Murray S. Kucherawy Subject: Re: [ietf-dkim] detecting header mutations after signing DKIM simply highlights an issue that's been there for a very long time now. No. No, no, no, no, no. Malformed messages only become an issue when someone aserts that they're not malformed. In the absence of DKIM signatures, the reasonable thing to do with a malformed message is to render it. In the presence of a DKIM signature, the reasonable thing is something else. That's why this is a DKIM issue. Do Alpine or Thunderbird or whatever else do anything special now when a message is signed, whether or not the signature(s) pass or fail? Current modules that don't do the kind of enforcement people are demanding and that isn't exacerbating anything. When they add DKIM support in some way, I imagine those MUAs will become aware of the problem and do the something else you're talking about. I'm fine with providing some informative guidance about that to MUAs, but that's different than telling verifiers that they are required to enforce something that's not specifically within their scope. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 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: Wednesday, October 13, 2010 1:59 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing I understand the issues raised by Murray about the slippery slope. On the other hand, I would rather see an MUA present nothing about DKIM than give a false impression to endusers. I can understand the engineering nervousness over crossing layers, but that seems to me to be conflating the SMTP aspects of an MTA with the DKIM aspects of an MTA/verifier. It strikes me that a DKIM verifier is already well into the business of 2822 semantics as it knows about headers, header labels, continuation syntax, header/body boundaries and so on. In that light, taking an additional step wrt duplicate headers (or malformed 2822 in general) is still in the same layer as the verifier. My objection isn't so much layering within the software, because I know that gets mushy real quick, but layering among the protocol specifications. For example, we wouldn't include in an SMTP specification some text about dealing with fuzzy TCP implementations, and what people are talking about here makes just as much sense to me. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Oct 13, 2010, at 1:59 PM, Mark Delany wrote: It strikes me that a DKIM verifier is already well into the business of 2822 semantics as it knows about headers, header labels, continuation syntax, header/body boundaries and so on. In that light, taking an additional step wrt duplicate headers (or malformed 2822 in general) is still in the same layer as the verifier. I'm a little leery about going that far conceptually, but I'm happy with any piece of code that verifies DKIM should do some basic 822 sanity checking too. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
In that light, taking an additional step wrt duplicate headers (or malformed 2822 in general) is still in the same layer as the verifier. My objection isn't so much layering within the software, because I know that gets mushy real quick, but layering among the protocol specifications. For example, we wouldn't include in an SMTP specification some text about dealing with fuzzy TCP implementations, and what people are talking about here makes just as much sense to me. The problem is that I don't think we are really just talking about getting a protocol right from a bits perspective. If DKIM has any value it's that it ultimately affects the user mail experience for the better. Consequently, to remain silent on matters that we know will adversely affect that experience seems contradictory. Similarly to not offer guidance to implementors on the sorts of things they can do to maximize the value of DKIM seems similarly to miss the point. Furthermore, DKIM specifically came into existence to deal with an adversarial environment whereas 821/822 and the like have very specific just get the bits right goals. So guiding verifiers to assume the worst seems consistent with our intent or at least our genesis. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
+1, well said Mark. Its a real potential situation that is on par, IMTO, with what the DKIM technology was suppose to help with. It was unfortunate it fell through the cracks during the Threats Analysis RFC 5016 production. If it was realized back then, I don't think anyone would be debating who is the blame and what was needed to be done (written into the RFC 4871 specs). In retrospect, I recall most discussions was around multiple addresses possible in the single 5322.From header and how to deal with that, especially in regards to redundant POLICY lookups. If I recall, the consensus was that only the first address in the potetial list of from addresses in the single 5322.From header was the only important author domain for POLICY considerations. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Mark Delany wrote: Murray wrote: My objection isn't so much layering within the software, because I know that gets mushy real quick, but layering among the protocol specifications. For example, we wouldn't include in an SMTP specification some text about dealing with fuzzy TCP implementations, and what people are talking about here makes just as much sense to me. The problem is that I don't think we are really just talking about getting a protocol right from a bits perspective. If DKIM has any value it's that it ultimately affects the user mail experience for the better. Consequently, to remain silent on matters that we know will adversely affect that experience seems contradictory. Similarly to not offer guidance to implementors on the sorts of things they can do to maximize the value of DKIM seems similarly to miss the point. Furthermore, DKIM specifically came into existence to deal with an adversarial environment whereas 821/822 and the like have very specific just get the bits right goals. So guiding verifiers to assume the worst seems consistent with our intent or at least our genesis. Mark. ___ 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] detecting header mutations after signing
On Wednesday, October 13, 2010 03:59:27 pm Jeff Macdonald wrote: On Wed, Oct 13, 2010 at 2:47 PM, Scott Kitterman ietf-d...@kitterman.com wrote: On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote: And even if there was a DKIM signature, it is the BAD GUY'S signature, which should cause it to go into the SPAM folder, with a large phishing warning. No. That misses the point entirely. The problem here is that one can take a DKIM signed message that is signed by any entity and add additional From/Subjects and the message may still appear to be the one signed by the original entity even though it's been modified post-signature. Right. I had understood that and then forgot. If DKIM is just viewed as providing an identifier and nothing more, then this is a MUA problem. If DKIM is viewed as providing more than an identifier, then this is a DKIM problem. The identifier only makes sense within a context. For DKIM that context is the signed content. For the identifier to be meaningful, it has to be connected to the actual content of the message, if not, the identifier could be arbitrarily reused and would serve little purpose. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/13/2010 3:17 PM, John R. Levine wrote: We put a bunch of stuff in DKIM to allow benign modifications of messages, notably relaxed canoncalization. (We can argue about whether l= is useful, but it's easy enough to ignore if one thinks it isn't.) I think it's also reasonable to put stuff in to disallow malevolent modifications. Putting things in to be more robust against vagaries of travel is quite different from adding things to resist actual attack. In particular, note that nothing being discussed, here, invalidates the signature. The topics being discussed concern processing that really is outside of DKIM. Therefore its discussion is outside of DKIM. Most of the confusion is exactly the difference between DKIM as a labeling technology versus DKIM as a message protection technology. On 10/13/2010 3:30 PM, Murray S. Kucherawy wrote: I'm talking about a dual-From: message that wasn't signed at all. An MUA will still show the wrong one. So I fail to see why a DKIM specification needs to make a normative requirement about a problem that's been around since years before the acronym DKIM ever appeared anywhere. +1 On 10/13/2010 3:47 PM, Murray S. Kucherawy wrote: I'm concerned that if we name that specific check, that's all people will do and then think they're safe. Exactly! We are not tasked with dealing with the larger security issues and this is but a piece of it. Tackling only this tiny piece constitutes woefully incomplete work and it's really out of scope. DKIM simply highlights an issue that's been there for a very long time now. Actually, no. DKIM does not highlight this. What is highlighting this is security discusses that come from wanting to apply DKIM to more than it is designed for. It is the /discussions/ that highlight this, not DKIM. (I'm not playing semantics here. I'm playing scope.) Given that DKIM's core algorithms are the same as those used for message security, it's pretty easy to imagine applying DKIM to these other, larger issues, but that's a separate engineering effort. On 10/13/2010 4:09 PM, MH Michael Hammer (5304) wrote: I've said for a long time (from a phishing perspective) that if we let bad stuff (from a brand perspective) get to the enduser ... Having said that, if an MUA is going to present an indication of DKIM PASS to the enduser, ... I understand the issues raised by Murray about the slippery slope. On the other hand, I would rather see an MUA present nothing about DKIM than give a false impression to endusers. Fundamentally, everything in your note suffers from being both valid but irrelevant (to the current discussion about DKIM). It's valid and even essential, to a different, larger discussion. 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] detecting header mutations after signing
On 10/13/2010 4:59 PM, Mark Delany wrote: I know we're not in the MUA business, but if DKIM makes no difference to what an end-user finally sees, then it serves a very limited purpose indeed. Well, yes. But that's a /good/ thing, as a core capability. More importantly, we are not in the MUA business because we lack the expertise, as a group. 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] detecting header mutations after signing
On 10/13/2010 8:56 PM, Mark Delany wrote: If DKIM has any value it's that it ultimately affects the user mail experience for the better. Consequently, to remain silent on matters that we know will adversely affect that experience seems contradictory. Similarly to not offer guidance to implementors on the sorts of things they can do to maximize the value of DKIM seems similarly to miss the point. Mark, First, let's be clear that no one think MUA issues are minor or irrelevant. The question is how DKIM relates to them and what should be said about the topic in the DKIM Signing specification. Everything affects the user experience. IP interpacket arrival times. TCP algorithms responding to congestion. SMTP transaction design. Every f'ing thing. But this does not mean that each of them must make comments about MUA issues. DKIM resolved a massively important problem by defining a validated name-affixing mechanism. But neither Domainkeys nor DKIM specifications demonstrate any of the human factors or usability specialties needed to make serious comments -- nevermind normative directives -- about MUA design. Nor did they need to. What you are calling for would be good to have. It should be done. Just not in the signing spec. 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] detecting header mutations after signing
What you are calling for would be good to have. It should be done. Just not in the signing spec. Correct me if I'm wrong, but I hear you saying that if one creates or verifies the DKIM signature on a message, one should also do the double header check somewhere in the mail processing path, but rather than saying so in the spec, it'll just be our private bit of folklore. R's, John PS: I'm fine with Jim's proposed section 6.1.1. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
bill.ox...@cox.com wrote: 50% of the spam we see is RFC compliant DKIM signed, DKIM isnt the issue in your example its the operator and how they determine reputation Please read what was said. No Signature, Double From --- Trapped/rejected by mipassoc.org DKIM signed Double From Accepted, Resigned by mipassoc.org If mipassoc.org is going to an example of many systems, then we have a unfortunate problem until current systems are updated to prevent the DKIM loophole for what is otherwise RFC5322 checking systems. What it means for most systems that they need to change a model based on this: CHECK DKIM PASS -- ACCEPT CHECK RFC5322 BAD -- REJECT BREAK RESIGN DISTRIBUTE To this: CHECK RFC5322 BAD -- REJECT CHECK DKIM PASS -- ACCEPT BREAK RESIGN DISTRIBUTE -- 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] detecting header mutations after signing
--On 12 October 2010 09:36:42 -0400 Hector Santos hsan...@isdg.net wrote: No Signature, Double From --- Trapped/rejected by mipassoc.org Really? You tested this? I assumed the message was accepted because it contained a From: header belonging to a list member. Not because it was signed. DKIM signed Double From Accepted, Resigned by mipassoc.org Yes, we saw that. -- 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] detecting header mutations after signing
On 10/12/2010 11:05 AM, Ian Eiloart wrote: No Signature, Double From --- Trapped/rejected by mipassoc.org Really? You tested this? I assumed the message was accepted because it contained a From: header belonging to a list member. Not because it was signed. You are correct. The list accepts submissions only from subscribers, as checked in the From: field. This test message failed that stricture. 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] detecting header mutations after signing
On Fri, 08 Oct 2010 18:25:40 +0100, Wietse Venema wie...@porcupine.org wrote: If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. You are indeed mistaken. All you have ensured is that any message signed (say by ebay) is proof against reply attacks that add additional headers. But the scam we are considering does not involve replay attacks at all. It involves a message created and signed by the scammer using his own key. Naturally, scammers feel no obligation to follow advice or requirements in standards, so they will sign just one instance of the two headers. The ONLY way to defeat this scam is for the Verifier to count the headers itself. And the threat is serious enough that the counting has to be a 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] detecting header mutations after signing
Charles Lindsey: On Fri, 08 Oct 2010 18:25:40 +0100, Wietse Venema wie...@porcupine.org wrote: If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. You are indeed mistaken. All you have ensured is that any message signed (say by ebay) is proof against reply attacks that add additional headers. But the scam we are considering does not involve replay attacks at all. It involves a message created and signed by the scammer using his own key. Please read my entire response carefully before responding. The above detects the case where a bad guy adds a forged header to a DKIM-signed message, in the hope that naive mail programs will render their forged header with an indication that THE GOOD GUY'S DKIM SIGNATURE VERIFIED. When the bad guy sends mail with (multiple) forged headers, the best they can get is that naive mail programs render their forged header with an indication that THE BAD GUY'S DKIM SIGNATURE VERIFIED. Sending forged headers with bad guy's DKIM signatures is not an interesting attack on DKIM. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Charles Lindsey: When the bad guy sends mail with (multiple) forged headers, the best they can get is that naive mail programs render their forged header with an indication that THE BAD GUY'S DKIM SIGNATURE VERIFIED. Sending forged headers with bad guy's DKIM signatures is not an interesting attack on DKIM. On the contrary, it is an exceedingly interesting attack. If you believe that sending mail with a valid bad guy signature is an interesting attack on DKIM, then that implies that you're willing to believe mail that is signed by arbitrary strangers. That is a problem that DKIM is not designed to solve. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Monday, October 11, 2010 3:18 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing It's not really an 'attack' on anything, but the most one could claim is that it's an attack on the recipient's reputation data base, or failure to use one. I would even submit that it's an attack on user confidence via MTAs and/or MUAs that are too forgiving of invalid syntax. But that was a problem before DKIM even existed anyway. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Dave CROCKER wrote: On 10/11/2010 3:05 PM, Wietse Venema wrote: If you believe that sending mail with a valid bad guy signature is an interesting attack on DKIM, then that implies that you're willing to believe mail that is signed by arbitrary strangers. Well... But it's not an attack on DKIM. It's not really an 'attack' on anything, but the most one could claim is that it's an attack on the recipient's reputation data base, or failure to use one. The DKIM part is used correctly and works fine. So there's no 'attack'. Thats poster framing material. I sure hope you are right. After all, President Obama did get by your defenses on your list. No Signature, Double From --- Trapped/rejected by mipassoc.org DKIM signed Double From Accepted, Resigned by mipassoc.org So without DKIM, 100% RFC5322 compliant - trapped multiple 5322.From headers. With DKIM, there is a loophole. Go figure. Lets hope this DKIM exploit does not become common place and surprises a bunch of layman operators. At the point, you can say you were aware about it. -- 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] detecting header mutations after signing
50% of the spam we see is RFC compliant DKIM signed, DKIM isnt the issue in your example its the operator and how they determine reputation On Oct 11, 2010, at 9:23 PM, Hector Santos wrote: Dave CROCKER wrote: On 10/11/2010 3:05 PM, Wietse Venema wrote: If you believe that sending mail with a valid bad guy signature is an interesting attack on DKIM, then that implies that you're willing to believe mail that is signed by arbitrary strangers. Well... But it's not an attack on DKIM. It's not really an 'attack' on anything, but the most one could claim is that it's an attack on the recipient's reputation data base, or failure to use one. The DKIM part is used correctly and works fine. So there's no 'attack'. Thats poster framing material. I sure hope you are right. After all, President Obama did get by your defenses on your list. No Signature, Double From --- Trapped/rejected by mipassoc.org DKIM signed Double From Accepted, Resigned by mipassoc.org So without DKIM, 100% RFC5322 compliant - trapped multiple 5322.From headers. With DKIM, there is a loophole. Go figure. Lets hope this DKIM exploit does not become common place and surprises a bunch of layman operators. At the point, you can say you were aware about it. -- 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John R. Levine wrote: So here's a 0th cut at a list of headers where we should recommend N+1 entries in the h= rfc 5322 From Sender Reply-To (maybe not, since often smashed by mailing lists) To Cc(not Bcc even though it's 0/1) Message-ID Subject Date rfc 4021 MIME-Version Content-Type I would focus on the main rendering items, the ones common across the mail universe of devices, gated systems, etc. From:required by 822/2822/5322 Date:required by 822/2822/5322 Subject: optional 822/2822/5322 To: required by 822, optional 2822/5322 The others are related to Network Control Lines and are generally hidden and only the ones necessary for a reply (if different than the From) may be kludged in. I know this is old school but it still applies today. Many systems do a Valid Header check in order to see if a header block needs to be generated. This is what allows a human or simple mail bot (print, fax job, etc) to enter no headers in a DATA state and still get mail through because the fields can be filled: From:--- 5321.MAIL FROM To: --- 5321.RCPT TO Date:--- Local Computer Timestamp Subject: --- left blank or filled with (NO SUBJECT) That said I don't see incentives to spoof: Message-ID MIME-Version Content-Type What are the gains? The Sender: can change too, like in a list. Not sure about CC: I guess it should be included. I think for 4871bis, we should keep it simple with focusing on the main security hole, 5322.From (and also make a statement that regarding RFC5322). -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
I don't see incentives to spoof: MIME-Version Content-Type What are the gains? This has been discussed at great length. Please consult the list archives. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John R. Levine wrote: I don't see incentives to spoof: MIME-Version Content-Type What are the gains? This has been discussed at great length. Please consult the list archives. Thanks - you couldn't summarize or its too hard to explain? I can search, certainly not consult. But let me consult GOOGLE: MIME-Version Exploits IETF-DKIM Without going nuts looking all the results, I see whats in 4871 section 8.1.1. Addition of New MIME Parts to Multipart/* and this seems about the l= body size issue which most people already agreed is a bad idea. I don't see how the 5322.Mime-Version header can be exploited. Anyway, never mind. -- 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] detecting header mutations after signing
A) You have to sign either all occurences of a header or none of them, ... B) Same as A, but limited to an enumerated set of headers that are supposed to occur only once. c) Same as B, but tell signers to use the h= trick to make verification fail if extra headers show up. Realistically useful advice probably has to influence rendering of messages. That might mean MUA participation or it might mean mailstore participation that removes all (typically) rendered headers that are unsigned. Gosh, I hope not. I'd like DKIM to be sturdy enough that I can trust stuff signed by people I know and not have to backstop it by tricks elsewhere to defend against malicious changes that DKIM didn't notice. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John R. Levine: a) Author creates a 100% compliant message b) Signer signs 100% compliant message c) Bad guy adds an extra header, making it non-compliant, and sends it to someone ... Mike, I only have vague recollection of the h= trick anymore... You list all the headers you sign in h= list, and you can include headers that don't exist, which means that they can't exist when verified either. So for a header that occurs N times, you can list it N+1 times in h= to ensure that more aren't added. The original motivation was usually N=0 to avoid games played by adding MIME headers to messages that don't have them, but it's generally applicable. With this signer-side configuration solution, the verifier can detect attempts to spoof any header that was covered by the DKIM signature (spoof as in add a forged header, and hope that naive programs will use the forged header instead of the authentic one). So the solution is already available in DKIM. We just need to use the solution, and make it part of routine DKIM tests. Having the signer put the extra junk in h= should make existing verifiers do the right thing, although I doubt the bit of verification code that checks for the non-existence of the N+1st header for N0 is well tested in DKIM implementations. To address this, make this solution part of routine DKIM test suites. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Michael Thomas wrote: On 10/07/2010 05:01 PM, John R. Levine wrote: Nobody has signed a non-compliant message, so while there is nothing wrong with Mike's advice, it completely misses the point. You're right, it does miss the point. What I'm trying to get my head around is whether this is a real problem in the real world. Not yet, but this has a higher risk of occurrence in the future than let's say, SHA1 exploits which required us to incorporate SHA256 into the options mix. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Wietse Venema wrote: With this signer-side configuration solution, the verifier can detect attempts to spoof any header that was covered by the DKIM signature (spoof as in add a forged header, and hope that naive programs will use the forged header instead of the authentic one). So the solution is already available in DKIM. We just need to use the solution, and make it part of routine DKIM tests. Having the signer put the extra junk in h= should make existing verifiers do the right thing, although I doubt the bit of verification code that checks for the non-existence of the N+1st header for N0 is well tested in DKIM implementations. To address this, make this solution part of routine DKIM test suites. +1, however. This is only part of the solution. A temporary one to allow current operators to cover themselves using their Required Header configuration, if any. The real solution is to void double 5322.From messages. Either the DKIM compliant MSA, MDA do it or the better DKIM signer/verification engine does it to cover for legacy MSA, MDA or to make sure customers using a 3rd party signing engine are sending the proper mail to sign. Can someone come up with IETF amenable copy text for Dave to add to 4871bis that won't prohibit or slow it down its progress? IMV, all would be implementers need to read is a basic idea of: Make sure there are no two or more 5322.From headers when signing or verifying. These messages should be voided. and thats it. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 08/Oct/10 07:00, John R. Levine wrote: Having the signer put the extra junk in h= should make existing verifiers do the right thing, although I doubt the bit of verification code that checks for the non-existence of the N+1st header for N0 is well tested in DKIM implementations. +1, and the revised example proposed by Julian can be enough. The whole discussion on multiple Froms then boils down on whether it is worth to change the protocol so that, for example, h=from:subject:date:message-id:to MUST be interpreted by the verifier to mean h=from:from:subject:subject:date:date:message-id:message-id:to:to, a handy abbreviation for known fields. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Friday, October 08, 2010 8:34 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing The whole discussion on multiple Froms then boils down on whether it is worth to change the protocol so that, for example, h=from:subject:date:message-id:to MUST be interpreted by the verifier to mean h=from:from:subject:subject:date:date:message-id:message-id:to:to, a handy abbreviation for known fields. I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? 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] detecting header mutations after signing
Dave CROCKER: On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Friday, October 08, 2010 12:33:38 pm Dave CROCKER wrote: On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? d/ Detecting modification in transit is outside the scope of what DKIM is trying to achieve? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Friday, October 08, 2010 10:01 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? Detecting modification in transit is outside the scope of what DKIM is trying to achieve? Doesn't DKIM try to detect modification of the portion covered by the hashes, which is unchanged in this scenario? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. The standard advice has always been to accept malformed mail and render it as best you can, on the theory that it was probably from a legit but buggy sender. Other than this DKIM issue, that's still good advice. Here's another way to look at it: if we think that adding extra headers is a significant threat, someone's going to have to check for them. History suggests that in the absence of DKIM, it's not worth doing since nobody does it. That also suggests that all the places other than a DKIM verifier will continue not to do it, since it's still of no great benefit. So if we don't do it in the verifier, it's not going to happen. Our software works, but you have to make changes of no direct benefit to yourself to plug a hole we could have plugged has rarely been a winning argument in the past. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Friday, October 08, 2010 01:41:15 pm Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Friday, October 08, 2010 10:01 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? Detecting modification in transit is outside the scope of what DKIM is trying to achieve? Doesn't DKIM try to detect modification of the portion covered by the hashes, which is unchanged in this scenario? For what I view as a very abstract definition of unchanged, sure. I think adding additional From or Subject does change the content of the message From or Subject. If one takes the view that we've defined things such that this is OK from a protocol definition perspective, so it's not an issue, I think we've lost sight of the original goal of this requirement in the protocol. I think that this can be dealt with through an additional security consideration and doesn't have to disrupt the rush to get this advanced through the standards process. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 08/Oct/10 18:33, Dave CROCKER wrote: On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I don't know of a precedent standard, but I recall of an MTA that did bother to enforce normative portions. Users periodically complained, because it is not quite practical to not be liberal in what we accept. The best of users' protests that I recall was No, just to deliver mail rather than being a pedantic-mode SMTP debugger. [http://www.mail-archive.com/courier-us...@lists.sourceforge.net/msg16896.html] I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? Hmm... it is only theoretical until it becomes productive to put it into practice, and at that point it will be too late. No doubt most of us will update their to-be-signed field lists during the next few weeks. However, introducing what I called a handy abbreviation would be a source of confusion. When h=from:from will be automatically assumed by verifiers on seeing h=from, will we still have to specify h=from:from in case we hit an older verifier? Otherwise, just to be safe, we may end up with h=from:from; h2=from; :-/ In addition, the current style of the DKIM specs doesn't dig into the meaning of fields. Rather than being layered on top of 5322, DKIM looks parallel to it: In case one does sign multiple Froms --as it happened upthread-- the resulting signature looks unambiguously valid. If anything is undefined, it is the 5322 semantics, not that of 4871. Introducing knowledge of what fields may occur what number of times would alter that style. Why not also take into account MIME preambles and epilogues, then? After all, I'd keep that handy abbreviation for a revised canonicalization, whenever it will come. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Wietse Venema wrote: If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. It depends on the Application implementation of DKIM. How are you doing it or offering DKIM signer configuration in postfix? Do you have a Required Headers to sign operation option? Let me give you a summary background of events leading up to this. We began to finally go full steam with DKIM integration into our integrated mail framework. I had explored the 2006 revision of the Alt-N open source API to explore all this, and to begin the effort in earnest, I upgraded the API to latest 2009 version which included ADSP support. There were one thing I noticed when I did a diff between the two API versions. The one that stood out was a new signer options: int nAllowUnsignedFromHeaders; // 0 = From headers not included in the // signature are not allowed, 1 = allowed Note I wasn't aware of this multiple from issue yet, so I presumed this was an implementator field experience after three years with a need to relax the RFC 4871 requirement to hash the 5322.From. After all, with the direction to disassociate the author and signer, it felt that was all part of it. There was another related header hashing option that was both in the old and new versions: char szRequiredHeaders[256]; // colon-separated list of headers that // must be signed The API also provides a callback where it passes each 5322 header as it parsed the 5322 message where it wants a TRUE or FALSE function response. This allows an application to prepare a callback to determine what specific headers to sign. The difference is: With a CALL BACK, application be be specific with the headers to sign and only these headers appear in the tag h= values list. With szRequireHeaaders defined, it was not exclusive but added headers that by default the API didn't sign. In other would, by default, the signing function signed ALL headers excluding X-* Authentication-Results: Return-Path: Using szRequiredHeader, would allow you to sign other headers not already signed. But for the application which imports the API into a p-code language for SMTP receiver (verify) and SMTP router (signing) shimming, I could not use the call back method and I needed a way to give operators a configuration method way to allow them which headers should be signed. So I added an option: int nUseRequiredHeadersOnly; // 1 - used szRequireHeaders and exclude the rest which says if szRequiredHeaders is set, then only those headers are signed. I then ask Alt-N about the nAllowUnsignedFromHeaders feature and to inform them if the change I made with nUseRequiredHeadersOnly. That is why I found out why they needed nAllowUnsignedFromHeaders because a customer incident reported the multiple 5322.From issue. I was able to confirm this and I traced the logic of nAllowUnsignedFromHeaders and saw that it doesn't stop multiple 5322.From (N) but rather it enforces that each one was included in the h= tag. So while the trick to add N+1 from values to the h= tag would help mitigate this, we don't know if most applications give an operators option to set the exclusive headers to sign. I did because I wanted to explore different h= headers signing setup especially with integrated list operations. For example, the operator configuration default: #- # Signing Options for author-domain section # # Possible values for canon= # # DKIM_CANON_SIMPLE # DKIM_CANON_NOWSP # DKIM_CANON_RELAXED # DKIM_SIGN_SIMPLE # DKIM_SIGN_SIMPLE_RELAXED # DKIM_SIGN_RELAXED # DKIM_SIGN_RELAXED_SIMPLE # # [AUTHOR-DOMAIN] # signer = SIGNER-DOMAIN# this is the signature d= tag # selector = SELECTOR # this is the signature s= tag # Canon = DKIM_SIGN_SIMPLE # canonization # IncludeBodyLengthTag = 0 # opt, 1 - include l= tag body size # IncludeTimeStamp = 1 # opt, 1 - include t= tag timestamp # IncludeQueryMethod = 0 # opt, 1 - include q= tag # Hash = 1 # req, 1 - SHA1, 2 - SHA256 # IncludeCopiedHeaders = 0 # opt, 1 - use z= tag # Identity =# opt, i= tag # ExpireTime = 0 # opt, days, adds x= tag # UseRequiredHeadersOnly = 1 # opt, 1 - used szRequireHeaders # RequiredHeaders= From:To:Date:Message-Id:Organization:Subject:List-ID
Re: [ietf-dkim] detecting header mutations after signing
Scott Kitterman wrote: Murray S. Kucherawy wrote: Doesn't DKIM try to detect modification of the portion covered by the hashes, which is unchanged in this scenario? For what I view as a very abstract definition of unchanged, sure. I think adding additional From or Subject does change the content of the message From or Subject. If one takes the view that we've defined things such that this is OK from a protocol definition perspective, so it's not an issue, I think we've lost sight of the original goal of this requirement in the protocol. I think that this can be dealt with through an additional security consideration and doesn't have to disrupt the rush to get this advanced through the standards process. +1. Well, then again, one side of my is trying to be cooperative and sensitive of those who want to rush the document. Minimize text with not saying too much. But the other side is saying technically Fix this ASAP - get the proper protocol semantics in in the 4871bis specs and use this incident or at least prepare a response ready against any negative PR that could emerge as a plus to enhancing the marketability of DKIM as a tool that helps solved a 25+ year old problem. -- 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
