Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
On Jun 3, 2010, at 12:20 PM, Amir Herzberg wrote: > On Wed, Jun 2, 2010 at 8:57 PM, Brett McDowell wrote: > ... > A = sender of message from an ADSP=discardable domain but the message was not > DKIM signed > B = sender of message from an ADSP=discardable domain and the message was > DKIM signed > C = the MLM who is a participating MLM in the authenticated email ecosystem > D = receiver of email from the MLM who is a participating receiver (DKIM/ADSP > inbound) > Note: this scenario takes place after this IETF DKIM WG standardizes the new > header I mentioned above. > > In this scenario C will report to D that the message from A was not signed on > inbound and that the message from B was. > > Shouldn't C discard such message instead of sending it to D? Good question. I don't have a strong opinion either way (yet). The fact that MLM's deliver those messages today enables what we've seen on this list, i.e. at least the message is in subscribers' spam folders which enables them to configure their MUA's to deliver such things in the future. But I've seen several posts to this list suggesting life is better if such messages simply never reach the subscribers' inbox. To be honest, I don't recall the motivation for that position. IIRC, the original motivation was to avoid auto-unsubscriptions from the MLM, but I think we've concluded that MTA's shouldn't bounce those rejected messages back to the MLM anyway. ___ 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 May 27, 2010, at 12:29 PM, Roland Turner wrote: > 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 Why not simply clarify this in the currently underway DKIM-BCP? Then we don't have to have the caveat in our three guiding principles. Our principles will assume all stakeholders (participating in authentication or not) are reading and following our BCP guidance. Is that a fair position for us to take? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] My discardable statistics
Thank you John for taking the time to put that together. On Jun 2, 2010, at 9:44 PM, John Levine wrote: > I've been saving the DKIM signatures on mail sent to my inbox for > about the past year, so I did a little analysis on them. There's a > total of 71,000 signed messages that got to the procmail delivery > filter, signed by a total of 474 domains. I went through and looked > up the ADSP records for all of them. I found 51 ADSP records: > > 24 dkim=all > 19 dkim=unknown > 8 dkim=discardable > > A few had t=s but none of the discardables did. > > Let's take a look at those eight records. The number on each line is > the number of messages: > > 135 paypal.com dkim=discardable > 23 paypal.co.uk dkim=discardable > 7 intl.paypal.com dkim=discardable > 6 mail.julianhaight.com dkim=discardable > 4 undp.org dkim=discardable > 4 info.paypal.com dkim=discardable > 2 info.paypal.ca dkim=discardable > 1 info.paypal.co.uk dkim=discardable > > Six of them are Paypal, who presumably know what they're doing. > > Of the other two, mail.julianhaight.com is Julian's personal domain. > All of the mail from that domain came through a mailing list, which > tells us that he didn't follow the advice in RFC 5617. > > It appears that undp.org really is a branch of the United Nations, and > their mail management isn't very good. All four of those messages > came from the UNDP's mail servers, all four of them had return > addresses that appear to be individual users at undp.org, and all four > of them are spam or phish, presumably from botted PCs. Two of the > DKIM signatures verify, two don't, haven't looked hard enough to tell > why not, but they were broken when they arrived at my MTA. (Look at > the spamassassin lines, added at SMTP time.) > > They're all in my spam archive, so you can look at them yourself: > > http://spample.iecc.com/yjf/21798071 > http://spample.iecc.com/yvh/22631217 > http://spample.iecc.com/oga/22622255 > http://spample.iecc.com/gdx/22039445 > > Looking at the headers, this mail appears to have taken the same path > that real user mail would have taken, so discardable is wrong here, > too. Note that even though the mail is spam, the From: line addresses > are in the domain of the sending system, so for ADSP purposes, they're > OK, or would be if the signatures were good. > > I admit that this isn't a very big sample, but it does say that of > all the people who sent me mail in the past year, Paypal is the > only one who used ADSP discardable in a way that would would be > useful for inbound mail handling. > > R's, > John > ___ > 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
On Jun 2, 2010, at 4:36 PM, MH Michael Hammer (5304) wrote: > So, is this a discussion about a BCP for MLMs or is this a discussion > about revisiting the ADSP spec? The course of the discussion really > depends on what the consensus is. Let's break these up. Murray tried and I think succeeded to some degree of getting a clear thread that is dedicated only to the MLM BCP. What makes that a refreshingly productive thread is that we have an I-D to review and comment on. Perhaps we are at (or long past) the point of diminishing returns in debating the efficacy of ADSP until we have an I-D that covers fixing/enhancing ADSP to make it more useful. -- Brett ___ 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 Jun 2, 2010, at 4:05 PM, Dave CROCKER wrote: > If proponents want simply to keep automatically saying that things are great > and > keep automatically rejecting any counter-points, then I'm not clear what the > purpose of these discussions is. If opponents want simply to keep automatically saying that things are terrible and keep automatically rejecting any counter-points, then I'm not clear what the purpose of these discussions is. ___ 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 Jun 2, 2010, at 3:26 PM, John R. Levine wrote: >>> Recent experience suggests that they often don't. >> Can you name someone with ADSP experience who doesn't understand what it >> means? > > Not to pick on you specifically, since there are multiple examples, but I'd > say that domains that publish dkim=discardable and who let their users > subscribe and send messages to mailing lists don't understand what their ADSP > is telling people. > > I suppose it's possible they do know and they don't care how much damage they > cause to everyone else, but I'd rather think it was confusion than malice. > You'd call it malice to prioritize consumer protection over the a very small population of employees being temporarily inconvenienced by having some of their messages to mail lists delivered to SPAM and in some corner cases, actually unsubscribed from lists... while we invest time and resources to (a) assess how MTA's, MUA's and MLM's actually deal with these mail streams and (b) work with the standards community to improve the ecosystem by shaving off the rough edges we find? Neither ignorance or malice, simply the will to be an early adopter of young standards with proven consumer protection capabilities coming from a respected source. Yes, we are learning by doing and we are contributing all of that back to the community. What surprises me is how our efforts have been received by the community who produced these standards in the first place. ___ 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 28, 2010, at 12:14 AM, 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. I disagree, but here's some new data that might better illustrate the case for ADSP. In terms of public information, we are in production with DKIM verification/blocking today with two mailbox providers. We'd like to be in production with say... two hundred by some near-term date certain. Hence the need for ADSP. The case is even stronger from the mailbox providers' perspective since they would be working with orders of magnitude more senders. ___ 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 28, 2010, at 12:15 AM, 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. ADSP seems to mean one thing to pundits and something else to the people actually using it. Who is right? > Recent experience suggests that they > often don't. Can you name someone with ADSP experience who doesn't understand what it means? ___ 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 Jun 2, 2010, at 2:41 PM, Steve Atkins wrote: > > On Jun 2, 2010, at 10:59 AM, Brett McDowell wrote: > >> On May 28, 2010, at 1:08 AM, Steve Atkins wrote: >> >>> 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. >> >> Your numbers were so far off from what we see that I was perplexed, but now >> it's clear why. >> >> In reality we do register many of the domains you assumed we don't (like >> paypal.net) and we are not unique in that practice. We have over a thousand >> of these domains parked. >> >> The result of this simple error in assumption has skewed your data to the >> point where it is no longer representative. > > There's no error in assumption. The data is fairly accurate as measured (and > also reasonably representative of the behaviour of a mixed-use domain, I > think). > > First, as I said above > >>> they were mostly using the word >>> "paypal" in the friendly from, the local part or a subdomain of >>> the domain part > > ... in other words your argument doesn't apply at all to most of the phishing > email that ADSP failed to deal with. I don't think you are following me... the receivers who are performing ADSP look-ups and enforcing "discardable" would have blocked a ton of that email you are reporting would have made it through. > > Second... > >steve$ host -t txt _adsp._domainkey.paypal.net >_adsp._domainkey.paypal.net has no TXT record >steve$ host -t txt paypal.net >paypal.net has no TXT record > > ... I wasn't going to mention it, but you brought it up. The MX for > paypal.net will also give a 2xx response to any RCPT TO in the paypal.net > domain. ...and I wasn't going to mention that I tried to work with you off-list to get more information about your phish from paypal.net but you didn't respond. If you get a chance, please do send that along. > > Third, as I mentioned above, even if you were publishing ADSP records for > lookalike domains, most of those lookalike domains appear to have been > acquired after enforcement of a phishing issue - meaning that there would > have been no ADSP records when the phishing mails were sent, and your > ownership of them now is irrelevant. As I've reported before, we have over 100 millions reasons (blocked attacks from our registered domains) why you are wrong about this assertion. > > Fourth, as I mentioned above, even if all you said was valid, registering > thousands of domains in order to make ADSP sort-of work against phishing > isn't something that scales, either in terms of domain name system nor the > expense. If ADSP requires users to spend tend of thousands of dollars a year > to maintain domain registrations in order for it to have a significant effect > on phishing then it's not something that's really going to scale to more than > a handful of senders. You have this backwards. Major brands register cousin domains for more reasons than phishing. This practice pre-dated ADSP and it will continue with or without ADSP. It's simply an operational fact that is relevant to any debate about how ADSP can/should be used. > >> I feel compelled to point out this error since several people on the list >> have been quoting your data since you circulated it and are likely to draw >> erroneous conclusions from it. > > > I understand you
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 28, 2010, at 12:28 AM, Steve Atkins wrote: > > 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. My problem with this position is that it seems to argue for proprietary one-off solutions vs. Internet standards for email authentication policy assertions. I would think that's a non-starter, especially for participants in this WG. ___ 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 Jun 2, 2010, at 3:06 PM, Michael Thomas wrote: > On 06/02/2010 11:41 AM, Steve Atkins wrote: >> Fourth, as I mentioned above, even if all you said was valid, registering >> thousands of domains in order to make ADSP sort-of work against phishing >> isn't something that scales, either in terms of domain name system nor the >> expense. If ADSP requires users to spend tend of thousands of dollars a year >> to maintain domain registrations in order for it to have a significant >> effect on phishing then it's not something that's really going to scale to >> more than a handful of senders. > > I'd be willing to bet a good chunk of money that Paypay -- and lots of other > domains -- > have this practice regardless, and preceding ADSP. ADSP use supplements that > current > best practice for phishing target domains. Which is sort of the point. > +1 ___ 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 Jun 2, 2010, at 9:33 AM, MH Michael Hammer (5304) wrote: > > >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of John Levine >> Sent: Wednesday, June 02, 2010 9:21 AM >> To: ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong >> Discussion >> > > > >> >> Here's a thought experiment: let's say you have your list of domains >> that are known to be phish targets that sign their mail, so you drop >> unsigned mail, and they all happen to publish ADSP. Someone's ADSP >> record goes away. Is it more likely that they've stopped signing >> their mail, or that their ADSP record is temporarily messed up? Why? >> > Signing their mail does not equal ADSP. "Knowing" they sign their mail > does not equal ADSP. As you have pointed out, ADSP does not equal manual > drop lists. > > The fact that someone's ADSP record - absent any other data points - > goes away, tells us nothing other than their ADSP record went away. > There could be any number of reasons as to why it went away. > > Are we now going to have to write a draft for casting goat bones to > determine the meaning of standards implementations and operational > practices? > > It's really quite simple. Agreed. BTW, I'm actually agreeing to this statement in the context it was made :-) > If there is no longer an ADSP record then ADSP > is not applicable. Well, you'd process that mail as if... there were no ADSP policy because... there's no ADSP policy. Do we really need to publish informational guidance on this point? If yes, then let's do it. ___ 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 28, 2010, at 1:08 AM, Steve Atkins wrote: > 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. Your numbers were so far off from what we see that I was perplexed, but now it's clear why. In reality we do register many of the domains you assumed we don't (like paypal.net) and we are not unique in that practice. We have over a thousand of these domains parked. The result of this simple error in assumption has skewed your data to the point where it is no longer representative. I feel compelled to point out this error since several people on the list have been quoting your data since you circulated it and are likely to draw erroneous conclusions from it. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
On May 26, 2010, at 12:59 PM, Steve Atkins wrote: > On May 26, 2010, at 7:45 AM, Brett McDowell wrote: > >> On May 25, 2010, at 8:43 PM, Scott Kitterman wrote: >> >>>> Like I said, "throw away anything that doesn't have our signature" has >>>> some chance of broad adoption. Every extra word you add to the message >>>> makes it less likely that people will do it. >>>> >>> I agree with this. I have yet to see any proposals for additions that >>> didn't either add enough complexity to act as a barrier to deployment or >>> alternately make it trivially possible to allow third parties to create >>> messages that render discardable moot. >> >> I agree that adding anything to "throw away anything that doesn't have our >> signature" add complexity to implementation and therefore, by definition, is >> a barrier to adoption. That's not what we are debating. What we are >> debating is whether such complexity is a necessary evil that we should >> provide a specification to support -- as an optional mechanism for >> stakeholders who want to opt-in to the authenticated email ecosystem. I >> *think* the answer is "yes". But we haven't yet had the meaningful debate >> that will resolve that question. >> >> Let's debate whether transient trust through a MLM is actionable. Would a >> new header that enabled the MLM to report to the receiver that they indeed >> validated the original signature actually make any difference in the >> deliverability of that message to the receiver, and if yes, is that actually >> a good thing? I say "yes" and "yes". But I expect that if we debate this >> specific point one of you might highlight an unintended consequence that >> would tip the balance away from pursuing such a model. >> >> Thoughts? > > Aesthetically I like the idea of some way for the MLM to tunnel > authentication information through to the recipient. Perhaps that's common ground we just discovered. Let's build on that. > > But I don't think it's clear that doing so would change anything at the > recipients MX. As a concrete example, if two subscribers to a mailing list > send mail to the list, one DKIM signed and one not, and the list then signs > each message and sends it to the recipient, is there any reason that the > recipients MX would treat those two messages differently? > Yes. But we need more information about the scenario in order to describe how. The following detail will illustrate how. A = sender of message from an ADSP=discardable domain but the message was not DKIM signed B = sender of message from an ADSP=discardable domain and the message was DKIM signed C = the MLM who is a participating MLM in the authenticated email ecosystem D = receiver of email from the MLM who is a participating receiver (DKIM/ADSP inbound) Note: this scenario takes place in after this IETF DKIM WG standardizes the new header I mentioned above. In this scenario C will report to D that the message from A was not signed on inbound and that the message from B was. This would lead D to deliver the message from B but not deliver the message from A. The MLM signed both messages before sending to D. -- Brett ___ 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 28, 2010, at 12:01 AM, Steve Atkins wrote: > > 1. Do we want to reduce the DKIM broken signature rate or do we want to make > ADSP less vulnerable to it. Or both, I guess. I think both of those objectives are of interest. > > 2. If we want to reduce the DKIM broken signature rate, do we need to rework > DKIM at all I don't think so. > , or do we need to make operational recommendations to the generator and > signer of the mail yes > , or do we need to provide operational advice to forwarders and mailing list > managers yes > . For any of those we need to balance the improvement against the reduction > in deployment and reduction in correct deployment the increased complexity > will cause. The history of SPF-all and SRS is likely relevant there. > Why is guidance for how to use something that already exist make things more complex? It should dramatically reduce complexity through clear recommendations. Re-writing DKIM would be a problem, and I for one am not in favor of that as I agree with Steve that it will have a negative impact on deployments, but surely implementation guidance would only have a positive impact on deployments. > 3. If we want to make ADSP less vulnerable to it, this basically means > reworking ADSP such that it says that receivers should accept unsigned mail > in some cases - the various suggestions about accepting unsigned mail from > "trusted" mailing lists or forwarders. This is bound to open up a bunch of > theoretical security issues, and probably some real ones. I do not believe that is our only option. We can extend ADSP to provide a few new options over "all" and "discardable" that meet current use cases. Otherwise we could publish guidance to address expected use but I assume that guidance will leave it to the deployer to decide who and why they "trust" certain streams and/or policy assertions. > > 3a. If we go in that direction we're looking at making some fairly tricky > security related decisions. We'd need a proper analysis of the security risks > and operational benefits, which would require us to be more honest than we > have been in the past about what the end goals are, and how some of the more > obvious attack trees would affect those goals. > Maybe you are contemplating a different part of the elephant but I don't see what you are getting at with this line of rhetoric. > Any of those changes - i.e. doing anything other than accepting the seriously > broken behaviour and just documenting it - would require buy-in from the > chairs and other participants, and likely a charter clarification. I would not be surprised if we need a charter clarification to tackle adding options to ADSP, but aren't we already chartered to provide BCP guidance for the technologies that have come out of this WG? ___ 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! > >
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
On May 27, 2010, at 2:05 AM, 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. 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. -- Brett ___ 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 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 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 someth
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 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 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 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 26, 2010, at 1:42 PM, Steve Atkins wrote: I'm big on concrete examples. So how does your logical conclusion deal with these two situations? $ host -t txt _adsp._domainkey.paypaI.me _adsp._domainkey.paypaI.me descriptive text "dkim=discardable" $ host -t txt _adsp._domainkey.paypal.com _adsp._domainkey.paypal.com descriptive text "dkim=discardable" >> I would like to answer your question... but I can't grok it from these two ADSP look-ups. Are you asking about what we do if someone other than ourselves registers a cousin domain? ___ 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 3:02 PM, Steve Atkins wrote:
>
> On May 26, 2010, at 11:48 AM, Michael Thomas wrote:
>
>> On 05/26/2010 11:30 AM, Steve Atkins wrote:
> Michael claims off-list that he has no idea what I'm speaking of.
I said "huh?" too.
>>>
>>> Perhaps I'm missing something. I'm working with the mental model
>>> that the underlying problem ADSP advocates would like to address
>>> is phishing or brand protection, as they're the only concrete problems
>>> I've seen mentioned.
>>
>> So you're on a tangent about something that's not even vaguely in our
>> charter.
>
> I don't believe I am.
>
>> ADSP doesn't claim to solve "phishing", it just allows bit-for-bit
>> domain names to be safely tossed if they don't have a signature. How that
>> integrates into the larger anti-phishing modules is frankly where the secret
>> sauce lies for vendors.
>
> We can't usefully discuss things like best practices or a revision of
> the spec without some sort of concrete operational use case.
>
> The only operational experience I've seen discussed so far is entirely
> negative - it causes mail from mailing lists to be lost and leads to
> recipients being unsubscribed from those lists.
>
> We really need to come up with some positive operational experience,
> or at least a theoretical situation where some may occur, before we
> can talk about either best practices for using it or modifying the spec in
> order to avoid the observed problems.
>
> 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)?
What do I need to show you guys before you accept that I have demonstrated that
ADSP provides operational benefit?
>
> So we're left with a protocol that doesn't appear to be terribly
> useful for any particular use case, and which is demonstrably
> broken when used with mailing lists.
>
> This thread started with the observation that ADSP was broken
> w.r.t. mailing lists, and discussion of how the spec might be
> changed such that it wasn't broken in that respect, yet would
> still be effective for it's main purpose. We also have tangents
> on how it should be deployed in practice ("What does 'discardable'
> mean? Does it mean you should reject mail instead of discarding
> it?")
>
> And that leads to... what is the intended main purpose? Without
> that, there's no way to decide whether the suggested changes
> will improve things, or simply cause it to be more broken (via
> increased complexity leading to reduced usage or incorrect
> usage, for example), nor to provide appropriate advice on
> deployment (other than "Don't, yet.").
>
> 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] more on discardable, was Lists "BCP" draft
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 If we agree to that then I believe it opens up some opportunities and clarifies why we would have rough consensus on some of the major issues that have been under debate for a few weeks now. For example: In the past I have argued that the receivers should simply not bounce DKIM+ADSP=discardable messages back to the MLM. But that position assumes the receiver is participating in the authN email ecosystem. The principles listed above would lead me to change that position. Thoughts? On May 26, 2010, at 10:48 AM, Steve Atkins wrote: > > On May 26, 2010, at 7:00 AM, Jeff Macdonald wrote: > >> >> >> On Mon, May 24, 2010 at 9:55 PM, Steve Atkins >> wrote: >> >> On May 24, 2010, at 6:38 PM, John Levine wrote: >> >>> Since ADSP causes problems for innocent bystanders, I think it's >>> reasonable to decline A's mail in the first place. This is doubly >>> true since the ADSP RFC rather specifically says that you shouldn't >>> mark a domain discardable if its users send mail to lists. >> >> It causes no problems at all to innocent bystanders in that case - the >> recipient at domain B is a willing participant who has chosen both >> to pay attention to ADSP and to respond to it by rejecting, rather than >> discarding, mails labeled "discardable". >> >> Perhaps I missed something, but if domain B is rejecting email from the list >> Authored by A, then won't that cause a list member at domain B to be removed >> from the list as well? I think that is what John meant by innocent >> bystander. Most MLM remove subscribers after repeated bounces. I don't know >> if they are smart enough to look into why the message bounced. > > That's exactly the issue, and not a theoretical one. > > 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. > > The mailing list operator is the one caught in the middle between two domains > that have made bad decisions, so is an innocent bystander, but the level of > inconvenience to them is pretty small, relative to the usual overhead of > running a mailing list. > > 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
I respectfully disagree with you. We *were* a special case. Soon we will not be a special case because ADSP will enable all mailbox providers, if they choose, to do for others what they have historically done for us. That's the big win that only ADSP could ever enable. Apparently such an announcement is going to come as a surprise to many of you on this list, but it shouldn't. It's the logical conclusion of the ADSP work. -- Brett On May 26, 2010, at 11:55 AM, John Levine wrote: >> Problem = phishing >> Utility = just one sender + two mailbox providers have blocked over >> 100 million phishing attacks, many of those blocks also resulted in >> site take-downs. > >> The value of what we already have from your efforts in IETF is HUGE > for consumer protection. > > I believe this is a big win for DKIM, which I hope we can tell the world > about. > > It has NOTHING WHATSOEVER to do with ADSP, since the two mailbox > providers are (quite reasonably) treating paypal and ebay as a special > case. > >> It could be even more useful with the kind of tweaks I've suggested >> for MLM's... and probably a few more flags/states for ADSP. > > We've gone around enough times why this would be bad for Paypal and > bad for everyone else, so I'll stop now. > > R's, > John > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
On May 25, 2010, at 8:43 PM, Scott Kitterman wrote: >> Like I said, "throw away anything that doesn't have our signature" has >> some chance of broad adoption. Every extra word you add to the message >> makes it less likely that people will do it. >> > I agree with this. I have yet to see any proposals for additions that didn't > either add enough complexity to act as a barrier to deployment or alternately > make it trivially possible to allow third parties to create messages that > render discardable moot. I agree that adding anything to "throw away anything that doesn't have our signature" add complexity to implementation and therefore, by definition, is a barrier to adoption. That's not what we are debating. What we are debating is whether such complexity is a necessary evil that we should provide a specification to support -- as an optional mechanism for stakeholders who want to opt-in to the authenticated email ecosystem. I *think* the answer is "yes". But we haven't yet had the meaningful debate that will resolve that question. Let's debate whether transient trust through a MLM is actionable. Would a new header that enabled the MLM to report to the receiver that they indeed validated the original signature actually make any difference in the deliverability of that message to the receiver, and if yes, is that actually a good thing? I say "yes" and "yes". But I expect that if we debate this specific point one of you might highlight an unintended consequence that would tip the balance away from pursuing such a model. Thoughts? -- Brett ___ 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 25, 2010, at 7:03 PM, Steve Atkins wrote: > > On May 25, 2010, at 3:38 PM, Brett McDowell wrote: > >> On May 10, 2010, at 3:09 PM, Steve Atkins wrote: >> >>> On May 10, 2010, at 11:59 AM, John R. Levine wrote: >>> >>>>> Apart from ADSP rules, a broken signature must be treated as if there was >>>>> no >>>>> signature at all. That in itself is not the problem. The problem with >>>>> broken >>>>> signatures is that people will not buy into a technology (DKIM) if it >>>>> will >>>>> not cover a significant part of their e-mail. >>>> >>>> Of course. That's why MLMs should sign their mail, or equvalently the MSA >>>> they use should sign it. Problem solved, right? >>>> >>>> Free bonus: MLMs can sign the list mail even if the contributor didn't >>>> sign it. >>> >>> +1. It's pretty much a non-issue (unless you believe that DKIM is >>> magic fairy dust that will prevent all "fraudulent use of your brand"). >> >> I believe we can disagree without being disagreeable. I'm sure there is no >> one on this list (or in the world) who thinks DKIM is magic fairy dust that >> will prevent all fraudulent use of a brand. > > If ADSP is not there to prevent "fraudulent use of your brand", what > is it for? To protect users from a type of crime (phishing) perpetrated in a particular channel (email). It's not about protecting our brand. It's about protecting our customers. > > While I don't think ADSP proponents actually believe it is magical brand > protection fairy dust, that is the operational model we're using when we're > discussing the usage of ADSP. > > ADSP does not, and can not, provide significant operational value > in dealing with phishing, Ummm... PayPal+Google+Yahoo have collectively blocked well over 100 million phishing attacks using DKIM+ADSP=discardable (if you include the out-of-band equivalent to ADSP=discardable that we had to put in place while we waited for a standard, that we now fully support and deploy). > which is the only concrete example > anyone has brought forward. So we're left with "brand protection", > which is still plausible because it's so vague. > > (If it were described as "Brand protection as applied to the section of > the byte sequence in the From: field that isn't the part usually displayed > to the end user" that would be less vague, but more obviously useless). > > > >> I would like to think we are all on this list making a good faith effort to >> explore and debate the right way to deal with the status quo, including the >> option of sustaining it. I personally don't agree with the position that >> the status quo should be sustained, but I respect both that position and >> those who articulate it. > > > Yes, this summary may be blunt and possibly even disagreeable, but > there comes a point when developing something that's going to affect > many, many people that you have to mention the elephant in the room - > which is that while lots of people involved have invested quite a bit of > effort > and professional credibility in putting it together there's still no > definition > of what problem it's supposed to solve, and the end result appears to > be pretty much useless for any concrete phishing or brand protection > scenario. Problem = phishing Utility = just one sender + two mailbox providers have blocked over 100 million phishing attacks, many of those blocks also resulted in site take-downs. The value of what we already have from your efforts in IETF is HUGE for consumer protection. It could be even more useful with the kind of tweaks I've suggested for MLM's... and probably a few more flags/states for ADSP. -- Brett > ___ 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
+1 My favorite line from Mike's email is "there is value that can be leveraged in conjunction with other tools as part of an overall anti-abuse program. " An example of how this fits into an overall strategy is captured in a white paper PayPal published in 2008: https://www.thepaypalblog.com/2008/04/a-practical-app/ (the link to the paper is in the last paragraph of that blog post) -- Brett On May 26, 2010, at 9:22 AM, MH Michael Hammer (5304) wrote: > > >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of Steve Atkins >> Sent: Tuesday, May 25, 2010 7:03 PM >> To: DKIM List >> Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong >> Discussion >> >> >> On May 25, 2010, at 3:38 PM, Brett McDowell wrote: >> >>> On May 10, 2010, at 3:09 PM, Steve Atkins wrote: >>> >>>> On May 10, 2010, at 11:59 AM, John R. Levine wrote: >>>> >>>>>> Apart from ADSP rules, a broken signature must be treated as if > there >> was no >>>>>> signature at all. That in itself is not the problem. The problem > with >> broken >>>>>> signatures is that people will not buy into a technology (DKIM) > if it >> will >>>>>> not cover a significant part of their e-mail. >>>>> >>>>> Of course. That's why MLMs should sign their mail, or equvalently > the >> MSA >>>>> they use should sign it. Problem solved, right? >>>>> >>>>> Free bonus: MLMs can sign the list mail even if the contributor > didn't >>>>> sign it. >>>> >>>> +1. It's pretty much a non-issue (unless you believe that DKIM is >>>> magic fairy dust that will prevent all "fraudulent use of your > brand"). >>> >>> I believe we can disagree without being disagreeable. I'm sure > there is >> no one on this list (or in the world) who thinks DKIM is magic fairy > dust >> that will prevent all fraudulent use of a brand. >> >> If ADSP is not there to prevent "fraudulent use of your brand", what >> is it for? >> > > A most pithy question deserving of an answer. ADSP does not "prevent > fraudulent use of your brand". Never has and never will. What it is > intended to prevent is "fraudulent use of your domain" that may or may > not be a brand. It is a specific tool targeted at a narrow problem. > Nothing more and nothing less. It does not prevent abuse of the display > name nor does it prevent the use of cousin domains as just two examples > of the many things it does not do. It is a point solution to a point > problem. > >> While I don't think ADSP proponents actually believe it is magical > brand >> protection fairy dust, that is the operational model we're using when >> we're >> discussing the usage of ADSP. >> > > Have to disagree with you here Steve. It's not magical and as I pointed > out above, it is not strictly speaking "brand protection". > >> ADSP does not, and can not, provide significant operational value >> in dealing with phishing, which is the only concrete example >> anyone has brought forward. So we're left with "brand protection", >> which is still plausible because it's so vague. >> > > The only reason that ADSP does not provide significant operational > benefits is that for the sake of compromise it was crippled at birth. > Speaking based on the experience of DKIM signing all mail for some > heavily abused domains since 2007, there is value that can be leveraged > in conjunction with other tools as part of an overall anti-abuse > program. > >> (If it were described as "Brand protection as applied to the section > of >> the byte sequence in the From: field that isn't the part usually > displayed >> to the end user" that would be less vague, but more obviously > useless). >> > > There is a very simple solution I have suggested in the past that can > and will likely be implemented once email authentication reaches a > critical mass. That is for MUAs to set the default implementation to NOT > display the display name if the mail is unauthenticated. > > I would hope that the long term goal is to reduce the attack surface > available to abusers. >> >> >>> I would like to think we are all on this list making a good faith > effort >> to explore and debate the right way to deal with the status quo,
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 10, 2010, at 3:09 PM, Steve Atkins wrote: > On May 10, 2010, at 11:59 AM, John R. Levine wrote: > >>> Apart from ADSP rules, a broken signature must be treated as if there was >>> no >>> signature at all. That in itself is not the problem. The problem with >>> broken >>> signatures is that people will not buy into a technology (DKIM) if it will >>> not cover a significant part of their e-mail. >> >> Of course. That's why MLMs should sign their mail, or equvalently the MSA >> they use should sign it. Problem solved, right? >> >> Free bonus: MLMs can sign the list mail even if the contributor didn't >> sign it. > > +1. It's pretty much a non-issue (unless you believe that DKIM is > magic fairy dust that will prevent all "fraudulent use of your brand"). I believe we can disagree without being disagreeable. I'm sure there is no one on this list (or in the world) who thinks DKIM is magic fairy dust that will prevent all fraudulent use of a brand. I would like to think we are all on this list making a good faith effort to explore and debate the right way to deal with the status quo, including the option of sustaining it. I personally don't agree with the position that the status quo should be sustained, but I respect both that position and those who articulate it. FWIW, -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
On May 25, 2010, at 1:46 PM, John R. Levine wrote: >> Step three: fix the status quo for *participating* MLM's by offering up a >> new technical solution that enables MLM's to assert that they've validated >> the original sender's signature. > > Not to pick on Paypal specifically, since this is a general failure of ADSP, > but: Colorful, but those were not my/our words or sentiment. Once again, our use case is: > On Apr 26, 2010, at 1:19 PM, McDowell, Brett wrote: >> >> From my perspective, I'd like to enable (not mandate or expect universal >> compliance with) the deployment scenario where the sender's DKIM signature >> is either maintained without adulteration or "proxied" by the list so the >> transient trust can be carried through the mailing list intermediary to the >> destination (per Murray's note which I'm also going to respond to). That's >> my use case. By sharing this use case I'm not trying to deprecate or >> undermine John Levine's original use case. But there is a diversity of >> valid/appropriate behavior by mailing lists vis-a-vis DKIM that we need to >> consider (which is why I'm so pleased to see Mike H. take our discussion in >> this direction). >> >> -- Brett There are mailbox providers who want to leverage email authentication technologies to protect their users from phishing. I'm not making that up. What we have done with Google and Yahoo! is well known, but who here actually believes those are the only two deployments in the world today (or in-process)? I don't think it's in the best interest of the Internet to leave these use cases with no alternative but to pursue closed, proprietary mechanisms. It is my opinion that the standards community (if not IETF, then who?) could view these use cases as an opportunity to evolve the standards in a way that will gain more adoption and utility. The only thing we would be doing is evolving the existing standards to enable -- not compel or coerce -- consumer protection use cases. Everything I've articulated since joining the mail list has been rooted in the concept of choice. This authenticated messaging ecosystem is optional, not mandatory. Any effort to make it mandatory is doomed. So why not provide the option? Why not spec out a means for MLM's to participate in a DKIM/ADSP=discardable flow in a way that supports consumer protection use cases? -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 24, 2010, at 9:08 AM, John R. Levine wrote: >> I guess the list should be rejecting his email! Then, perhaps, his >> organisation would get around to deploying a non-discardable domain. > > I've suggested it. They know they have a problem, but they won't yet say > what they're going to do about it. > I'll be happy to report on our decision once we've implemented it. FWIW, I agree with the recommendations made on this list, at least in the short-term. Step one: was to start using anything that wasn't under an ADSP=discardable assertion (so here I am using a me.com account). Step two: is to do something along the lines of what's been recommended here (a non-discardable domain). Step three: fix the status quo for *participating* MLM's by offering up a new technical solution that enables MLM's to assert that they've validated the original sender's signature. > As you may recall, they suggested that lists sign an A-R header and all > recipient systems track what lists they're subscribed to and do > complicated processing to see whether list mail was signed when it showed > up at the list. That is a mischaracterization of what I proposed. What I actually proposed was: > On Apr 26, 2010, at 1:19 PM, McDowell, Brett wrote: > >> On Apr 26, 2010, at 10:05 AM, MH Michael Hammer (5304) wrote: >> >>> I think we are having the wrong discussion. The real question is: >>> >>> "What are appropriate practices for mailing lists in handling DKIM >>> signed mail?" >> >> Agreed. >> >> From my perspective, I'd like to enable (not mandate or expect universal >> compliance with) the deployment scenario where the sender's DKIM signature >> is either maintained without adulteration or "proxied" by the list so the >> transient trust can be carried through the mailing list intermediary to the >> destination (per Murray's note which I'm also going to respond to). That's >> my use case. By sharing this use case I'm not trying to deprecate or >> undermine John Levine's original use case. But there is a diversity of >> valid/appropriate behavior by mailing lists vis-a-vis DKIM that we need to >> consider (which is why I'm so pleased to see Mike H. take our discussion in >> this direction). >> >> -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 24, 2010, at 5:27 AM, Ian Eiloart wrote: >> We have one concrete failure scenario, in which someone who publishes >> dkim=discardable sends mail to a MLM that as usual breaks the signature, >> a subscriber's mail system carefully follows the ADSP and rejects that >> mail, causing the subscriber to be bounced off the list. (This really >> happened, on an IETF list.) The advice is obvious a) put a shim in >> front of your MLM to reject discardable mail and b) the usual advice not >> to use ADSP at all, but it definitely needs publishing. > > The other piece of advice should be to actually discard, rather than > rejecting, discardable email. That would have protected the subscriber from > automatic unsubscription. The advice should be to discard the mail vs. bouncing it back to the MLM. That solves the use case of subscribers being auto-unsubscribed to mail lists without undermining all the other use cases that led the IETF to standardize ADSP in the first place. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 20, 2010, at 6:01 PM, McDowell, Brett wrote: > B) I'm going to re-subscribe to this (and all outside-the-firewall mailing > lists) with a personal email address to avoid the current situation (of my > messages going to SPAM or the bit bucket due to the firm ADSP=discardable > policy on paypal.com and MLM's inability to sustain DKIM signatures in a form > receivers need to see it in order to verify the paypal.comsignature). It's a > temporary work-around and we are developing a long-term solution for our > employees that I'll write about once it's live so other ADSP=discardable > organization can learn from our experience. This is just a quick follow-up to let folks know that I'll be using this personal account for public mail lists until we have addressed the "DKIM+ADSP=discardable breaks MLM's/MLM's break DKIM+ADSP=discardable" problem in a more systemic manner. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
