Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
I thought I had. Remember that business about 100 million phishing attacks being blocked (DKIM alone would not have delivered that... it was our policy assertion and the acceptance to act on that policy assertion that made this happen)? Right. But then there is the utterly unwarranted leap to claiming that has any connection to ADSP. You published your policy by calling up your friends at large ISPs, not by ADSP. It is a fine idea to have a manually maintained list of the handful of domains where there is an operational benefit to throwing away unsigned mail. I've configured my spamassassin that way. What do I need to show you guys before you accept that I have demonstrated that ADSP provides operational benefit? Something that uses ADSP, rather than a hand-configured list of domains. The key point that Steve and I keep hammering on is that ADSP does not scale, because experience tells us that for every domain in Paypal's situation, a phish target sending only* transaction mail, there will be 100 or 1000 that think it's more secure and will publish discardable even though they're not phish targets and there is real unsigned mail with their return address. The one data point we have about ADSP is the IETF list where the ADSP led to bad results. Does anyone have positive experience with ADSP? I haven't seen any yet. R's, John * - I am optimistically assuming that Paypal is in the process of separating its transaction and individual mail streams so this will be true. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
Steve Atkins and I have explained why that's utterly implausible enough times that anyone who's interested can easily find it in the list archives. With all due respect, the two of you don't constitute consensus, and I don't think abruptly stifling legitimate debate like this serves the working group or the communities we claim to serve at all. It seemed like we were just reiterating well-worn arguments, and I didn't want to be redundant. Sorry if it seemed otherwise. As subsequent messages have shown, there is serious confusion between ADSP and manual discard lists that could stand to be cleared up. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 5/26/10 8:28 PM, Steve Atkins wrote: So it says nothing about the threat it's supposed to thwart. Without that there's no possibility of creating an attack tree. And without that, there's no possibility of doing any security analysis on any proposal. And ADSP is (I think) primarily a security protocol... Start with a few premises: Premise one: Users sort messages based upon important From email-addresses. Premise two: Users mail system does one of the following: a) annotates ADSP results, b) blocks on ADSP non-compliance, i.e. no Author Domain signature with ADSP all or discardable, or c) includes header available for sort criteria, i.e. Authentication-Results I'm pretty sure that ADSP as-is is a bad tool to solve any particular problem. But given it's not being proposed to solve any concrete problem, it's hard to discuss whether there's a better solution. Based on these two premises, clearly 2b and 2c depends far less on a user's recognition of expected results. A very good thing. It is silly to debate whether ADSP is being currently used. ADSP is currently suitable for only an extremely small subset of mail. This unfortunately necessitates use of alternative domains. Using alternative domains in conjunction with domains suitable for ADSP all or discardable significantly erodes the practicality of a sorting mail based upon the From, an important part of domain based protection strategy. Third-party authorization should overcome this issue. The original argument was that it would help deal with phishing, but now even the strongest proponents are happy to explain that it will do absolutely nothing to help with phishing - but go on to say that as it won't help with phishing, the fact that it won't help with phishing isn't a weakness. ADSP alone does not afford complete protection. No one has said otherwise. ADSP needs extended. So what actual operational problem does it attempt to solve? A byte sequence in an email header field that's commonly not shown to the user is not an operational problem. It might be a middle point in a line of reasoning between an operational problem and ADSP. Indeed, ADSP must be viewed as part of a larger strategy. ADSP takes advantage of DKIM's ability to survive forwarding, and to not converge messages into an overly broad IP address authorization scheme. It is common for servers to carry messages from many different domains, where IP address authorization paths remain problematic from an architectural standpoint, and significantly increase a domain's exposure to exploitation. Conversely, ADSP in conjunction with third-party authorization should eliminate a need for alternative domains when taking advantage of third-party services, and will significantly reduce the domain's attack surface. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists BCP draft
Hi Subramanian, Thank you for your comments. On 5/26/10 9:11 PM, SM wrote: Hi Doug, At 14:03 26-05-10, Douglas Otis wrote: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03 I read that draft. Are there any plans for an implementation? By the way, the question is not to brush you off. Murray suggested that at one time, he might be willing. It seems better to first arrive at understanding the need. The draft includes open code that is needed to generate the tpa labels, and has been tested on few systems. The draft was aimed at illustrating how domain based authorization schemes could implemented without imposing an inordinate number of transactions. Since this scheme is only needed to handle a small number of exceptions not practically avoided, its impact should be slight. The third-party scheme could also protect vanity domains signed by major providers who confirm ownership prior to signing, i.e. gmail. Why would unilateral authorization be troubling, since these are also infrequent? In this way, individuals would also be allowed to stray off the reservation, provided they get permission. :^) -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists BCP draft available
On 25/05/2010 18:37, Ian Eiloart wrote: No, and of course a site needn't reject ADSP mail with broken signatures. Indeed, to protect it's members from unwanted unsubscriptions, it might be better to drop the email than reject it. But, then the sender might never discover what they're doing wrong. Worse, such a configuration would do collateral damage: other broken ADSP cases (forwarders which aren't mailing-lists in the sense that we're describing) would lead to silent message loss. If the recipient rejects the message, then the list should be able to bounce back to the sender, since it was originally properly signed. Ideally, but without a reliable indication by the receiver that the refusal was for DKIM failure, there's no easy way for the MLM to know which bounces to return to the sender. - Roland -- Roland Turner | Director, Professional Services Group BoxSentry Pte Ltd | 3 Phillip Street #13-03, Singapore 048693 Mobile: +65 96700022 | Skype: roland.turner roland.tur...@boxsentry.com | http://www.boxsentry.com/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists BCP draft
On 26/05/2010 23:40, Brett McDowell wrote: This is a good example of a tradeoff that I think would benefit from some agreed upon principles. If we agreed to the following two principles, I think we'd all find a lot more common ground: 1) Authenticated email is optional, not required 2) We desire to fully enable the functionality of the authenticated email ecosystem, but 3) We will do nothing with the authenticated email architecture that forces non-participating email stakeholders harm/breakage/errors That would be three principles, and I think they're sound. This does leave us somewhere rather unpleasant for: - sender from a discardable domain sends to a mailing list, despite the advice being not to - the MLM is a non-participant - a subscriber is rejecting messages which fail DKIM authentication (conservative stance: avoid silent failures causing mail loss) - the MLM unsubscribes the recipient for [multiple] refusals In this case, a participating-but-conservative receiver cops collateral damage because of incorrect/ill-advised behaviour by a sender. This is an undesirable outcome. I'd strengthen #3 with unrelated harm/breakage/errors should not arise from participating stakeholders behaving conservatively. - Roland -- Roland Turner | Director, Professional Services Group BoxSentry Pte Ltd | 3 Phillip Street #13-03, Singapore 048693 Mobile: +65 96700022 | Skype: roland.turner roland.tur...@boxsentry.com | http://www.boxsentry.com/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists BCP draft
Roland Turner roland.tur...@boxsentry.com wrote: On 26/05/2010 22:48, Steve Atkins wrote: However, domain B is not an innocent bystander, as they intentionally configured their mail system to reject mail it shouldn't, and the recipients at domain B support that decision, on some level. Domains don't subscribe to mailing lists, individual recipients do. The recipients in a domain may oppose the domain[-administrator]'s decision, but often lack the power to have it changed. Failure to quit your job cannot reasonably be construed as consent/support in this context. This just brings us back to the Do domain owners have a right to control how their domains get used in email question. If they do, the point is irrelevant. If they don't, email authentication policy is wrong and we should just stop. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
Since these are all rhetorical questions, let's cut to the chase: do you believe John, who never believed in ADSP and has repeatedly said that he hope it fails, and who has a microscopic amount of deployment experience if any at all. Or do we believe Brett/paypal that ADSP is providing benefit *today* in the form of 100's of millions of thwarted phishes, and that ADSP is the only way he can get things to scale beyond handshakes in the Valley. Maybe I'm crazy, but I give cred to the guy with operational experience. Mike On 05/26/2010 11:05 PM, John Levine wrote: I thought I had. Remember that business about 100 million phishing attacks being blocked (DKIM alone would not have delivered that... it was our policy assertion and the acceptance to act on that policy assertion that made this happen)? Right. But then there is the utterly unwarranted leap to claiming that has any connection to ADSP. You published your policy by calling up your friends at large ISPs, not by ADSP. It is a fine idea to have a manually maintained list of the handful of domains where there is an operational benefit to throwing away unsigned mail. I've configured my spamassassin that way. What do I need to show you guys before you accept that I have demonstrated that ADSP provides operational benefit? Something that uses ADSP, rather than a hand-configured list of domains. The key point that Steve and I keep hammering on is that ADSP does not scale, because experience tells us that for every domain in Paypal's situation, a phish target sending only* transaction mail, there will be 100 or 1000 that think it's more secure and will publish discardable even though they're not phish targets and there is real unsigned mail with their return address. The one data point we have about ADSP is the IETF list where the ADSP led to bad results. Does anyone have positive experience with ADSP? I haven't seen any yet. R's, John * - I am optimistically assuming that Paypal is in the process of separating its transaction and individual mail streams so this will be true. ___ 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
[ietf-dkim] bad mail blowback
On 05/27/2010 03:21 AM, Roland Turner wrote: On 26/05/2010 22:48, Steve Atkins wrote: However, domain B is not an innocent bystander, as they intentionally configured their mail system to reject mail it shouldn't, and the recipients at domain B support that decision, on some level. Domains don't subscribe to mailing lists, individual recipients do. The recipients in a domain may oppose the domain[-administrator]'s decision, but often lack the power to have it changed. Failure to quit your job cannot reasonably be construed as consent/support in this context. So this problem is obviously larger than just discardable. This can happen any time a list member gets a piece of mail that the filter in the receiving domain finds objectionable for *whatever* reason. So what we're really talking about is a 5822 problem, not a DKIM/ADSP problem. So the question is, in my mind, should the receiver just silently discard it which breaks reliability but allows the MLM to do nothing special, or should the receiver bounce/5xx it back. To my mind, if the MLM is going to do something as drastic kick the receiving user, it ought to at least be open to a 5xx explanation that it's the mail in question that's the problem instead of blindly giving the user X number of 5xx's before they're declared a nuisance and kicked. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
do you believe John, who never believed in ADSP and has repeatedly said that he hope it fails, and who has a microscopic amount of deployment experience if any at all. Or do we believe Brett/paypal that ADSP is providing benefit *today* in the form of 100's of millions of thwarted phishes, and that ADSP is the only way he can get things to scale beyond handshakes in the Valley. Indeed. Only, I think it's a little more complicated than that. PayPal has good experience with independent arrangements that behave like ADSP, and they expect it to translate to good and broader experience with ADSP. On the other hand, they have some bad experience with ADSP, which they expect to meliorate with a change that Brett hasn't described yet. On the other hand, John and Steve expect that the benefits PayPal is seeing in thwarted phishing messages will be short-lived, as phishers just change domain names, and send out just as many messages as before, fooling just as many recipients into thinking they're from PayPal. We will certainly need data collected over time to determine whether there's any long-term reduction in unblocked phishing messages as a result of ADSP. I'm eager to get that data. We'll also need some analysis of whether (and why) PayPal sees some real value in ensuring that successful PayPal phishing messages do not actually have paypal.com in the from field. I'm eager to see that, too. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] bad mail blowback
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Thursday, May 27, 2010 6:22 AM To: Roland Turner Cc: DKIM List Subject: [ietf-dkim] bad mail blowback So the question is, in my mind, should the receiver just silently discard it which breaks reliability but allows the MLM to do nothing special, or should the receiver bounce/5xx it back. To my mind, if the MLM is going to do something as drastic kick the receiving user, it ought to at least be open to a 5xx explanation that it's the mail in question that's the problem instead of blindly giving the user X number of 5xx's before they're declared a nuisance and kicked. This is something the lists BCP could discuss. Perhaps something like: bounces with enhanced status codes of 5.7.1 should not be counted against the recipient as they are done for message-specific policy reasons and not for something more general. (I might have the 5.7.1 wrong, but you get the idea.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 05/27/2010 07:05 AM, Barry Leiba wrote: do you believe John, who never believed in ADSP and has repeatedly said that he hope it fails, and who has a microscopic amount of deployment experience if any at all. Or do we believe Brett/paypal that ADSP is providing benefit *today* in the form of 100's of millions of thwarted phishes, and that ADSP is the only way he can get things to scale beyond handshakes in the Valley. Indeed. Only, I think it's a little more complicated than that. PayPal has good experience with independent arrangements that behave like ADSP, and they expect it to translate to good and broader experience with ADSP. On the other hand, they have some bad experience with ADSP, which they expect to meliorate with a change that Brett hasn't described yet. On the other hand, John and Steve expect that the benefits PayPal is seeing in thwarted phishing messages will be short-lived, as phishers just change domain names, and send out just as many messages as before, fooling just as many recipients into thinking they're from PayPal. We will certainly need data collected over time to determine whether there's any long-term reduction in unblocked phishing messages as a result of ADSP. I'm eager to get that data. We'll also need some analysis of whether (and why) PayPal sees some real value in ensuring that successful PayPal phishing messages do not actually have paypal.com in the from field. I'm eager to see that, too. The problem with the cross examination that John and Steve are trying to perform is that the witnesses are under no obligation to respond. And, quite reasonably, they don't. I have absolutely no doubt in my mind that paypal, for example, has a huge amount of infrastructure and practical knowledge about the lookalike domain problem. I'm also completely unsurprised that they aren't leaping out into the fray in a public forum to tell us how they deal with it, and how exactly ADSP fits into their plans. I am happy that they have told us that ADSP is instrumental to their plans even if out of necessity they need to leave it at face value. I'm sorry that John and Steve aren't satisfied with a company keeping their secret sauce... secret, but that's just how these things work. Especially for security procedures. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] bad mail blowback
On 05/27/2010 07:35 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Thursday, May 27, 2010 6:22 AM To: Roland Turner Cc: DKIM List Subject: [ietf-dkim] bad mail blowback So the question is, in my mind, should the receiver just silently discard it which breaks reliability but allows the MLM to do nothing special, or should the receiver bounce/5xx it back. To my mind, if the MLM is going to do something as drastic kick the receiving user, it ought to at least be open to a 5xx explanation that it's the mail in question that's the problem instead of blindly giving the user X number of 5xx's before they're declared a nuisance and kicked. This is something the lists BCP could discuss. Perhaps something like: bounces with enhanced status codes of 5.7.1 should not be counted against the recipient as they are done for message-specific policy reasons and not for something more general. (I might have the 5.7.1 wrong, but you get the idea.) Considering that this is really a 5822 level problem, I have my doubts that a DKIM/ADSP targeted document is the right place to bury this kind of advice. And I'm also skeptical that we have the right set of eyes looking at this in this working group because this is certainly a very old topic and it would be stupid of us to come out with advice that goes against or without the consent of the much larger smtp community. On the other hand, if the larger email community already has a normative or BCP solution to this which we can just restate, then that's great. (which might be what you're getting at). Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Wed, May 26, 2010 at 11:28 PM, Steve Atkins st...@wordtothewise.com wrote: So what actual operational problem does it attempt to solve? A byte sequence in an email header field that's commonly not shown to the user is not an operational problem. It might be a middle point in a line of reasoning between an operational problem and ADSP. So I understand your line of reasoning. But today, I believe ADSP can provide a benefit. Brett has data that supports that. It may have a limited lifetime. But I don't think this will be the only RFC that has a limited lifetime in the transition to an authenticated email universe. Stating the obvious, in an Authenticated world, services that were designed in a non-Authenticated world will break authentication. A complex authentication protocol might be designed to work with services that don't support authentication, but I think that is a futile attempt. It makes sense to me to go to each of these services, see if there is a consensus in the value proposition of authenticated email, and help modify those services to work in an Authenticated world. I'd also advocate not changing the authentication part to make it work with a service. That just adds complexity. My two cents. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] bad mail blowback
-Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Thursday, May 27, 2010 7:49 AM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] bad mail blowback Considering that this is really a 5822 level problem, I have my doubts that a DKIM/ADSP targeted document is the right place to bury this kind of advice. And I'm also skeptical that we have the right set of eyes looking at this in this working group because this is certainly a very old topic and it would be stupid of us to come out with advice that goes against or without the consent of the much larger smtp community. I think it's appropriate since ADSP is creating the problem (or in your view, extending the existing problem). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists BCP draft
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, May 27, 2010 7:28 AM To: DKIM List Subject: Re: [ietf-dkim] more on discardable, was Lists BCP draft Roland Turner roland.tur...@boxsentry.com wrote: On 26/05/2010 22:48, Steve Atkins wrote: However, domain B is not an innocent bystander, as they intentionally configured their mail system to reject mail it shouldn't, and the recipients at domain B support that decision, on some level. Domains don't subscribe to mailing lists, individual recipients do. The recipients in a domain may oppose the domain[-administrator]'s decision, but often lack the power to have it changed. Failure to quit your job cannot reasonably be construed as consent/support in this context. This just brings us back to the Do domain owners have a right to control how their domains get used in email question. If they do, the point is irrelevant. If they don't, email authentication policy is wrong and we should just stop. Scott K +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists BCP draft
Hi Doug, At 03:20 27-05-10, Douglas Otis wrote: Murray suggested that at one time, he might be willing. It seems better to first arrive at understanding the need. Don't read anything in here as a statement of support for the draft. Convince Daniel to write the code. :-) It can be committed as a FFR. The draft includes open code that is needed to generate the tpa labels, and has been That's not how the project works. Someone has to do the work and help the users when they have questions. Obviously, any comments from marketing departments are discouraged. Why would unilateral authorization be troubling, since these are also infrequent? Once the code is out there, it may be easier to find an answer to that question. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] bad mail blowback
On Thu, May 27, 2010 at 10:35 AM, Murray S. Kucherawy m...@cloudmark.com wrote: (I might have the 5.7.1 wrong, but you get the idea.) Ah, my type of tangent. I think 5.7.1 is right. Ideally, in the future, it would be a 5.8.z. But before even that, we need more folks to support RFC3463. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] bad mail blowback
At 07:49 27-05-10, Michael Thomas wrote: Considering that this is really a 5822 level problem, I have my doubts that a DKIM/ADSP 5322. :-) targeted document is the right place to bury this kind of advice. And I'm also skeptical that we have the right set of eyes looking at this in this working group because this is certainly a very old topic and it would be stupid of us to come out with advice that goes against or without the consent of the much larger smtp community. There's a discussion of local policy in Section 6.3 of RFC 4871. I'll emphasize the first sentence of that section: It is beyond the scope of this specification to describe what actions a verifier system should make. In terms of implementation, we might be doing some rejects at the SMTP level. I refrained from suggesting having that as part of the default knobs because of the odd cases. I am wary about going beyond the RFC 5322 level for some of the reasons you stated above and because DKIM does not operate at that level. At 07:53 27-05-10, Murray S. Kucherawy wrote: I think it's appropriate since ADSP is creating the problem (or in your view, extending the existing problem). Maybe, but this is the kind of thing where some people will take the simplistic answer and ignore the caveats. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] bad mail blowback
-Original Message- From: SM [mailto:s...@resistor.net] Sent: Thursday, May 27, 2010 10:06 AM To: ietf-dkim@mipassoc.org Cc: Michael Thomas; Murray S. Kucherawy Subject: Re: [ietf-dkim] bad mail blowback At 07:53 27-05-10, Murray S. Kucherawy wrote: I think it's appropriate since ADSP is creating the problem (or in your view, extending the existing problem). Maybe, but this is the kind of thing where some people will take the simplistic answer and ignore the caveats. True, but that doesn't mean it's not worth saying. I'd rather say it to what limited audience this draft might have than not say it at all. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] FW: RFC 5863 on DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
Congrats, team! -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of rfc-edi...@rfc-editor.org Sent: Thursday, May 27, 2010 11:27 AM To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org Cc: ietf-dkim@mipassoc.org; rfc-edi...@rfc-editor.org Subject: RFC 5863 on DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations A new Request for Comments is now available in online RFC libraries. RFC 5863 Title: DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations Author: T. Hansen, E. Siegel, P. Hallam-Baker, D. Crocker Status: Informational Stream: IETF Date: May 2010 Mailbox:tony+dki...@maillennium.att.com, d...@esiegel.net, phil...@hallambaker.com, dcroc...@bbiw.net Pages: 51 Characters: 126915 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dkim-deployment-11.txt URL:http://www.rfc-editor.org/rfc/rfc5863.txt DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of spam and phishing. This document provides implementation, deployment, operational, and migration considerations for DKIM. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Domain Keys Identified Mail Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 5/27/10 7:53 AM, Jeff Macdonald wrote: So I understand your line of reasoning. But today, I believe ADSP can provide a benefit. Brett has data that supports that. It may have a limited lifetime. But I don't think this will be the only RFC that has a limited lifetime in the transition to an authenticated email universe. Stating the obvious, in an Authenticated world, services that were designed in a non-Authenticated world will break authentication. A complex authentication protocol might be designed to work with services that don't support authentication, but I think that is a futile attempt. Disagree. The number of exceptions needed are few. A single transaction can mitigate issues related to third-party services that don't exchange DKIM keys. Such a scheme offers comprehensive protections without a long wait for something far less practical. Since DKIM and ADSP directly benefits senders by ensuring their messages are not obscured, it seems only right that senders, rather than recipients, carry the larger burden. For most financial organizations, this burden will be slight. It makes sense to me to go to each of these services, see if there is a consensus in the value proposition of authenticated email, and help modify those services to work in an Authenticated world. I'd also advocate not changing the authentication part to make it work with a service. That just adds complexity. Authorization is separate mechanism from DKIM's authentication a domain. The authentication methods will not change. However, ADSP polices should be able encompass third-party authorization for services that don't exchange DKIM private keys needed to produce Author-Domain signatures. Authorization is far simpler than coordinated and complex exchanges of private keys or indirect and moving publications of public keys among two or more administrative entities. Yuck. An authorization can be made unilaterally without complex coordination. An authorization can remain static, even when keys roll over. To better answer Steve's criticisms on phishing, our company among others, offers browser plugins for web mail and popular email applications that annotate messages using corporate icons. Users can afford themselves similar protections by sorting email based upon the From email address and the DKIM/ADSP results. It seems reasonable to expect these functions will become easier to employ. They are not that hard now. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 27, 2010, at 10:39 AM, Michael Thomas wrote: The problem with the cross examination that John and Steve are trying to perform is that the witnesses are under no obligation to respond. And, quite reasonably, they don't. I appreciate the support, but I didn't want to leave anyone with the false impression that I had abandoned the debate just because I hadn't responded to the list in the past 22 hours or so. Although I do consider some of the counter-arguments as FUD and/or deliberately obtuse, I've actually tried to be responsive to all questions and comments on the list since joining. For better or worse I'm in for penny, in for a pound. I've been in standards development for awhile... I'm not that easily discouraged ;-) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 27, 2010, at 10:05 AM, Barry Leiba wrote: do you believe John, who never believed in ADSP and has repeatedly said that he hope it fails, and who has a microscopic amount of deployment experience if any at all. Or do we believe Brett/paypal that ADSP is providing benefit *today* in the form of 100's of millions of thwarted phishes, and that ADSP is the only way he can get things to scale beyond handshakes in the Valley. Indeed. Only, I think it's a little more complicated than that. PayPal has good experience with independent arrangements that behave like ADSP, and they expect it to translate to good and broader experience with ADSP. More than expecting to, we are actively working on deployments with parties interested in opting-in to this open, standards-based, authenticated email ecosystem. Unfortunately for the sake of this debate, I cannot disclose who just yet. On the other hand, they have some bad experience with ADSP, which they expect to meliorate with a change that Brett hasn't described yet. Ya but... we have a handful of emails that have gone into spam filters (and due to the natural dynamics of MLM's those have probably *all* been recovered with no net communication loss at the end of the day) vs. thwarting over 100 million attacks. So yes, there are things we can do to remove what little down-side we've seen, the status quo is pretty much all up-side from our perspective when put into context. There isn't even a whisper of abandoning ADSP within PayPal. Our only thought is on accelerating more and more deployments across the Internet. I'm in this WG to help make the overall architecture (through BCP's, spec enhancements, new spec's, etc.) just that much easier to deploy with clearer and more reliable expectations for stakeholders who participate. I hope others are here for the same reason. On the other hand, John and Steve expect that the benefits PayPal is seeing in thwarted phishing messages will be short-lived, as phishers just change domain names, and send out just as many messages as before, fooling just as many recipients into thinking they're from PayPal. I understand that argument, but even if that were happening (and it isn't happen to us) we would have removed an attack vector. That's *always* worth doing. Defense in depth. No one is looking for a silver bullet. BTW, some of the theoretical arguments for how criminals can game ADSP neglect to consider other elements of the infrastructure might also evolve to be more full participants in the authenticated email ecosystem, e.g. MUA's that change the way they currently work to make these consumer protection applications more robust. We will certainly need data collected over time to determine whether there's any long-term reduction in unblocked phishing messages as a result of ADSP. I'm eager to get that data. We'll also need some analysis of whether (and why) PayPal sees some real value in ensuring that successful PayPal phishing messages do not actually have paypal.com in the from field. I'm eager to see that, too. I'm working on publishing more of our experience, not to mention working in organizations like BITS, MAAWG, OTA, etc. in an effort to get more data from across the Internet put into play. ADSP hasn't been around very long folks... I think we are moving pretty fast actually. It's just not reasonable to expect many ADSP deployments right now, let alone ADSP=discardable. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 27, 2010, at 1:25 AM, Steve Atkins wrote: On May 26, 2010, at 9:24 PM, SM wrote: At 11:20 26-05-10, Murray S. Kucherawy wrote: I've written code implementing all of this stuff, but I've never run it in an operational environment of the size or nature that Brett does. So I want to hear what he has to say until there's consensus to the contrary. I would like to hear what Brett has to say. I would also like to hear from the people who have implemented MLMs and those who have been quiet. I'd be interested in seeing Brett's data and methodology too. Cheers, Steve It would probably help me if you folks could send me questions (probably off-list as I'm not sure how relevant this is to the WG scope) that I can use as a guide for exactly how to wrangle our data into a publishable state. I've been thinking about how to present our experience but that might not align exactly with what folks want/need to know. So I'd appreciate specific questions (think database query and/or FAQ) that I could work from. Thank you (in advance) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 26, 2010, at 11:28 PM, Steve Atkins wrote: I'm pretty sure that ADSP as-is is a bad tool to solve any particular problem. But given it's not being proposed to solve any concrete problem, it's hard to discuss whether there's a better solution. Are you deliberately ignoring the data I provided... at your request for data? The original argument was that it would help deal with phishing, but now even the strongest proponents are happy to explain that it will do absolutely nothing to help with phishing I'm sorry, I'm not only arguing that it absolutely DOES help with phishing, I've provided real data (vs. theory). Steve, I saw you give a presentation in February and I was very impressed by both your technical knowledge and your overall common sense. I consider you both intelligent and wise. But I cannot explain the position you've taken on the ADSP issue on this mail list. What other solutions on top of DKIM would you like to see the Internet adopt instead of ADSP... something open, interoperable, and royalty-free I hope! ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 26, 2010, at 5:00 PM, Steve Atkins wrote: On May 26, 2010, at 12:46 PM, Brett McDowell wrote: Paypal is claiming an operational benefit, but haven't actually demonstrated that ADSP either provides that benefit, nor that those benefits can't be provided in a significantly cheaper manner. I thought I had. Remember that business about 100 million phishing attacks being blocked (DKIM alone would not have delivered that... it was our policy assertion and the acceptance to act on that policy assertion that made this happen)? Should ADSP be deployed widely, and it were to be used by PayPal, then any of the smarter phishers would not continue to send mail that would not be delivered. That's rational, but theoretical and not supported by what we are seeing. We are stopping phish every day in large quantities. Based on your logic, that would have stopped by now. But it hasn't. I could have a lengthy talk about why we believe it hasn't stopped, but I think that would be a tangent. They would continue to send phish email, of course, just not of a form that would be blocked by ADSP. At best this would cause the badly done phishing emails to be blocked while allowing the ones sent by smarter criminals to be delivered. You are making too many assumptions. The biggest is probably that MUA's won't evolve to address the display name vs. author domain issue. Given that, it's not something that will provide any benefit once ADSP is deployed - maybe just the opposite, as it will effectively neuter the approach you're currently using. You may win the battle of preventing use of the string paypal.com in the non-displayed part of the From: field, yet lose the war of protecting your users from phishers. I know you guys are security experts and I'm in no position to lecture you on best practices, but seeing some of these arguments makes me think we need a quick reminder of the bigger picture... defense in depth. Removing an attack vector is a good thing. Then you remove the next one, etc. What do I need to show you guys before you accept that I have demonstrated that ADSP provides operational benefit? You need to go beyond We do this to We do this, and our opponents will respond with that, Really?!... now you are talking theory not data. You are using the crystal ball. Sure, you can see real possibilities even now, but that's not data. That said, if it's within the scope of this WG to talk about the next layer of what we can/should do after we have shut-off the vector that DKIM+ADSP=discardable enables us to shut-off, we can start working on that too. I'd participate in that... but I'd lower the priority on that longer-term planning compared to the short-term of using and enhancing what we already have. and we will respond with the other At some point you keep some of those cards in your hand until you have to show them. We are talking about crime-fighting after all. This isn't a protocol that's used solely between honest peers, it's something that is solely for thwarting bad guys in a hostile environment. Granted, the consumer protection use case are what matter most to me, but there are several folks who care more about deliverability. So the assertion above is not true in the deliverability case. And how do use the ADSP protocol to thwart bad guys if not by a coalition of the willing among honest peers? Should we be dismissive of SSL just because it's only for thwarting bad guys? Where would eCommerce be today without SSL? There are clearly approaches that can be build on top of DKIM that would be extremely effective in that environment. There's no data so far to suggest that ADSP is one of them. Again, I'm feeling a bit ignored which is frustrating since it was you who asked me to provide the data that you now seem to be dismissing. (ADSP could provide benefits when combined with something like certification or whitelisting - but in those cases you can skip the publication of ADSP records altogether, and apply the certification or whitelisting results directly, based on DKIM authentication). I thought this was the Internet ETF. So shouldn't we be concerned with solving these use cases using Internet technologies vs. closed, proprietary, silo-ed one-off solutions? But you are correct, if we fail, that's exactly what will happen. In fact, I think we are in a bit of a horse race at this point. So I'd love to see us stop debating the shape of the table and get back to write a BCP or a spec or something tangible and useful. And every bit of ISP or sender resources or mindshare that is consumed by ADSP is focus that's not expended on approaches that are likely to be more effective, both immediately and longer term. Something corresponding to extended validation SSL certificates, perhaps. Any proposals? ___ NOTE WELL: This list
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 27, 2010, at 3:41 PM, Dave CROCKER wrote: More than expecting to, we are actively working on deployments with parties interested in opting-in to this open, standards-based, authenticated email ecosystem. Unfortunately for the sake of this debate, I cannot disclose who just yet. A problem, here, is that you are using that citation as a kind of proof of the correctness of your position, but we do not have access to the data to make an independent assessment. It was offered in the spirit of being helpful since so many people on the list believe (and assert) that no one is using ADSP. Actually in my standards development experience (almost entirely in fora outside of IETF) it is somewhere between unusual and disallowed to ask for or provide any information about deployment or product plans. I think I have not done anything here that violates anti-trust law, but I take your point and will refrain from any other references to non-public data. On the average, much of the argumentation in this thread -- by most of the participants -- seems to be in a style that asserts one person's expertise over another's, and generally seems inclined to refrain from considering details either for or against a position. Ad hominen or hostile tone is then mixed in to make the defender (or attacker) feel superior while nonetheless failing to respond with substance. As a newbie to this list, I have to say I agree. This has been a far less collegial debate than what I'm used to. That said, I may be guilty of reciprocating, and if anyone feels they have been on the receiving end of such, I apologize. In a serious discussion, I'd expect to see someone's offering a specific criticism, concern, counter-example or the like to get a response that incorporates what was offered, responding to the particulars. For some reason, discussion here seems to be resistance to such a substantive clarifying efforts. I would welcome this moment of retrospection as a turning point in how we progress out deliverables in a more efficient, informed, and collegial manner. I take it that you will be operating under this general rubric going forward as well. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 5/27/2010 1:30 PM, Brett McDowell wrote: On May 27, 2010, at 3:41 PM, Dave CROCKER wrote: A problem, here, is that you are using that citation as a kind of proof of the correctness of your position, but we do not have access to the data to make an independent assessment. It was offered in the spirit of being helpful since so many people on the list believe (and assert) that no one is using ADSP. I don't recall seeing anyone say no one is using ADSP and even if there is a counter-example, I certainly believe that it is not so many people. At the least, we need to distinguish between people who are broadly dismissive, versus people who are specifically critical. What I /do/ recall seeing is some people being highly dismissive of its strategic benefit. I recall seeing one or more responses that are highly dismissive of those views, in return. Not what one would call a constructive approach to dialogue. I also recall seeing some people offer particular criticisms of the breadth of its utility. That is, I recall seeing one or more people observe that the ability to take an ADSP-like tool that is used in a very particular scenario does not necessarily generalize for making predictions about ADSP's own utility. That methodological challenge has not fared well. Actually in my standards development experience (almost entirely in fora outside of IETF) it is somewhere between unusual and disallowed to ask for or provide any information about deployment or product plans. I think I have not done anything here that violates anti-trust law, but I take your point and will refrain from any other references to non-public data. Product plans are certainly never reasonable to expect to hear. It's dandy if someone offers them, but quite gauche to expect or demand that they be divulged. Deployment and ops experience depends on its nature. The reality, here, is that Paypal and its friends have developed a proprietary capability that appears to be quite similar to what ADSP is attempting. It is common and constructive to seek to develop an open standard that is based on earlier, proprietary work. (Note that DKIM is an example.) Whether based on is merely conceptual or actually entails merely incrementing the technical details isn't the issue. Benefiting from field experience is the issue. That makes it attractive for analysis. On the other hand, the technical details might actually be too different for comparison. Equally, the details of the usage scenario might be highly restrictive and therefore not (likely to) generalize for the broader Internet. What works for a small group of friends might or might not work for hundreds of millions of strangers. That a particular mechanism does not scale to a large number of participants is a red flag for standardization, although it does not automatically preclude standardization. At the least, careful consideration of scaling issues is required. Handwaving in either direction can't possibly be productive. On the average, much of the argumentation in this thread -- by most of the participants -- seems to be in a style that asserts one person's expertise over another's, and generally seems inclined to refrain from considering details either for or against a position. Ad hominen or hostile tone is then mixed in to make the defender (or attacker) feel superior while nonetheless failing to respond with substance. As a newbie to this list, I have to say I agree. This has been a far less collegial debate than what I'm used to. That said, I may be guilty of reciprocating, and if anyone feels they have been on the receiving end of such, I apologize. The DKIM wg has had a particularly rocky history, in this regard. Security is technically challenging. Anti-abuse is technically, operationally and politically challenging. And some of us personally are, u, challenging. A perfect storm, of a sort... In a serious discussion, I'd expect to see someone's offering a specific criticism, concern, counter-example or the like to get a response that incorporates what was offered, responding to the particulars. For some reason, discussion here seems to be resistance to such a substantive clarifying efforts. I would welcome this moment of retrospection as a turning point in how we progress out deliverables in a more efficient, informed, and collegial manner. I take it that you will be operating under this general rubric going forward as well. mais oui! (I don't use smileys, but if I didn't, I'd look for one to insert here that shows wide-eyed innocence...) 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] list vs contributor signatures, was Wrong Discussion
On May 27, 2010, at 12:46 PM, Brett McDowell wrote: On May 26, 2010, at 11:28 PM, Steve Atkins wrote: I'm pretty sure that ADSP as-is is a bad tool to solve any particular problem. But given it's not being proposed to solve any concrete problem, it's hard to discuss whether there's a better solution. Are you deliberately ignoring the data I provided... at your request for data? Not at all. It's interesting, but it's only marginally related to ADSP. You're taking data based on a private relationship at a small number of consumer ISPs, for a very specific subset of mail and using that as data to directly support a protocol based on self-publication by a large number of different parties that would be acted upon by more than just a couple of consumer freemail providers. (If that weren't the case, there'd be no point in standardising a self-publication approach such as ADSP). Additionally, the data you've provided that I've seen isn't that useful as it only provides one of the four useful numbers in the legitimate vs phish, rejected by ADSP vs not rejected matrix. To give you a bit more idea of what I mean by that, I've pulled some data out of my mailbox, looking at emails that were both legitimate paypal mail, and which were clear phish emails targeting paypal. For each of those I worked out whether it would have been accepted or rejected based solely on ADSP dkim=discardable if they'd been signed when sent. I'll write up the methodology in a little more detail, but out of my sample the initial data is: Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% rejected. This is based on mail to my mailbox, but other than that it's a pretty fair sample, if anything it's fairly heavily skewed towards phish emails that would be rejected by ADSP (as it's based on emails with the string paypal in the From: line, which includes all phish mail that would be rejected, but excludes quite a lot of phish mail that wouldn't be). It's a small sample, but that means I've been able to identify and confirm manually the status of each email. (It does ignore the fact that Paypal acquires an awful lot of lookalike domains, partly because that's something it's hard to analyze after the fact but mostly because buy every domain in every TLD that has my company name in it is not a behaviour that scales at all.) It's also based on sender behaviour before there's significant actual filtering via ADSP. I would expect less mail, both legitimate and illegitimate, to be rejected by ADSP as time went on. That's real data, not theory, for the current state of the paypal related mailstream as I personally see it. I think I can extrapolate from there to what'll happen to that specific mail stream were ADSP to be widely adopted, but that'd be speculation. The original argument was that it would help deal with phishing, but now even the strongest proponents are happy to explain that it will do absolutely nothing to help with phishing I'm sorry, I'm not only arguing that it absolutely DOES help with phishing, I've provided real data (vs. theory). Steve, I saw you give a presentation in February and I was very impressed by both your technical knowledge and your overall common sense. I consider you both intelligent and wise. But I cannot explain the position you've taken on the ADSP issue on this mail list. I think DKIM is a Good Thing that should be widely deployed. ADSP is broken in many respects, and because it's tied to DKIMs mindshare that brokenness deters DKIM adoption. So I believe that ADSP needs to be fixed or it needs to be allowed to die. What other solutions on top of DKIM would you like to see the Internet adopt instead of ADSP... something open, interoperable, and royalty-free I hope! I can think of several, and I'd be more than happy to sit down and discuss them at some point over a beer, but I'm hearing enough grumbling from the chairs about what's on topic and what isn't already[1]. Cheers, Steve [1] Domain whitelists operated by FDIC, DB etc, for real businesses in a particular niche, or certificates based on vetting, a-la the green bar are two obvious ones, though. The green bar and extended verification certs is what PayPal is really relying on to avoid phishing right now, AFAICT. It's simple and effective and easy for consumers to understand. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 27, 2010, at 2:22 PM, Steve Atkins thinkoed: Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% rejected. That should be Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% not rejected. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
I must have missed an email or something... what's the context for and/or source of this data? On May 27, 2010, at 5:57 PM, Steve Atkins wrote: On May 27, 2010, at 2:22 PM, Steve Atkins thinkoed: Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% rejected. That should be Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% not rejected. 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] list vs contributor signatures, was Wrong Discussion
(disregard previous, I did miss this message Steve... I have the context now... a few comments below) On May 27, 2010, at 5:22 PM, Steve Atkins wrote: On May 27, 2010, at 12:46 PM, Brett McDowell wrote: On May 26, 2010, at 11:28 PM, Steve Atkins wrote: I'm pretty sure that ADSP as-is is a bad tool to solve any particular problem. But given it's not being proposed to solve any concrete problem, it's hard to discuss whether there's a better solution. Are you deliberately ignoring the data I provided... at your request for data? Not at all. It's interesting, but it's only marginally related to ADSP. You're taking data based on a private relationship at a small number of consumer ISPs, for a very specific subset of mail and using that as data to directly support a protocol based on self-publication by a large number of different parties that would be acted upon by more than just a couple of consumer freemail providers. (If that weren't the case, there'd be no point in standardising a self-publication approach such as ADSP). Additionally, the data you've provided that I've seen isn't that useful as it only provides one of the four useful numbers in the legitimate vs phish, rejected by ADSP vs not rejected matrix. To give you a bit more idea of what I mean by that, I've pulled some data out of my mailbox, looking at emails that were both legitimate paypal mail, and which were clear phish emails targeting paypal. For each of those I worked out whether it would have been accepted or rejected based solely on ADSP dkim=discardable if they'd been signed when sent. I'll write up the methodology in a little more detail, but out of my sample the initial data is: Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% rejected. This is based on mail to my mailbox, but other than that it's a pretty fair sample, if anything it's fairly heavily skewed towards phish emails that would be rejected by ADSP (as it's based on emails with the string paypal in the From: line, which includes all phish mail that would be rejected, but excludes quite a lot of phish mail that wouldn't be). It's a small sample, but that means I've been able to identify and confirm manually the status of each email. (It does ignore the fact that Paypal acquires an awful lot of lookalike domains, partly because that's something it's hard to analyze after the fact but mostly because buy every domain in every TLD that has my company name in it is not a behaviour that scales at all.) It's also based on sender behaviour before there's significant actual filtering via ADSP. I would expect less mail, both legitimate and illegitimate, to be rejected by ADSP as time went on. That's real data, not theory, for the current state of the paypal related mailstream as I personally see it. I think I can extrapolate from there to what'll happen to that specific mail stream were ADSP to be widely adopted, but that'd be speculation. I look forward to learning more about your methodology. Your numbers don't match ours so there may be something we could learn from your analysis. The original argument was that it would help deal with phishing, but now even the strongest proponents are happy to explain that it will do absolutely nothing to help with phishing I'm sorry, I'm not only arguing that it absolutely DOES help with phishing, I've provided real data (vs. theory). Steve, I saw you give a presentation in February and I was very impressed by both your technical knowledge and your overall common sense. I consider you both intelligent and wise. But I cannot explain the position you've taken on the ADSP issue on this mail list. I think DKIM is a Good Thing that should be widely deployed. ADSP is broken in many respects, and because it's tied to DKIMs mindshare that brokenness deters DKIM adoption. So I believe that ADSP needs to be fixed or it needs to be allowed to die. I vote for fix. What other solutions on top of DKIM would you like to see the Internet adopt instead of ADSP... something open, interoperable, and royalty-free I hope! I can think of several, and I'd be more than happy to sit down and discuss them at some point over a beer, but I'm hearing enough grumbling from the chairs about what's on topic and what isn't already[1]. Cheers, Steve [1] Domain whitelists operated by FDIC, DB etc, for real businesses in a particular niche, or certificates based on vetting, a-la the green bar are two obvious ones, though. The green bar and extended verification certs is what PayPal is really relying on to avoid phishing right now, AFAICT. It's simple and effective and easy for consumers to understand. Yes, wee support EV Certs too... defense in depth. ___ NOTE WELL: This list
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 5/27/10 4:14 PM, Brett McDowell wrote: I think DKIM is a Good Thing that should be widely deployed. ADSP is broken in many respects, and because it's tied to DKIMs mindshare that brokenness deters DKIM adoption. So I believe that ADSP needs to be fixed or it needs to be allowed to die. I vote for fix. In agreement with both Steve and Brett. :^) -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
We have had ADSP deployed since the week before the February MAAWG meeting. I just asked our infrastructure guru to do a quick check and we are seeing about a million ADSP look-up's per day at this point. That's a good start. Now we need to figure out some way to find out who's doing those lookups, and what they're doing with them. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
Steve Atkins st...@wordtothewise.com wrote: On May 27, 2010, at 2:22 PM, Steve Atkins thinkoed: Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% rejected. That should be Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% not rejected. Why paypal in the from line and not from payal.com? It sounds like you are capturing messages unrelated to any ADSP assertions paypal.com might make. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
Brett McDowell brett.mcdow...@me.com wrote: ... As a newbie to this list, I have to say I agree. This has been a far less collegial debate than what I'm used to. That said, I may be guilty of reciprocating, and if anyone feels they have been on the receiving end of such, I apologize. ... I think your only offense is presenting a perspective based on operational experience that varies from the preconceived notions of a substantial fraction of the participants of this working group. There has been considerable resistance to doing any standardized policy work relative to DKIM. It's unfortunate that this resulted in policy having to be bolted on to DKIM after it was designed because we were prohibited from doing policy work as a part of DKIM development. As far as I can see, the only problem with ADSP and your discussion of it is that ADSP is guilty of doing exactly what it was designed to do with exactly the limitations we said it would have when we designed it. The same people that didn't like it then, don't like it now. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 27, 2010, at 7:38 PM, Scott Kitterman wrote: Steve Atkins st...@wordtothewise.com wrote: That should be Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% not rejected. Why paypal in the from line and not from payal.com? It sounds like you are capturing messages unrelated to any ADSP assertions paypal.com might make. No, I'm capturing (a subset of) phishes that were targeting paypal. That subset was those that were using the string paypal somewhere in the From: field, either in the local part or domain part of the email address or the friendly from. Some of those would have been rejected by ADSP, some wouldn't. See the message the one you quote was a reply to for the methodology. This is just a quick and dirty way to identify a subset of paypal related phishes, though, as I don't want to grovel through hundreds of thousands of messages looking for phishes by hand. A more thorough approach would have found a number of additional phishes that did not have the string paypal anywhere in the From: line, and so which would not have been rejected by ADSP. In other words, were I more thorough I would have found exactly the same number of phishes that were rejected by ADSP and I would have found more that were not rejected. (If you were to define phishes targeting paypal as phishing mail that would have been rejected by ADSP then that would lead to 100% of phishes rejected by ADSP and 0% that weren't. That would be nonsensical, though.) Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
Steve Atkins st...@wordtothewise.com wrote: On May 27, 2010, at 7:38 PM, Scott Kitterman wrote: Steve Atkins st...@wordtothewise.com wrote: That should be Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% not rejected. Why paypal in the from line and not from payal.com? It sounds like you are capturing messages unrelated to any ADSP assertions paypal.com might make. No, I'm capturing (a subset of) phishes that were targeting paypal. That subset was those that were using the string paypal somewhere in the From: field, either in the local part or domain part of the email address or the friendly from. Some of those would have been rejected by ADSP, some wouldn't. See the message the one you quote was a reply to for the methodology. This is just a quick and dirty way to identify a subset of paypal related phishes, though, as I don't want to grovel through hundreds of thousands of messages looking for phishes by hand. A more thorough approach would have found a number of additional phishes that did not have the string paypal anywhere in the From: line, and so which would not have been rejected by ADSP. In other words, were I more thorough I would have found exactly the same number of phishes that were rejected by ADSP and I would have found more that were not rejected. (If you were to define phishes targeting paypal as phishing mail that would have been rejected by ADSP then that would lead to 100% of phishes rejected by ADSP and 0% that weren't. That would be nonsensical, though.) Selecting messages that are by design outside the scope of what ADSP is intended to deal with to prove ADSP doesn't work is even more so. ADSP does only deal with exact domain forgery. Some people think that's worth doing and others don't. The fact that it is not the miracle solution to all phishing is neither surprising nor particularly interesting. The working group went through this exact discussion when ADSP was being developed. The rough consensus of the group was to go forward and unless there is some new information to cause us to reconsider the decision, hauling the same arguments out again is just wasting time better spent on other things. ADSP is not the policy component for DKIM that I would have designed, but it's the one we have and I'd rather see what can be done with it than rehash preconceived notions. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 27, 2010, at 7:39 PM, Scott Kitterman wrote: Brett McDowell brett.mcdow...@me.com wrote: ... As a newbie to this list, I have to say I agree. This has been a far less collegial debate than what I'm used to. That said, I may be guilty of reciprocating, and if anyone feels they have been on the receiving end of such, I apologize. ... I think your only offense is presenting a perspective based on operational experience that varies from the preconceived notions of a substantial fraction of the participants of this working group. There has been considerable resistance to doing any standardized policy work relative to DKIM. It's unfortunate that this resulted in policy having to be bolted on to DKIM after it was designed because we were prohibited from doing policy work as a part of DKIM development. As far as I can see, the only problem with ADSP and your discussion of it is that ADSP is guilty of doing exactly what it was designed to do with exactly the limitations we said it would have when we designed it. The same people that didn't like it then, don't like it now. That's because it was broken then, and it's still broken now. :) This explanation of why I think it's broken, and what might be done to fix it, is fairly terse, though, so please don't grab onto a single phrase and shake that phrase to death like a terrier with a rat. Really, it's worth reading all the way through. There are, I think, two problems that are intrinsic to the use of ADSP in the context of mitigating phishing email. One underlying problem is that ADSP is based on the inverse of an intentionally unreliable positive assertion (DKIM). That maps the non-problem of a mail with a broken DKIM signature being treated as unsigned to the serious problem (72% false positive rate) of mail with a broken signature being discarded. The only reason that DKIM is intentionally unreliable is that it's primary design constraint was that it would be something that could be added by a smarthost, without the sending MUA needing to be aware of it, and received by an MX and delivered to a receiving MUA without either needing to be aware of it. If ADSP were based on a reliable signing algorithm (such as S/MIME) then my objections to it based on the fragility of DKIM would go away (fundamentally, that it doesn't work reliably and causes legitimate email to be lost). Given it's primary value is when applied to B2C bulk mail, the constraints that apply to DKIM signing wouldn't apply and pretty much every MUA renders S/MIME. While I believe that would be a much smarter direction to go in, we've chosen not to. As ADSP is based on DKIM, and DKIM is always going to have a significant level of broken signatures, ADSP is always going to have a significant false positive rate - making it unusable for mail that it's important be delivered. All we can do is mitigate in an attempt to reduce that false positive rate. I'm sure we can come up with something that'll bring it down to single digit percentages of legitimate mail lost, or even to less than 1%, at least in some cases with very limited use of email (bulk mailer smarthost directly to major ISP MX, for instance). And there are situations where the mail that's being sent is sufficiently worthless or redundant that losing one mail in every few hundred might be acceptable. The other underlying problem, as applied to phishing email, is that ADSP will currently, if implemented perfectly by all senders and all receivers, reduce the volume of phishing mail delivered to the inbox by less than 50%, and that reduction is likely to decrease rapidly. Given the volume of phishing mail sent, and the volume of it that's already blocked much more reliably by existing filters, that means it is likely to have minimal effect on the number of phishing emails delivered to the recipients inbox. So the suggested use model is one where the security of the mail is so critical that it's worth going to this much effort in order to discard 50% of phish messages, yet it isn't critical enough that losing one in every few hundred legitimate messages isn't a problem. This doesn't seem like a use case most informed security or bulk email experts would consider interesting. If that's the low bar we're aiming for, then we're fine, but it would be dishonest not to document the limitations in a way that's clear to even a casual reader. OTOH, if that isn't acceptable then we need to change things. We cannot fix the second issue, ineffectiveness against phishing mail, both intrinsically and because the chairs have ruled that it's not a valid topic for discussion. So all we can do is improve the first issue - high levels of false positives leading to legitimate email being rejected. There are a few different places we could look at doing that, and some of the questions we need to ask are: 1. Do we want to reduce the DKIM broken signature rate or do
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 5/27/2010 2:22 PM, Steve Atkins wrote: I'll write up the methodology in a little more detail, but out of my sample eager to see the method description. not lots of detail, just the gist of what criteria created each of the 4 values. the initial data is: Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% rejected. This is pretty interesting data. It declares both FPs and FNs with ADSP, which certainly ain't part of any model I ever heard in support of its use. It's also based on sender behaviour before there's significant actual filtering via ADSP. I would expect less mail, both legitimate and illegitimate, to be rejected by ADSP as time went on. Given that a standard carries strategic costs in terms of development, implementation and deployment (real dollars and time) one would think that its level of benefit should not decay, or at least not quickly. Since it takes years to become useful it should take quite a few years before it becomes useless... 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] list vs contributor signatures, was Wrong Discussion
So I understand your line of reasoning. But today, I believe ADSP can provide a benefit. Brett has data that supports that. Once again, we have a pernicious confusion between manually maintained drop lists and ADSP. Brett has data that supports the former, not the latter. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On the other hand, John and Steve expect that the benefits PayPal is seeing in thwarted phishing messages will be short-lived, as phishers just change domain names, and send out just as many messages as before, fooling just as many recipients into thinking they're from PayPal. Actually, that's Steve. John sees utility in manual drop lists, but not in ADSP since there is no way to tell whether someone publishing ADSP understands what it means. Recent experience suggests that they often don't. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 27, 2010, at 9:15 PM, John Levine wrote: On the other hand, John and Steve expect that the benefits PayPal is seeing in thwarted phishing messages will be short-lived, as phishers just change domain names, and send out just as many messages as before, fooling just as many recipients into thinking they're from PayPal. Actually, that's Steve. John sees utility in manual drop lists, but not in ADSP since there is no way to tell whether someone publishing ADSP understands what it means. Recent experience suggests that they often don't. It's not really my view either. I do think that there's some risk of manual drop lists becoming less effective, but I also think that it's more a risk than a certainty, and it's something that may be resolved by a couple of smart engineers - as it's a flexible approach that can be modified in response to opponent behaviour in days or hours. That flexibility (and lack of publication of the details) and direct involvement of smart people in real time to maintain it are some of the things that make the manual drop list approach much more viable than a static, self-publication approach. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 27, 2010, at 9:03 PM, Dave CROCKER wrote: On 5/27/2010 2:22 PM, Steve Atkins wrote: I'll write up the methodology in a little more detail, but out of my sample eager to see the method description. not lots of detail, just the gist of what criteria created each of the 4 values. Sure. It was a very quick and rough analysis, based just on my mailboxes. I assumed that all signing, DNS publication, DKIM checking and ADSP checking was performed perfectly. I assumed that any modification of the body or subject of the mail after it was sent would invalidate a DKIM signature. I did make a few simplifications to speed the analysis, but the effect of those was solely to reduce the number of phishing emails not rejected by ADSP that were counted. My mailboxes are pre-categorised in a bunch of ways, such that it's easy for me to extract transactional mail, mail from discussion lists, mail from marketing lists and junk mail (including phishing). the initial data is: Legitimate email from paypal: 72% rejected by ADSP 28% not rejected For these two groups I extracted all mail that had an @paypal.com email address that was categorized as legitimate email. I inspected all of them by hand, and they were a mixture of transactional notifications from paypal in response to payments, direct 1:1 mail from paypal.com employees and mail from paypal.com employees via mailing lists. I didn't actually check signatures, just considered the 1:1 mail and transactional mail as not rejected and considered the mail sent through mailing lists that I know modify the content as rejected by ADSP. Phishing emails using paypal in the From line: 39% rejected by ADSP 61% not rejected. For this I extracted all the email categorised as junk mail that included the string paypal in some case or other in the RFC2822 From: field. That includes any use of paypal in the local part or domain part of the email, or in the friendly from. It excludes any phish emails that didn't include the term paypal in the From: field, or which used B or Q-encoding or which used homoglyphs or misspellings of paypal. (This will exclude some phishes that would pass ADSP, but will not exclude any that would be rejected by ADSP). I checked them quickly by eye - all appeared to be paypal phishes. Of those, I classified those where the from address was @paypal.com as rejected by ADSP and those where it wasn't as not rejected. Paypal is rather a special case, as they actively register many, many domains in a lot of TLDs that contain the word paypal or some misspelling of it, both proactively and in response to enforcement. I didn't consider those domains as triggering an ADSP rejection for a number of reasons. One is that many (most?) of them would have been acquired by paypal though enforcement action after the phishes were sent, and the other is that it's a behaviour (registering a huge number of domains purely to deny them to others) that's atypical and that doesn't scale. Havning said that, I did spot check quite a lot of the phishes that I'd tagged as not rejected and the vast majority weren't using domains I'd expect paypal to have proactively reserved (paypal.net, for instance) - they were mostly using the word paypal in the friendly from, the local part or a subdomain of the domain part. Of those that weren't of that form many were things like @paypal-access.com and suchlike. So I think those two numbers are likely accurate to within a few percent or better. This is pretty interesting data. It declares both FPs and FNs with ADSP, which certainly ain't part of any model I ever heard in support of its use. I expect that it would improve drastically in some respects with more widespread use of ADSP - I'd expect paypal employees to migrate to using a non-paypal.com domain for their email, for example. Also, my mailbox is more typical of someone in the industry than a consumer mailbox as, well, I get some mail from paypal.com that's neither transactional nor bulk. Someone who was a pure consumer at a major ISP who didn't use mailing lists or forwarding services and had no interaction with anyone at paypal other than via their bulk email system would see a much lower FP rate. It's also based on sender behaviour before there's significant actual filtering via ADSP. I would expect less mail, both legitimate and illegitimate, to be rejected by ADSP as time went on. Given that a standard carries strategic costs in terms of development, implementation and deployment (real dollars and time) one would think that its level of benefit should not decay, or at least not quickly. Since it takes years to become useful it should take quite a few years before it becomes useless... +1 Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 05/27/2010 09:14 PM, John Levine wrote: So I understand your line of reasoning. But today, I believe ADSP can provide a benefit. Brett has data that supports that. Once again, we have a pernicious confusion between manually maintained drop lists and ADSP. Brett has data that supports the former, not the latter. It takes a special amount of arrogance to tell people with operational experience what they they've actually experienced. Congratulations. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
