Re: [ietf-dkim] The limits of DKIM and SSP
Dave Crocker wrote: Fraudulent From domains are a problem, and they certainly occur in massive numbers, but if bad actors can trivially use alternatives that are not equally protected, fixing only the fraudulent From domain issue is of no long-term benefit. Yes and No. Part of investing in solution comes with an expecting there will be high payoff. Thats a given. In my engineering view, there is a high payoff in eliminating one of the most obvious frauds there is that today we have no real reliable protection against. More importantly, when done as a group, you begin to do something that was never done before - force the bad guy to change or adapt. Help shift the burden and cost to the bad guy. Do nothing? Like today, the bad guy has no incentive to adapt. So if adapting to the other "look-alike" domains, then this will narrow the focus of developing augmented solutions that begin to require learning, heuristics and artificial intelligence methods. But in the mean time, we closed one of the biggest loopholes we have today. We force the bad guys to change - a shift in the cost burden. As such, anything that SSP attempts needs to be evaluated in terms of long-term benefits and the likelihood that there is a simple work-around available to bad actors. That has been done Dave. Unfortunately, you have your own filtering process. And we certainly have not done a threats and work-arounds > analysis for SSP. This is so not true David. What will it take to prove it was already done? What are you looking for? For each proposed SSP feature, there needs to be a statement describing the thread, the way that the feature will mitigate it and some discussion of possible work-arounds and the ease with which they can be used. The analysis had already been done. There were a few proposals centered around it and the RFC 5016 Requirements document and SSP-01 draft are reflections of that 2+ year analysis. That said, I do agree with you there are troubling aspects of it and they were predicted to occur by a few people in the group. I always felt that sound engineering will engineering prevail. To my surprise, I wonder why it took you so long to bring up a few of these critical points that were clearly highlighted many times here. They are the reasons why had did other I-D proposals written. Unfortunately, David, with all due respect, you seem to have your own process of dissemination information. I can suggest that you begin reading input from all interested parties and not just a selected few you deem worthy of your attention. This is not an attack on your person, I have a tremendous amount of respect for you, but it is an observation of whats going on here. -- Sincerely 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] The limits of DKIM and SSP
Graham Murray wrote: Surely the Bank's SSP means that the criminal will not be able to send mail in the banks name as he will not have access to the Bank's signing key. The challenge is the phrase "in the bank's name". 1. SSP does nothing to mitigate against use of the Bank's actual "name" (brand) anywhere in the message, including the display string of the From field, the Subject line or the body. 2. SSP does nothing to mitigate against use of cousin domain's which are likely to confuse some significant percent of recipients. As a consequence, SSP needs to distinguish between attacks on the bank's domain name, versus attacks on the bank's brand and it needs to explain how SSP mitigates each. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Issue #1527: (was: Re: [ietf-dkim] The limits of DKIM and SSP)
Dave, Just looking for a bit more on one of the points you raised. I also changed the subject since this is specific to one of the new issues you raised. [1] Dave Crocker wrote: > And we certainly have not done > a threats and work-arounds analysis for SSP. > > For each proposed SSP feature, there needs to be a statement describing > the thread, the way that the feature will mitigate it and some > discussion of possible work-arounds and the ease with which they can be > used. RFC 4868 [2] does contain some analysis of SSP from a year or so ago. Can you describe some additional threats that aren't covered there that we ought be considering? Or are there parts of the analysis that need revisiting? S. [1] https://rt.psg.com/Ticket/Display.html?id=1527 [2] http://tools.ietf.org/html/rfc4686 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The limits of DKIM and SSP
On Monday 10 December 2007 12:24, Dave Crocker wrote: > Wietse Venema wrote: > > My point is that SSP alone cannot distinguish between mail from my > > Bank and mail from a Criminal who pretends to be a slightly different > > bank. It distinguishes only the stupid criminals who send mail in > > the Bank's name without signature by the Bank. > > ... > > > SSP alone does not distinguish between mail from a Bank and mail > > from a Criminal who pretends to be a bank. That is SSP's dirty > > little secret. > > I think this goes to a core issue point of discrimination that should be > used for considering SSP features: The difference between near-term, > essentially tactical, concerns, versus concerns that are strategic. > > A standard is a very expensive thing. Expensive to develop, expensive to > deploy and typically expensive to use when it pertains to operations issue > and especially to policy issues. > > Hence, a standard should pertain to core, strategic issues, especially when > they are in the security and operations realm. > > Fraudulent From domains are a problem, and they certainly occur in massive > numbers, but if bad actors can trivially use alternatives that are not > equally protected, fixing only the fraudulent From domain issue is of no > long-term benefit. > > As such, anything that SSP attempts needs to be evaluated in terms of > long-term benefits and the likelihood that there is a simple work-around > available to bad actors. > > My own preference is to look for mechanisms that would be good to have, > even if spam and phishing were not serious problems, and then use their > presence merely as motivators for taking immediate action. > > We have extensive, real world precedent for signing messages. > > I believe we do not have any real-world precedent for telling recipients > what to do with mail that is not signed. And we certainly have not done a > threats and work-arounds analysis for SSP. > > For each proposed SSP feature, there needs to be a statement describing the > thread, the way that the feature will mitigate it and some discussion of > possible work-arounds and the ease with which they can be used. > > d/ -1. Been there. Done that. And no, I'm not going to look it up for you. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The limits of DKIM and SSP
Wietse Venema wrote: My point is that SSP alone cannot distinguish between mail from my Bank and mail from a Criminal who pretends to be a slightly different bank. It distinguishes only the stupid criminals who send mail in the Bank's name without signature by the Bank. ... SSP alone does not distinguish between mail from a Bank and mail from a Criminal who pretends to be a bank. That is SSP's dirty little secret. I think this goes to a core issue point of discrimination that should be used for considering SSP features: The difference between near-term, essentially tactical, concerns, versus concerns that are strategic. A standard is a very expensive thing. Expensive to develop, expensive to deploy and typically expensive to use when it pertains to operations issue and especially to policy issues. Hence, a standard should pertain to core, strategic issues, especially when they are in the security and operations realm. Fraudulent From domains are a problem, and they certainly occur in massive numbers, but if bad actors can trivially use alternatives that are not equally protected, fixing only the fraudulent From domain issue is of no long-term benefit. As such, anything that SSP attempts needs to be evaluated in terms of long-term benefits and the likelihood that there is a simple work-around available to bad actors. My own preference is to look for mechanisms that would be good to have, even if spam and phishing were not serious problems, and then use their presence merely as motivators for taking immediate action. We have extensive, real world precedent for signing messages. I believe we do not have any real-world precedent for telling recipients what to do with mail that is not signed. And we certainly have not done a threats and work-arounds analysis for SSP. For each proposed SSP feature, there needs to be a statement describing the thread, the way that the feature will mitigate it and some discussion of possible work-arounds and the ease with which they can be used. 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] The limits of DKIM and SSP
Graham Murray wrote: [EMAIL PROTECTED] (Wietse Venema) writes: My point is that SSP alone cannot distinguish between mail from my Bank and mail from a Criminal who pretends to be a slightly different bank. It distinguishes only the stupid criminals who send mail in the Bank's name without signature by the Bank. Surely the Bank's SSP means that the criminal will not be able to send mail in the banks name as he will not have access to the Bank's signing key. Therefore such mail, irrespective of how stupid or clever the criminal is, would not carry the Bank's signature. The criminal would, of course, be able to send from a domain which makes you think, erroneously, that it comes from your Bank - which is a different problem entirely. +1. Thank your Graham. phishing also includes the form of using a "correctly spelled" domain name. I just got one from eBay this morning which is 100% directly on pay with nearly everything that was discussed here, include the PHISHER awareness that new systems are taking into the account the SENDER. Here is the relevant DNA of the message: Received: from socrate.agmasys.com ([193.201.171.65]) by winserver.com (Wildcat! SMTP v6.2.452.2) with ESMTP id 101035781; Mon, 10 Dec 2007 07:22:20 -0500 Received-SPF: softfail (winserver.com: domain of transitioning [EMAIL PROTECTED] does not designate 193.201.171.65 as permitted sender) Received: from User ([77.237.90.55]) by socrate.agmasys.com (Merak 7.4.2) with ASMTP id EBY38091; Thu, 06 Dec 2007 22:17:40 +0100 From: "eBay Member look4deals999"<[EMAIL PROTECTED]> Subject: Question from eBay Member regarding Item #320189950244 To: [EMAIL PROTECTED] But here is the clever phishing that was added to the top of the body: eBay sent this message on behalf of an eBay member via My Messages. Responses sent using email will not reach the eBay member. Use the Respond Now button below to respond to this message. [LEARN MORE!] [RESPOND NOW] Bot the Learn Mode and Response Now buttons were wrapped with webbot phisher hexed base IP (0x58.0xf8.0x2.0x81)links. So this is a prime case, if ebay was to become a DKIM signer, it can use SSP to help protect against these obvious low level abuses. Of course, eBay.com is a bad example because obviously it has an open policy of providing users email domain addresses. I don't use ebay, so I don't sure what their open policy is. But for a more restricted high value domain, like a Bank and so many others in the commercial world, including us, no doubt, we can benefit from non-signed or fake signature or 3rd party valid signature frauds using SSP with strict DKIM signing policies. -- Sincerely 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] The limits of DKIM and SSP
On Monday 10 December 2007 08:36, Wietse Venema wrote: > Scott Kitterman: > > On Sunday 09 December 2007 10:07, Wietse Venema wrote: ... > > > Conclusion > > > > > > We have a paradox where DKIM-BASE does not promise protection > > > against phishing attacks, but it's near trivial to use for that > > > purpose with a local address book; while SSP protection against > > > phishing can be sidestepped near trivially because it is grounded > > > in statements by a Sender Domain whose trustworthiness is unproven. > > > > Assuming SSP asserts something positive beyond what DKIM asserts. It > > doesn't. It allows a negative to be identified. > > It is not in the Bank's interest to say negative things about the > Banks mail. > > Likewise, it is not in the Criminal's interest to say negative > things about the Criminal's mail. > > SSP alone does not distinguish between mail from a Bank and mail > from a Criminal who pretends to be a bank. That is SSP's dirty > little secret. > > This was my final attempt to illustrate this fundamental problem. > I can lead the horse to the water but I can't force it to drink. Fair enough. Thank you for trying again. I think we are in agreement about what SSP can't do. It seems to me that the fundamental disagreement is about whether the relatively small thing is can do is worth doing or not. What you describe as a "Dirty little secret", I don't think is a secret at all. SSP can help receivers identify exact domain use by external entities. For some classes of domains such use is overhwhelmingly likely to be fradulent and SSP can give receivers a way to reliably identify unauthorized use and reject such mail. It's only a very narrow piece of the phishing problem, but one that I find worth dealing with (even if the end result is just that such messages don't get sent anymore because they stop working). Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The limits of DKIM and SSP
[EMAIL PROTECTED] (Wietse Venema) writes: > My point is that SSP alone cannot distinguish between mail from my > Bank and mail from a Criminal who pretends to be a slightly different > bank. It distinguishes only the stupid criminals who send mail in > the Bank's name without signature by the Bank. Surely the Bank's SSP means that the criminal will not be able to send mail in the banks name as he will not have access to the Bank's signing key. Therefore such mail, irrespective of how stupid or clever the criminal is, would not carry the Bank's signature. The criminal would, of course, be able to send from a domain which makes you think, erroneously, that it comes from your Bank - which is a different problem entirely. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The limits of DKIM and SSP
Scott Kitterman: > On Sunday 09 December 2007 10:07, Wietse Venema wrote: > > After yesterday's massive agreement, today I'll expand some of my > > statements with examples, and expose some limits. > > > > Statement 1 > > > > With DKIM, The Signer Domain says "I signed this mail". It does > > not approve content, or state that content is benign. The receiver > > decides whether to give this signature preferred treatment. There > > is little or no controversy about this aspect of DKIM. > > > > Having the bank's Signer Domain in my local address book, I can > > distinguish between mail that has The Bank's signature (known to > > be good) and mail that does not. When I get mail from a criminal > > bank with a name and logo similar to that of my bank, the criminal > > Signer Domain won't match any bank that I know I have a business > > relationship with, and I can treat it accordingly. > > > > Although I wrote that signers make no statement on content, there > > are valid reasons why a signer might want to do so. For example, > > an email security service provider might want to say "I signed this > > mail" and thus offer assurance that mail is free from malware. Of > > course they would leave any pre-existing signatures intact. > > > > Statement 2 > > > > With SSP, The Sender Domain says "I send such and such mail": if > > any is signed, or not signed. This is primarily relevant for mail > > without valid signature by The Sender Domain. There is little or > > no controversy about this aspect of SSP. > > Agreed, particularly the "without valid signature by The Sender Domain". > > > Some position SSP as a tool against phishing. For example, SSP can > > make statements about mail that claims it is sent in The Sender > > Domain's name, urging receivers not to open any letters that lack > > a valid signature by The Sender Domain. > > > > Unfortunately, this protection is effective only under the assumption > > that the bad guys are stupid; namely that they will try to send > > mail in the name of my bank without a valid signature by my bank. > > But criminals don't necessarily play by the rules. > > I disagree. I think that while the difference is small, I believe there is > worthwhile benifit to preventing what I would call exact domain forgery. > This is not a complete solution to phishing (I'm not sure such a thing > exists), but one small piece. While the difference between (for example - I > didn't check to see if Paypal owns the alternate I show here) paypal.com and > paypa1.com is small, it's a step. > > > Specifically, SSP statements by my bank won't protect ME against > > mail from a Criminal bank with a name and logo similar to that of > > my bank. The Criminal bank will make it 100% SSP compliant and will > > specify the strictest policy settings. Just like the real bank, > > the Criminal's SSP will say "Trust me. I am a high-value target". > > Agreed. Neither (necessarily) will the address book trick you describe in > Statement 1. The address book trick is only one social engineering trick > away from being on the good list. > > > +--+ > > |Why would I believe the SSP from my bank, and not the SSP from the| > > |criminal bank? Based on SSP alone, both have equal credibility. | > > +--+ > > Why would criminal bank's SSP matter? SSP doesn't exist to help make positive > assertions about good messages. It exists to identify messages that fall > outside the senders policy (or whatever we decided the P stood for). Trying > to assert "Passes SSP" as a criteria for acceptance would be a poor idea. Does the Bank's SSP matter? I assume your answer is "yes". My point is that SSP alone cannot distinguish between mail from my Bank and mail from a Criminal who pretends to be a slightly different bank. It distinguishes only the stupid criminals who send mail in the Bank's name without signature by the Bank. > > As discussed under "statement 1", mail from the criminal is easily > > exposed with a simple query against my local address book. The > > criminal Signer Domain won't match any banks that I know I have a > > business relationship with. I don't even have to go to an external > > reputation service for that. > > > > Conclusion > > > > We have a paradox where DKIM-BASE does not promise protection > > against phishing attacks, but it's near trivial to use for that > > purpose with a local address book; while SSP protection against > > phishing can be sidestepped near trivially because it is grounded > > in statements by a Sender Domain whose trustworthiness is unproven. > > Assuming SSP asserts something positive beyond what DKIM asserts. It doesn't. > It allows a negative to be identified. It is not in the Bank's interest to say negative things about the Banks mail. Likewise, it is not in the Criminal's interest to say negative things about the Cr
Re: [ietf-dkim] The limits of DKIM and SSP
On Sunday 09 December 2007 10:07, Wietse Venema wrote: > After yesterday's massive agreement, today I'll expand some of my > statements with examples, and expose some limits. > > Statement 1 > > With DKIM, The Signer Domain says "I signed this mail". It does > not approve content, or state that content is benign. The receiver > decides whether to give this signature preferred treatment. There > is little or no controversy about this aspect of DKIM. > > Having the bank's Signer Domain in my local address book, I can > distinguish between mail that has The Bank's signature (known to > be good) and mail that does not. When I get mail from a criminal > bank with a name and logo similar to that of my bank, the criminal > Signer Domain won't match any bank that I know I have a business > relationship with, and I can treat it accordingly. > > Although I wrote that signers make no statement on content, there > are valid reasons why a signer might want to do so. For example, > an email security service provider might want to say "I signed this > mail" and thus offer assurance that mail is free from malware. Of > course they would leave any pre-existing signatures intact. > > Statement 2 > > With SSP, The Sender Domain says "I send such and such mail": if > any is signed, or not signed. This is primarily relevant for mail > without valid signature by The Sender Domain. There is little or > no controversy about this aspect of SSP. Agreed, particularly the "without valid signature by The Sender Domain". > Some position SSP as a tool against phishing. For example, SSP can > make statements about mail that claims it is sent in The Sender > Domain's name, urging receivers not to open any letters that lack > a valid signature by The Sender Domain. > > Unfortunately, this protection is effective only under the assumption > that the bad guys are stupid; namely that they will try to send > mail in the name of my bank without a valid signature by my bank. > But criminals don't necessarily play by the rules. I disagree. I think that while the difference is small, I believe there is worthwhile benifit to preventing what I would call exact domain forgery. This is not a complete solution to phishing (I'm not sure such a thing exists), but one small piece. While the difference between (for example - I didn't check to see if Paypal owns the alternate I show here) paypal.com and paypa1.com is small, it's a step. > Specifically, SSP statements by my bank won't protect ME against > mail from a Criminal bank with a name and logo similar to that of > my bank. The Criminal bank will make it 100% SSP compliant and will > specify the strictest policy settings. Just like the real bank, > the Criminal's SSP will say "Trust me. I am a high-value target". Agreed. Neither (necessarily) will the address book trick you describe in Statement 1. The address book trick is only one social engineering trick away from being on the good list. > +--+ > > |Why would I believe the SSP from my bank, and not the SSP from the| > |criminal bank? Based on SSP alone, both have equal credibility. | Why would criminal bank's SSP matter? SSP doesn't exist to help make positive assertions about good messages. It exists to identify messages that fall outside the senders policy (or whatever we decided the P stood for). Trying to assert "Passes SSP" as a criteria for acceptance would be a poor idea. > +--+ > > As discussed under "statement 1", mail from the criminal is easily > exposed with a simple query against my local address book. The > criminal Signer Domain won't match any banks that I know I have a > business relationship with. I don't even have to go to an external > reputation service for that. > > Conclusion > > We have a paradox where DKIM-BASE does not promise protection > against phishing attacks, but it's near trivial to use for that > purpose with a local address book; while SSP protection against > phishing can be sidestepped near trivially because it is grounded > in statements by a Sender Domain whose trustworthiness is unproven. Assuming SSP asserts something positive beyond what DKIM asserts. It doesn't. It allows a negative to be identified. > In other words, SSP needs an external service to attest that the > Sender Domain's self-declared SSP does indeed represent a bona fide > business. Supposedly, criminals won't be able to purchase such > attestation. This is the dirty secret behind SSP. I disagree. I think it's the other way around. I think without SSP, some additional secret secret sauce (could be a list of banks you deal with), DKIM buys you little. With SSP there is a complete protocol set available that allows some subset of 'bad' messages to be identified and dealt with appropriatedly. In reality, I think that you are correct and the bad guys will be deterred fr
