Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
>12. I haven't tweaked anything. Assuming my reading of the >configuration files is correct, spamassassin is querying ADSP for >incoming mail, and applying a positive bump to the "spamminess" score >when a message comes from a domain with dkim=all, and a bigger bump for >dkim=discardable. This could account for many of the adsp lookups that >people are seeing. That's mostly right. In 60_adsp_override_dkim.cf they hotwire fake ADSP values for about 90 domains, with the discardable ones including paypal and ebay in many variants, some greeting cards like americangreetings.com (Hi, Mike) and a few banks. The "all" ones include amazon and a fairly randon group probably from mail the developers got, e.g. astrology.com, linkedin.com,, and *.greenpeace.org. They also set lower weights for gmail and yahoo, only if the mail doesn't look like it came through a mailing list. 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
MH Michael Hammer (5304) wrote: > > I'm still waiting for someone to produce use numbers (of domains) for > ADSP. Just out of curiosity, what number do we have to reach to hit the > technical term "massive"? Somehow I doubt that in it's current > incarnation ADSP will ever have massive implementation. > I recently surveyed the domains from which Cisco has received valid DKIM signatures: dkim=unknown: 205 domains dkim=all: 135 domains dkim=discardable: 63 domains There are perhaps some other domains that are publishing 'discardable' because they don't send any mail, but we wouldn't have seen them in this study. There's only a weak motivation (involving better DNS caching) for publishing dkim=unknown, so it's hard to gauge ADSP deployment by that number. In order to publish all or discardable, the domain's practices need to align with that, so unless there's a way to tell that a domain is signing all their mail and not publishing ADSP then it's challenging to gauge ADSP deployment for either of these categories. Addressing a question from elsewhere else in this massive thread, my home MTA runs the stock version of spamassassin that comes with Fedora 12. I haven't tweaked anything. Assuming my reading of the configuration files is correct, spamassassin is querying ADSP for incoming mail, and applying a positive bump to the "spamminess" score when a message comes from a domain with dkim=all, and a bigger bump for dkim=discardable. This could account for many of the adsp lookups that people are seeing. -Jim ___ 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
havnt been keeping up with all of the threads so forgive me if I am repeating earlier arguments ADSP is crippled, intentionally so. Its usefulness is limited to financial transaction types of transactions that may well be easily duplicated with a whale lamp, quill and parchment rbl management. DKIM is useful to determine who actually sent the mail. 1/2 of SPAM has valid DKIM signatures, the other half (bots) dont use it. It is a decent indicator that is useful along with all of the other tools on the belt. Its not a standalone fixall. carry on, Bill On Jun 2, 2010, at 4:21 PM, MH Michael Hammer (5304) wrote: > > >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of Brett McDowell >> Sent: Wednesday, June 02, 2010 3:46 PM >> To: John R. Levine >> Cc: DKIM List >> Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong >> Discussion >> > > > >> >> What surprises me is how our efforts have been received by the > community >> who produced these standards in the first place. >> >> > > Brett, I'm sorry you are surprised. > > This space has been contentious going back something like 10 years (or > more). Many of the participants go at it tong and hammer but we can > still sit down for dinner or a drink at the usual gatherings. > > Truth be told, the Financial sector (including PayPal) as well as other > key groups have been pretty much MIA from a lot of the discussions for a > long time. Many of the points of contention have been discussed ad > nauseum over the years without resolution or through compromises that > gave us crippled outcomes like ADSP. > > Actually, IETF has been somewhat mild compared to MARID . > > Mike > > ___ > 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 12:28 PM, Brett McDowell wrote: > > On Jun 2, 2010, at 2:41 PM, Steve Atkins wrote: > >> >> 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. I did[1]. It looks like your mailsystem is discarding email it shouldn't. There's a copy at http://tupid.org/paypal1.txt if you can't find it. It seems that paypal is not currently monitoring phishing, nor doing anything to deter it, on 99.9% of the domains they own, so have no real idea of what phishing is going on. Pointing those thousand domains at a catch-all mailserver with a wildcard MX and looking for bounces and spamfilter rejections might be a good way of getting metrics about how phishers respond to domains being owned by paypal over time. Those same metrics after adding SPF and ADSP records for those domains over time would be interesting. http://blog.wordtothewise.com/2010/05/how-to-disable-a-domain/ has some examples of how to set those up. That's the sort of data gathering I was suggesting you do, rather than just a bald count of DNS queries, when I looked at the numbers for my mailbox. (There's a copy of my raw data at http://tupid.org/paypal1.sql.txt if anyone is interested in running their own model against it.) (I'm not going to respond to the other misunderstandings unless someone really wants me to. I'm guessing most people are long past tl;dr at this point.) Cheers, Steve [1] May 28 13:54:47 fruitbat postfix/smtp[31990]: DA551814E6: to=, relay=gort.ebay.com[216.113.167.215]:25, delay=0.74, delays=0.17/0/0.45/0.11, dsn=2.0.0, status=sent (250 ok: Message 769193797 accepted) ___ 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
> -Original Message- > From: Dave CROCKER [mailto:d...@dcrocker.net] > Sent: Wednesday, June 02, 2010 4:26 PM > To: MH Michael Hammer (5304) > Cc: DKIM List > Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong > Discussion > > > > On 6/2/2010 1:21 PM, MH Michael Hammer (5304) wrote: > > Actually, IETF has been somewhat mild compared to MARID. > I appreciate that you understood what I meant rather than what I wrote. > > Narrower topic. Smaller group. > > Made it a lot easier to be selective with the attacks... > Actually, I think it was because MARID involved much more of the characteristics of a religious war. This is merely about passionate philosophical positions. 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
> -Original Message- > From: Dave CROCKER [mailto:d...@dcrocker.net] > Sent: Wednesday, June 02, 2010 4:06 PM > To: MH Michael Hammer (5304) > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong > Discussion > > > > On 6/2/2010 12:58 PM, MH Michael Hammer (5304) wrote: > >> Since we've been seeing reports of breakage due to using ADSP records > for > >> domains that are not under sufficient control, it is clear that some > >> fraction of the ADSP-using world does not understand what it is for, or > at > >> least what its limitations are. > > > > If we apply this to other standards (SMTP, DNS, HTTP, etc) we would just > > have to power down the whole internet. The best that we can do is come > up > > with something that makes a modicum of sense, fix things we didn't > anticipate > > or understand because we needed operational experience and move on. > > > > There will always be some fraction of the user/implementer base that > won't > > understand protocols, standards or RFCs. It kind of goes with the > territory. > > > Mike, this is the sort of discussion disconnect that prevents making > progress. > I'm copying the list because it's a broad-based problem we are all having > in > trying to discuss issues. > Simply stating that we are seeing some reports of breakage due to using ADSP records for domains that are not under sufficient control does not add much of anything meaningful to the discussion. This issue has been discussed for YEARS and now that we see it some people are acting shocked? I'm shocked I tell you. I seem to remember this very discussion at an excellent dinner following the FTC workshop in 2007. This same discussion was held years before that when SSP was just a gleam in everyone's eye. This is something that was predicted and predictable. At the end of the day, ADSP was a compromise that limited usefulness to a handful of corner cases implemented under extremely tight control at the risk of breakage and collateral damage if not carefully implemented. > First, a question was put forward and I offered an answer. It is simply > not > fair to then respond in a manner that dismisses that answer (or at least > dismisses it in this way.) > > Second, the usual way that services get successful is to look for problems > in > their use and look for ways to correct them. Simply saying that there are > always some problems is not helpful. > We know the answers for ADSP... see above. > Third, we do not have massive amounts of ADSP success which permits > marginalizing a tiny amount of problems. We have tiny use, with notable > breakage. > I'm still waiting for someone to produce use numbers (of domains) for ADSP. Just out of curiosity, what number do we have to reach to hit the technical term "massive"? Somehow I doubt that in it's current incarnation ADSP will ever have massive implementation. >From another perspective, in the greater scheme of standards, ADSP is still very much wet behind the ears. It wasn't until October of 2008 that there was interoperability testing. > Fourth, it has become increasingly clear to me, at least, that there is > broad-based misunderstanding of what can reasonably be accomplished with > DKIM > and what can reasonably be accomplished with ADSP, versus what cannot. I agree with you on that. Something along the lines of pixie dust, unicorn horns, magic spam prevention, makes you taller and your teeth whiter... > Failure > to gain broad-based agreement about both capabilities and limits ensures > an > on-going mismatch in expectations. > And thus the rise of 3rd party "trusted intermediaries". > 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. > I'm not a proponent and I'm not saying things are great. I believe I've stated a few times that I believe that ADSP is crippled and I don't see myself publishing "discardable". When the counterpoints are along the lines of "some people" have "some problems" and the point is made "if we were following the standard then we wouldn't be seeing your mail anyways", then my response is. then why aren't you discarding it? Either you believe in the standard you helped craft or you don't. 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. 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 6/2/2010 1:21 PM, MH Michael Hammer (5304) wrote: > Actually, IETF has been somewhat mild compared to MARID. Narrower topic. Smaller group. Made it a lot easier to be selective with the attacks... 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
> -Original Message- > From: MH Michael Hammer (5304) > Sent: Wednesday, June 02, 2010 4:21 PM > To: 'Brett McDowell'; John R. Levine > Cc: DKIM List > Subject: RE: [ietf-dkim] list vs contributor signatures, was Wrong > Discussion > > > > > Actually, IETF has been somewhat mild compared to MARID . > > Mike Apologies, that should read IETF-DKIM ___ 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
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Brett McDowell > Sent: Wednesday, June 02, 2010 3:46 PM > To: John R. Levine > Cc: DKIM List > Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong > Discussion > > > What surprises me is how our efforts have been received by the community > who produced these standards in the first place. > > Brett, I'm sorry you are surprised. This space has been contentious going back something like 10 years (or more). Many of the participants go at it tong and hammer but we can still sit down for dinner or a drink at the usual gatherings. Truth be told, the Financial sector (including PayPal) as well as other key groups have been pretty much MIA from a lot of the discussions for a long time. Many of the points of contention have been discussed ad nauseum over the years without resolution or through compromises that gave us crippled outcomes like ADSP. Actually, IETF has been somewhat mild compared to MARID . 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 6/2/2010 12:58 PM, MH Michael Hammer (5304) wrote: >> Since we've been seeing reports of breakage due to using ADSP records for >> domains that are not under sufficient control, it is clear that some >> fraction of the ADSP-using world does not understand what it is for, or at >> least what its limitations are. > > If we apply this to other standards (SMTP, DNS, HTTP, etc) we would just > have to power down the whole internet. The best that we can do is come up > with something that makes a modicum of sense, fix things we didn't anticipate > or understand because we needed operational experience and move on. > > There will always be some fraction of the user/implementer base that won't > understand protocols, standards or RFCs. It kind of goes with the territory. Mike, this is the sort of discussion disconnect that prevents making progress. I'm copying the list because it's a broad-based problem we are all having in trying to discuss issues. First, a question was put forward and I offered an answer. It is simply not fair to then respond in a manner that dismisses that answer (or at least dismisses it in this way.) Second, the usual way that services get successful is to look for problems in their use and look for ways to correct them. Simply saying that there are always some problems is not helpful. Third, we do not have massive amounts of ADSP success which permits marginalizing a tiny amount of problems. We have tiny use, with notable breakage. Fourth, it has become increasingly clear to me, at least, that there is broad-based misunderstanding of what can reasonably be accomplished with DKIM and what can reasonably be accomplished with ADSP, versus what cannot. Failure to gain broad-based agreement about both capabilities and limits ensures an on-going mismatch in expectations. 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. 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
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Dave CROCKER > Sent: Wednesday, June 02, 2010 3:48 PM > To: Brett McDowell > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong > Discussion > > > > On 6/2/2010 11:29 AM, Brett McDowell wrote: > > 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? > > > Since we've been seeing reports of breakage due to using ADSP records for > domains that are not under sufficient control, it is clear that some > fraction of > the ADSP-using world does not understand what it is for, or at least what > its > limitations are. > If we apply this to other standards (SMTP, DNS, HTTP, etc) we would just have to power down the whole internet. The best that we can do is come up with something that makes a modicum of sense, fix things we didn't anticipate or understand because we needed operational experience and move on. There will always be some fraction of the user/implementer base that won't understand protocols, standards or RFCs. It kind of goes with the territory. 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
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Wednesday, June 02, 2010 3:38 PM > To: MH Michael Hammer (5304) > Cc: DKIM List > Subject: RE: [ietf-dkim] list vs contributor signatures, was Wrong > Discussion > > > I can't help myself. This image of John sitting at a desk with his quill > > and inkwell manually maintaining his credible list by the light of a > > whale oil lamp keeps popping into my minds eye. How scalable is that > > list John? > > If ye towne cryer dost distribute such a liste to manye and divers mail > servers, as scalable as ye do wante. > This addresses distribution of the list, not maintaining the list. Ye olde add/change/delete issue. And of course there is the question of whether folks will trust (the generic) you as widely as a solid standards based approach for self-publication. > I agree it would be useful to have a way to discover whose mail is signed > and usefully discardable. But there's little reason to think that > self-publication along the lines of ADSP will do it successfully. > There's little reason to think it won't. Time wounds all heels. As I've said before, I believe ADSP is crippled intentionally so. There were compromises of various sorts in order to be able to get the document out. One need only look at the discussions around SSP drafts 1- I think it was 13 or so). Could it be fixed? Possibly. Will it be fixed? Doubtful. It is unlikely that there will be sufficient will or consensus from this working group for such an effort to be successful. 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
> If the domain or subdomain involved has enduser (at all) accounts then > it is likely a poor candidate for ADSP "DISCARDABLE". ADSP "DISCARDABLE" > should be used for domains that are subject to high levels of abuse and > are used primarily for transactional or marketing email and where the > mail flows are strictly controlled. I entirely agree. (So there!) The question remains how to reliably identify such domains. 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 6/2/2010 11:29 AM, Brett McDowell wrote: > 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? Since we've been seeing reports of breakage due to using ADSP records for domains that are not under sufficient control, it is clear that some fraction of the ADSP-using world does not understand what it is for, or at least what its limitations are. 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 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
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of John R. Levine > Sent: Wednesday, June 02, 2010 3:26 PM > To: Brett McDowell > Cc: DKIM List > Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong > Discussion > > >> 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. > > R's, > John > HA! Something John and I find common ground on. But whereas John's answer is that people shouldn't use ADSP (A strange position for an author of ADSP) my answer is that people need to be better educated or accept that they run the risk of their endusers mail getting handled in potentially suboptimal ways. It's not that people don't care, it's that this stuff (not just ADSP) is not particularly easy to understand and implement. Brett is relatively new to this space and wasn't responsible for the PayPal implementation but as soon as the maillist/enduser problem was pointed out to him he started working on addressing it. Personally, I'm not feeling quite as adventurous as to implement ADSP "DISCARDABLE" because it still isn't clear what the breakage rate on forwarding is. Publishing "ALL" isn't appealing because it leaves ambiguous what outcome a sender might expect. Do I get the gain for the pain or do I get nothing or ? Be that as it may, I'm going to point out again that the MLM issue is the tail and not the dog. From a BCP perspective it is straightforward to me: If the domain or subdomain involved has enduser (at all) accounts then it is likely a poor candidate for ADSP "DISCARDABLE". ADSP "DISCARDABLE" should be used for domains that are subject to high levels of abuse and are used primarily for transactional or marketing email and where the mail flows are strictly controlled. 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
> I can't help myself. This image of John sitting at a desk with his quill > and inkwell manually maintaining his credible list by the light of a > whale oil lamp keeps popping into my minds eye. How scalable is that > list John? If ye towne cryer dost distribute such a liste to manye and divers mail servers, as scalable as ye do wante. I agree it would be useful to have a way to discover whose mail is signed and usefully discardable. But there's little reason to think that self-publication along the lines of ADSP will do it successfully. 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 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
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Michael Thomas > Sent: Wednesday, June 02, 2010 3:07 PM > To: Steve Atkins > Cc: DKIM List > Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong > Discussion > > 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. > > Mike > Thousands of domains registered and counting. Been doing it well before ADSP and view it as only one of the things that owners of abused domains do. 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 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 want to discredit the statistics and I understand you wanted to report statistics to discredit ADSP... actually I don't understand that but it is certainly consistent with your arguments > - they show that as measured at my inbox, based on paypal related email, ADSP > dkim=discardable as currently used by PayPal to combat phishing is > significantly less useful than flipping a coin. 72% false positive, 61% false > negative. but your processing assumptions about what would get through vs. what would bounce was wrong. > > These statistics are quite valid, a
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
> 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. This is a non-sequitur, but we've been through it before so I won't keep beating the greasy spot where the horse used to be. 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
>> 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. 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 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 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. 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 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] 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
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. 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. 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. 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 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 want to discredit the statistics - they show that as measured at my inbox, based on paypal related email, ADSP dkim=discardable as currently used by PayPal to combat phishing is significantly less useful than flipping a coin. 72% false positive, 61% false negative. These statistics are quite valid, and reasonably representative. The only non-representative thing about them is that they're measured at my mailbox, rather than at a consumer mailbox of a user who has no interaction with PayPal other than transactional and bulk email (which is a big difference, sure, but it seems unlikely paypal would want to drop all usage of paypal.com other than for their bulk mail).. So rather than attacking the statistics that demonstrate that your current usage of ADSP simply doesn't work for it's stated purpose it would be better to concentrate on fixing the serious issues that those stats demonstrate. I'd start with the hideously high false positive rate, as that's an easier thing to fix than the hideously high false negative rate. We've already discussed some ways to improve the false positive rate (dedicating entire domains to B2C bulk mail rather than mixed use, rewriting every mailing list manager in the world and so on). Constraining ADSP usage to domains that are solely used to send bulk email to consumer ISPs strikes me as something that would be acceptable to many potential users, and would avoid most of the false positive issues. Cheers, Steve ___ NOTE WELL: This list operat
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Wednesday, June 02, 2010 2:25 PM > To: Brett McDowell > Cc: MH Michael Hammer (5304); ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong > Discussion > > > Well, you'd process that mail as if... there were no ADSP policy > because... there's no ADSP policy. > > I guess I agree, since I would use a credible manually maintained > list and ignore the ADSP whether or not there was any. > I can't help myself. This image of John sitting at a desk with his quill and inkwell manually maintaining his credible list by the light of a whale oil lamp keeps popping into my minds eye. How scalable is that list John? So ___ 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
> Well, you'd process that mail as if... there were no ADSP policy because... > there's no ADSP policy. I guess I agree, since I would use a credible manually maintained list and ignore the ADSP whether or not there was any. 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
"John Levine" wrote: >>Similarly, with ADSP you don't have to rely on published information, and >>when information is published, you don't have to guess whether the >>publisher is competent. You can maintain your own list of domains that you >>trust to get ADSP right, and use standard software to apply that judgement. > >Manual drop lists are a fine idea, but what do they have to do with ADSP? > >>1. Code reuse: Although you may choose to maintain your drop list, you >>don't have to write software for your MTA, you can just configure it. > >I'm happy to reuse the manual drop code in Spamassassin. I still don't >see what it has to do with ADSP. > >>2. Discoverability: You can find out from ADSP publications that the sender >>cares about this stuff. OK, it's still a leap to add them to your drop >>list, but you do at least have somewhere to start. > >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? Or, I suspect most likely, they thought they were signing everything and then later something changed or they discovered they missed a piece of their infrastructure, so they've retracted the policy until they've corrected the problem. 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 6/2/2010 9:12 AM, MH Michael Hammer (5304) wrote: > > For shame Dave. Taking one sentence out of context is something I would > not have expected from you. After all this time, I am glad to hear that I can still surprise you... FWIW I took it out of context entirely knowingly. Frankly, I wasn't interested in the particular topic. As I said, I think that that captures the critical difference in what drives the two sides of these various-but-really-identical debates. The particular context wasn't the point. The difference in attitudes about /any/ of these topics is the point. > The whole point of having a standard is to avoid the voodoo and > guessing. Right. And a standard that is not adopted or used does not achieve this. Worrying very carefully about adoption barriers -- who will adopt it and why -- is essential to this, but we have not been succeeding in getting answers to hard questions here. > You are absolutely correct that we should anticipate failures. That does > not mean we should anticipate FAILURE from a reasonably crafted > standard. Actually, yes it does. That is exactly my point. A side effect of living in Silicon Valley is seeing how often carefully crafted startups fail. Good ideas and a well-designed product are not sufficient to guarantee success, absent properly matching the /perceived/ needs of the folks who will use it /and/ the folks who will pay for it. > We cannot protect foolish people from doing foolish things to > themselves. This is another case of King Canute. The benefit of that perspective is acknowledging limitations. The danger is not putting in enough effort to make things appropriately usable and/or not putting enough effort into crafting a value proposition that is compelling to the target audience. 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 Jun 2, 2010, at 4:50 AM, Ian Eiloart wrote: > > > --On 27 May 2010 14:57:06 -0700 Steve Atkins wrote: > >> >>> 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. > > How many used "<�...@paypal.com>"? 100% of the legitimate email from paypal. 39% of the phishing email that used "paypal" in the From line. (A large fraction of the 61% of the phishing email that ADSP considered legitimate did use "@paypal.com", though, IIRC. More use of friendly from and less use of associated domains than I've noticed in recent phishing mail in general.) 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
For shame Dave. Taking one sentence out of context is something I would not have expected from you. When I say "It is simple" in response to Johns artificially constructed hypothetical, this is not the sweeping statement of the universe you are trying to present it as. In Johns example he is trying to conflate "I believe that someone always signs their mail" with ADSP. These are two different animals. Notice that he didn't indicate whether the person used "ALL" or "DISCARDABLE". He artificially gave us a binary set of choices when in fact there are many more choices available. The whole point of having a standard is to avoid the voodoo and guessing. If John or someone else were really that concerned about a particular domain's signing circumstances I would expect him/them to contact the domain in question. The whole point of a standard is to avoid the one-on-one checking. Now during initial rollouts I would expect people to do some validation and checking. You are absolutely correct that we should anticipate failures. That does not mean we should anticipate FAILURE from a reasonably crafted standard. We cannot protect foolish people from doing foolish things to themselves. This is another case of King Canute. Document, yes. Educate, yes. Protect from themselves, no. BTW John, I want to thank you for teaching me to invoke this. Mike > -Original Message- > From: Dave CROCKER [mailto:d...@dcrocker.net] > Sent: Wednesday, June 02, 2010 11:48 AM > To: MH Michael Hammer (5304) > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong > Discussion > > > > On 6/2/2010 6:33 AM, MH Michael Hammer (5304) wrote: > > It's really quite simple. > > > This is the crux of the disparity of views. > > Those of use who note that none of this is simple worry about adoption and > success barriers, noting that new services have a long and problematic > history > and that more efforts fail than succeed. > > We also note that operational details often are far more complicated > and/or > costly than designers anticipate. > > In other words, as soon as the effort moves outside of a few people's > minds, > nothing about this is simple. (Well, given the track record of new > protocols, > in general and security-related protocols in particular, I suppose it is > simple > and reasonable to anticipate failure.) > > 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 6/2/2010 6:33 AM, MH Michael Hammer (5304) wrote: > It's really quite simple. This is the crux of the disparity of views. Those of use who note that none of this is simple worry about adoption and success barriers, noting that new services have a long and problematic history and that more efforts fail than succeed. We also note that operational details often are far more complicated and/or costly than designers anticipate. In other words, as soon as the effort moves outside of a few people's minds, nothing about this is simple. (Well, given the track record of new protocols, in general and security-related protocols in particular, I suppose it is simple and reasonable to anticipate failure.) 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
> -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. If there is no longer an ADSP record then ADSP is not applicable. Doesn't matter whether they are still signing or not signing. If a domains DNS records returned an NXDOMAIN on a lookup would you insist on doing something other than saying the domain doesn't exist? 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 2 June 2010 08:35:56 -0400 "John R. Levine" wrote: > > There's ADSP code in Spamassassin for anyone who wants it. They suggest > that you configure it to ignore actual ADSP and hard code a handful of > domains such as paypal.com and ebay.com. > Why not do both? Look up, and log results for all domains. That'll give you evidence to base listing decisions on later. If you do decide to list a domain, then take action based on published policy. That gives the publisher the ability to change their policy without notifying you out of band. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
>Similarly, with ADSP you don't have to rely on published information, and >when information is published, you don't have to guess whether the >publisher is competent. You can maintain your own list of domains that you >trust to get ADSP right, and use standard software to apply that judgement. Manual drop lists are a fine idea, but what do they have to do with ADSP? >1. Code reuse: Although you may choose to maintain your drop list, you >don't have to write software for your MTA, you can just configure it. I'm happy to reuse the manual drop code in Spamassassin. I still don't see what it has to do with ADSP. >2. Discoverability: You can find out from ADSP publications that the sender >cares about this stuff. OK, it's still a leap to add them to your drop >list, but you do at least have somewhere to start. 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? 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 6/2/2010 4:46 AM, Ian Eiloart wrote: > --On 28 May 2010 13:26:28 -0700 Dave CROCKER wrote: >> On 5/28/2010 12:07 PM, Jeff Macdonald wrote: >>> But I'd like to see if I understand the difference your are trying to >>> highlight between a manually maintained list and a self published >>> list. >> >> There is a key semantic difference which, I believe, makes for a key >> difference in utility. ... > > Actually, the difference is less than you think. It's quite possible to > combine both models. You do not discuss "combining" the models. You discuss a tool that supports both. Juggling two things is not the same as combining them. In any event, the scope of this working group does not include design of filtering engines. It stops with providing filtering engines additional information. My previous point was -- and remains -- that the fundamental semantics of self-published information about a signer is entirely different from assessment information about that signer that is published by someone else. No software design eliminates that difference. > Effectively, you're applying your own domain reputation system, and using > SPF or DKIM published information to make the reputations more usable. That's not a "reputation" system. It's possibly useful information, but it's not "reputation" as the term is typically used in the industry. 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
>> 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. > > It should be fairly easy to figure out how many unique IP addresses are doing > the lookups, and give some view of the distribution. And then not too hard to > figure out how many of those IP addresses don't belong to the top 5 or so > mailbox providers. That would be of some help, but the real question is what they're doing with it after they get it. The top mailbox providers presumably have reasonable DNS caches, so their lookups will be imperceptible anyway. Since few people in the world at large understand DKIM, much less ADSP, the large numbers of lookups that Brett reports must be coming from software packages that have a configuration that looks them up. It might be possible to intuit from the details of the lookups, e.g., the sequence of queries, what packages they are, at which point we could probably look and see what they're doing with them. > If paypal want to broaden the uptake of ADSP, then contributing DKIM/ADSP > code or config recipes to open source MTA projects would be useful! There's ADSP code in Spamassassin for anyone who wants it. They suggest that you configure it to ignore actual ADSP and hard code a handful of domains such as paypal.com and ebay.com. 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 26 May 2010 15:51:33 -0400 Brett McDowell wrote: > 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? He seems to be. There are several approaches that could be taken: 1. A publication mechansism that allows you to say which cousin domains you have registered. 2. A filter checking domains with Hamming distance measurements. Like a magnifying glass casts a shadow round the focal point, I'd imagine that domains close to those with high reputation could be assigned negative reputation - unless they acquired reputation from (1) above. 3. It simply would not be advisable to use cousin domains. Though registering them to prevent use might be a good option. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
--On 28 May 2010 13:26:28 -0700 Dave CROCKER wrote: > > On 5/28/2010 12:07 PM, Jeff Macdonald wrote: >> But I'd like to see if I understand the difference your are trying to >> highlight between a manually maintained list and a self published >> list. > > There is a key semantic difference which, I believe, makes for a key > difference in utility. > > In a manually maintained list, there is an independent assessment of what > domain names are worth worrying about. (The independence is from the > owner of the domain. The assessment might be by a third part or it > might be by the recipient.) > > The owner-based list is a statement by the domain owner, themselves, of > what domains the recipient should handle in a particular way. > > An important problem with this latter model is how noisy it is. Both the > domain owner and the transmission process introduce significant errors. > > By contrast, the former model can incorporate a conformance metric into > the decision whether to list the domain. > Actually, the difference is less than you think. It's quite possible to combine both models. Spamassassin, for example, allows you to maintain a list of domains for which you should treat SPF or DKIM matches or fails in a particular way. For example, you could tell spamassassin to blacklist SPF fails for certain domains, or whitelist messages DKIM signed by certain domains. Effectively, you're applying your own domain reputation system, and using SPF or DKIM published information to make the reputations more usable. Similarly, with ADSP you don't have to rely on published information, and when information is published, you don't have to guess whether the publisher is competent. You can maintain your own list of domains that you trust to get ADSP right, and use standard software to apply that judgement. Several benefits are gained from ADSP: 1. Code reuse: Although you may choose to maintain your drop list, you don't have to write software for your MTA, you can just configure it. 2. Discoverability: You can find out from ADSP publications that the sender cares about this stuff. OK, it's still a leap to add them to your drop list, but you do at least have somewhere to start. If a large sender and receiver come to a private agreement about DKIM use, then only they benefit. If they choose to use ADSP to implement that agreement, then other mail systems can also benefit. 3. Discussability: given that it's a standard, potential users can read about best practice, and senders and receivers have a common language to talk about how things should work. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
--On 27 May 2010 14:57:06 -0700 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. How many used "<�...@paypal.com>"? > Cheers, > Steve > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 4:08 AM, Ian Eiloart wrote: > --On 26 May 2010 14:00:54 -0700 Steve Atkins > wrote: >>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. > > There's nothing "undisplayed" about the From header in my mail client. That's nice, but it is no longer typical. Far From: it > Mail > clients that don't display the From header address probably should not be > used. As soon as you convince all of the major MUAs to change and as soon as those changes propagate into the user world, it will be reasonable to worry about whether displaying the information matters. That is, it will be reasonable to then ask whether users will assess the validity of that information and make intelligent decisions based on it. (Hint: user interface works makes pretty clear that they won't...) 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 27 May 2010 21:57:54 -0400 "John R. Levine" wrote: >> 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. > It should be fairly easy to figure out how many unique IP addresses are doing the lookups, and give some view of the distribution. And then not too hard to figure out how many of those IP addresses don't belong to the top 5 or so mailbox providers. If paypal want to broaden the uptake of ADSP, then contributing DKIM/ADSP code or config recipes to open source MTA projects would be useful! -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
--On 26 May 2010 14:00:54 -0700 Steve Atkins wrote: > > 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. > There's nothing "undisplayed" about the From header in my mail client. Mail clients that don't display the From header address probably should not be used. In future, I'll bet they'll display the DKIM/ADSP status, too. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
--On 26 May 2010 11:48:53 -0700 Michael Thomas wrote: > >> 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. 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. Addressing an issue and solving it aren't the same things. Heck, neither is even a prerequisite for the other, given that some problems are self-resolving or solved accidentally. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 5/28/10 2:24 PM, Rolf E. Sonneveld wrote: > Dave CROCKER wrote: > >> On 5/28/2010 12:07 PM, Jeff Macdonald wrote: >> >>> But I'd like to see if I understand the difference your are trying to >>> highlight between a manually maintained list and a self published >>> list. >>> >> There is a key semantic difference which, I believe, makes for a key >> difference >> in utility. >> >> In a manually maintained list, there is an independent assessment of what >> domain >> names are worth worrying about. (The independence is from the owner of the >> domain. The assessment might be by a third part or it might be by the >> recipient.) >> > Before going forward talking about 'manually maintained lists' can > someone define what that is? What exactly are we talking about, how does > it operate, by whom, involved parties etc.? > Dave has well defined the difference between ADSP assertions and manually created lists of authentication acceptance criteria. In the latter case, a domain is unable to react. For manually generated lists, these represent a reaction to domains being flooded with phishing attempts. As with the course of rivers changing over time, this often happens by getting wider. If ADSP were easier to use without being disruptive, restrictive ADSP assertions would be more common. -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
Dave CROCKER wrote: > On 5/28/2010 12:07 PM, Jeff Macdonald wrote: > >> But I'd like to see if I understand the difference your are trying to >> highlight between a manually maintained list and a self published >> list. >> > > There is a key semantic difference which, I believe, makes for a key > difference > in utility. > > In a manually maintained list, there is an independent assessment of what > domain > names are worth worrying about. (The independence is from the owner of the > domain. The assessment might be by a third part or it might be by the > recipient.) > Before going forward talking about 'manually maintained lists' can someone define what that is? What exactly are we talking about, how does it operate, by whom, involved parties etc.? /rolf ___ 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/28/10 2:09 PM, Al Iverson wrote: > On Fri, May 28, 2010 at 3:34 PM, John Levine wrote: > >>> In past discussions there had been an expressed concern that the >>> number of domains/companies who send notifications and are phish >>> targets is very low, but I would counter that it is not low at all. >>> >> The question is low compared to what. There are probably thousands, >> maybe tens of thousands of domains that send financial notifications, >> but that's pretty low compared to the millions of domains overall. >> > High enough number to matter? IMHO, yes. > FWIW, our company has identified more than 20K such domains. Unfortunately, the number is rising and remains a burden for administrators to track independently. -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 Fri, May 28, 2010 at 3:34 PM, John Levine wrote: >>In past discussions there had been an expressed concern that the >>number of domains/companies who send notifications and are phish >>targets is very low, but I would counter that it is not low at all. > > The question is low compared to what. Â There are probably thousands, > maybe tens of thousands of domains that send financial notifications, > but that's pretty low compared to the millions of domains overall. High enough number to matter? IMHO, yes. Percentage compared to domains that don't need this kind of protection? Irrelevant, because the raw number is already at the hundreds of domains level, across my employer's client base alone. And I know I'm not alone. Way back when, it was actually you and me and a few other people talking about this at a conference, and I vaguely recall (forgive me if I am wrong) that you were thinking it was "could count on both hands the number of domains that need ADSP-style protection", i.e. the custom agreements between Ebay and Gmail scale well enough. IMHO, I personally am way beyond that level. Aren't others? At what level would folks agree that this no longer scales, and we need a sender publishable function like this, instead? I grant that this ultimately needs more receiver buy-in (or at least more than I personally observe), but these are unanswered questions that have been nagging at me. Cheers, Al ___ 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
>In past discussions there had been an expressed concern that the >number of domains/companies who send notifications and are phish >targets is very low, but I would counter that it is not low at all. The question is low compared to what. There are probably thousands, maybe tens of thousands of domains that send financial notifications, but that's pretty low compared to the millions of domains overall. 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/28/2010 12:07 PM, Jeff Macdonald wrote: > But I'd like to see if I understand the difference your are trying to > highlight between a manually maintained list and a self published > list. There is a key semantic difference which, I believe, makes for a key difference in utility. In a manually maintained list, there is an independent assessment of what domain names are worth worrying about. (The independence is from the owner of the domain. The assessment might be by a third part or it might be by the recipient.) The owner-based list is a statement by the domain owner, themselves, of what domains the recipient should handle in a particular way. An important problem with this latter model is how noisy it is. Both the domain owner and the transmission process introduce significant errors. By contrast, the former model can incorporate a conformance metric into the decision whether to list the domain. > Manually, there is confidence in understanding the > ramifications. Self published (ADSP) there is no assurance in the > understanding of the ramifications. Right. That's true, as well as the difference in the basis for the entry. > Therefore the data collected from > one method is not applicable to the other? The end result (discarding) > would somehow end up different? I am increasingly suspecting that ADSP's real benefit is in avoiding false positives, rather than the false negatives as we've always discussed. This is predicated on the importance of that "which domains should I care about?" manual list. 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 5/28/10 9:24 AM, Alessandro Vesely wrote: > I agree ADSP currently leaves much to be desired. It deserves > completion. (DKIM itself is in a similar situation, since it is still > not MIME-compliant. A somewhat embarrassing circumstance for a > protocol designed not to "break forwarding".) > Major providers such as AOL had insisted on breaking MIME, and S/MIME. This has changed, where more of their users access email by the web, as the era of modem squeals and "You've got mail." fades. However, provisions allowing modifications can be exploited. Had DKIM's canonicalization recognized MIME, then enumerating MIME sections could have been less problematic than line counting. Such a change to DKIM remains possible, where damage by comments added by forwarding services can still be remedied with reliance upon their Authentication-Results headers. Ideally, only this header would be added along with it being universally understood by mail clients. Until then, things will break. > At any rate, let me note that besides countering phishing, ADSP plays > a possibly more foundational role: it/characterizes/ DKIM signatures. > Thus, there may be further *DSPs, e.g. > > * list signature, tied to the signed List-ID, > * forwarder signature, tied to an SPF-validated 5321.mfrom. > I'd be interested in adding an experimental option for DKIM able to process a sender's instruction of which domains should be granted exceptions. I'd be reluctant to restrict which verification methods should be used, only what items should be available for such. If there is a concern about using of DNAME, a new label could be defined that permits third-party delegation with a CNAME. This method would still leave the phished domains in control, and allow them to react to reported problems. As it is now, there is little they can do when a problem occurs. > These characterizations integrate assessments. By qualifying the > reasons why a given party signs a message, they give an insight into > the mail transmission process, which may lead to the possibility of > tuning it, e.g. by routing feedback appropriately. OTOH, unqualified > signatures only entrust limited responsibility, as they don't say what > questions the signer should be able to respond to. In this respect, an > hypothetical reputation system that allowed to compute a message's > worthiness up to 16 digits of precision, albeit useful, wouldn't > differ much from spamassassin's fuzzy approach. > This might sound a bit strange, but reputation systems are primarily concerned with spam in general. Sender authorization for ADSP exceptions (LDSP as it might be described) is likely the only input that could safely allow exceptions. -Doug Side note: Although the Authentication-Results header is new, it suffers from a security weakness as well. The IP address seen at border MTAs when receiving public messages (those unauthenticated over port 25) is not normally captured. Only authenticated messages should exclude this information. In an era where compromised systems are the predominate source of spam, this missing information is often the only identifier able to locate problematic sources. People should not view this as a privacy issue, but instead see the greater concern being whether their system is compromised and is directly distributing spam. Bots and rats (remote access trojans) do nefarious things well beyond spamming, like key-logging and spoofing account details from your bank. The related criminal enterprise is growing, with their outward presence becoming less obvious. Ever since XP SP3, there is 10MB of boot space that is able to hide all types of VM. :^( ___ 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 Fri, May 28, 2010 at 2:32 PM, John R. Levine wrote: >> But I'd like to see if I understand the difference your are trying to >> highlight between a manually maintained list and a self published >> list. Manually, there is confidence in understanding the >> ramifications. Self published (ADSP) there is no assurance in the >> understanding of the ramifications. Therefore the data collected from >> one method is not applicable to the other? The end result (discarding) >> would somehow end up different? > > The discarding would be the same, but the mail that got discarded would be > different. Â In particular, from the point of view of my mail users, the > cost of losing a real notification from Paypal is low, since all the info > is on their web site, and the value of dropping an unsigned message is > high since it is (give or take Steve's numbers) likely to be a phish. > > For random domain X that is not a phish target and sends mail that is not > notifications, the cost of losing a real message is high, since it was > probably a message with real content, and the value of dropping an > unsigned message is low, since it's most likely a real message that got > its signature broken somehow. OK, there's a question right there worth fleshing out. Is ADSP's primary benefit only for domains used to send notifications? Certainly that's the source of my desire for the ability to utilize ADSP. So if that's the only stated value, and it's clearly stated that this is all that ADSP does, then I still like it. I still want it. In past discussions there had been an expressed concern that the number of domains/companies who send notifications and are phish targets is very low, but I would counter that it is not low at all. My employer has financial institutions of all sizes as clients, from the very small to the very large, and I certainly do observe phishing attempts of the smaller ones. For these situations, I want to be able to utilize ADSP, even knowing that it is not compatible with forwarding or mailing lists. Regards, Al Iverson ___ 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
> But I'd like to see if I understand the difference your are trying to > highlight between a manually maintained list and a self published > list. Manually, there is confidence in understanding the > ramifications. Self published (ADSP) there is no assurance in the > understanding of the ramifications. Therefore the data collected from > one method is not applicable to the other? The end result (discarding) > would somehow end up different? The discarding would be the same, but the mail that got discarded would be different. In particular, from the point of view of my mail users, the cost of losing a real notification from Paypal is low, since all the info is on their web site, and the value of dropping an unsigned message is high since it is (give or take Steve's numbers) likely to be a phish. For random domain X that is not a phish target and sends mail that is not notifications, the cost of losing a real message is high, since it was probably a message with real content, and the value of dropping an unsigned message is low, since it's most likely a real message that got its signature broken somehow. > John, is your manually maintained list done in co-operation with the > those in the list? To the extent that they are domains that I know are phish targets, send predominantly transactions, and have stated that they sign all their mail, yes. If you mean did I call them up and ask if I should put them in my drop list, no. 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 Fri, 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. > Strange, you replied to Brett's message showing the latter two hours before this message. But I'd like to see if I understand the difference your are trying to highlight between a manually maintained list and a self published list. Manually, there is confidence in understanding the ramifications. Self published (ADSP) there is no assurance in the understanding of the ramifications. Therefore the data collected from one method is not applicable to the other? The end result (discarding) would somehow end up different? John, is your manually maintained list done in co-operation with the those in the list? -- Jeff Macdonald Ayer, MA ___ 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 27/May/10 20:45, Douglas Otis wrote: > 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. Yes, perhaps a favicon would get more adoption than, say, "dkim=most" --which in turn would still be better than "unknown". This and the hypothesized MUA-hiding of unsigned "friendly from", that Mike mentioned, may increase DKIM's visibility, and possibly clarify how it works. I haven't found the rest of this discussion on ADSP overly constructive. If, as John said, domains publish inaccurate ADSP settings, it is the IETF's communication efficiency that has to be blamed --it's not an argument to favor private domains lists as an alternative. I agree ADSP currently leaves much to be desired. It deserves completion. (DKIM itself is in a similar situation, since it is still not MIME-compliant. A somewhat embarrassing circumstance for a protocol designed not to "break forwarding".) At any rate, let me note that besides countering phishing, ADSP plays a possibly more foundational role: it /characterizes/ DKIM signatures. Thus, there may be further *DSPs, e.g. * list signature, tied to the signed List-ID, * forwarder signature, tied to an SPF-validated 5321.mfrom. These characterizations integrate assessments. By qualifying the reasons why a given party signs a message, they give an insight into the mail transmission process, which may lead to the possibility of tuning it, e.g. by routing feedback appropriately. OTOH, unqualified signatures only entrust limited responsibility, as they don't say what questions the signer should be able to respond to. In this respect, an hypothetical reputation system that allowed to compute a message's worthiness up to 16 digits of precision, albeit useful, wouldn't differ much from spamassassin's fuzzy approach. I hope the WG will proceed and specify how LDSP should be, possibly leveraging any lesson that ADSP might have taught. ___ 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
Hi Brett, [feel free to follow up off-list] At 12:36 27-05-10, Brett McDowell wrote: >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. This is most likely unrelated to the discussion about the mailing list draft. You mentioned some numbers about ADSP lookups. Can you provide a breakdown (unique IP addresses, etc)? This question is framed incorrectly as I don't know about phishing attempts for your case and your infrastructure. Is there any correlation between phishing patterns and the lookups? What's the picture like when you take the top receivers out of the mix? What level of DKIM breakage are you seeing? Can you break it down by mail stream? What's it like when you are acting as receiver? Regards, -sm ___ 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:02 PM, Scott Kitterman 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. >> >> 2. If we want to reduce the DKIM broken signature rate, do we need to >> rework DKIM at all, or do we need to make operational recommendations to >> the generator and signer of the mail, or do we need to provide >> operational advice to forwarders and mailing list managers. 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. > ... > > I'm curious what level of reliability you think DKIM signatures have > currently? I just measured 72% broken in one case, and it's one that's not that atypical. It'll depend on the sort of mail you're talking about. For mail that's drafted carefully, and avoids doing anything (mime encoding, charsets) that might trigger MIME level rewrites during delivery, that's sent by a competent bulk mailer from well configured smarthosts directly to the MXes of a major consumer ISP I'd expect them to be extremely robust as measured at the MX. If your favorite use case of ADSP is bulk business-to-consumer mail sent from domains dedicated to sending solely that sort of mail, with no usage by employees, role accounts, customer support and so on then that's really good news. You'd need to start your email business unit pretty much from scratch to be able to do that, though. Also, I work with quite a lot of bulk mailers, and consistent operational competence of the level required is much rarer than you might hope. For mail that's being sent through any less well understood path there's risk of the mail being rewritten or lightly corrupted to an extent that it'll break the signature simply as part of SMTP forwarding. A common cause of this is mail being forwarded from a mail filtering appliance to an internal Exchange server. I've seen a bunch of obscure MIME rewriting and corruption issues in that case (our app used to express the same strong opinions at an ESMTP level that Exchange does, so I spent a long time tracking down a bunch of oddities there). I've no idea how widespread this sort of issue is, but I've seen problems that I think might cause this sort of issue at maybe 10% of my customers. For mail that's being sent through actual forwarders it's somewhat worse, as they're even more likely to annotate headers or body, modify headers or redraft MIME structure. Even "invisible" forwarding such as .forward files can break things when the mail is annotated by spam filters, then forwarded. All of the above can be mitigated somewhat by being very cautious both in generating mail content and by choosing which header not to sign, I'm sure. There there are mailing list managers - all bets are off, they tend to rewrite most everything and will break signatures more often than not. The only good point there is that the sender probably knows they're sending to a mailing list. > And are you measuring at a border MTA or somewhere later in > the delivery chain? I've been considering the state at the border MTA. I suspect it'll be a little worse later in the delivery chain, typically, but that's going to vary significantly based on the delivery path. I think there's going to be a large systemic component and a much smaller random component. And with that, I declare it the end of the week. Have a good slow Friday and Memorial day long weekend, everyone, if you're in a bit of the world that observes that. 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 5/27/10 9:01 PM, Steve Atkins wrote: > 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. > One objection to S/MIME was its poor presentation, where a failure as appearing to be phish is less tangible. S/MIME is also not compatible with provider practices of modifying presentations. In this case, the provider is expected to track its own brutal message handling, the motivation for Authentication-Results headers. Providers often consider themselves responsible for a user's impression of a message. Adding virtual icons, colored borders and the like can be effective strategies at combating phish, where presentation plays a critical role not compatible with S/MIME. > 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. > This conclusion overlooks the role message presentation plays. A role that represents a highly effective deterrent. > 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. > Where signatures are damaged beyond the provider's control is where attention is needed. This often represents third-party services. There are two possible approaches for handling these services. A) Have senders publish, in a scalable lightweight fashion, which third-party services are used. B) Depend upon recipient funded services that assess these services. Organizations most affected by fraud should be able to easily comply with A. In the case of public domains where fraud is less of an issue (ignoring successful ploys that leverage social networking) then B is needed. The third-party authorization scheme suggested can handle either approach. In the case of B, DNAME could vector to a consortium policing these services by publishing their own list of acceptable domains. These services will likely specialize on handling different regions. The suggested third-party authorization scheme attempts to include several qualifiers to further limit acceptance where possible, such as requiring LIST-ID, or authenticated Mail-From. It seems that this should be kept flexible, until it become unders
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
... > 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. > > 2. If we want to reduce the DKIM broken signature rate, do we need to > rework DKIM at all, or do we need to make operational recommendations to > the generator and signer of the mail, or do we need to provide > operational advice to forwarders and mailing list managers. 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. ... I'm curious what level of reliability you think DKIM signatures have currently? And are you measuring at a border MTA or somewhere later in the delivery chain? 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 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
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/dki
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 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
>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 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
On May 27, 2010, at 7:39 PM, Scott Kitterman wrote: > "Brett McDowell" 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
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
"Steve Atkins" wrote: > >On May 27, 2010, at 7:38 PM, Scott Kitterman wrote: > >> "Steve Atkins" 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:38 PM, Scott Kitterman wrote: > "Steve Atkins" 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
"Brett McDowell" 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
"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. > 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
> 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
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
(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, D&B 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 co
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: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
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 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, D&B 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 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 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 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? __
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
> 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. 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. 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. 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 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 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 Wed, May 26, 2010 at 11:28 PM, Steve Atkins 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] 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] 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] 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
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] 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
>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
