Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

From: Douglas Otis <[email-masked]>
Date: Sat, 01 May 2010 00:07:01 -0700

On 4/30/10 6:45 PM, John R. Levine wrote:
>> I don't think that's what I'm saying. Currently lists don't do much to
>> authenticate senders. I don't think it's implausible that a recipient might
>> have stricter rules than a list manager. It might be unusual, I suppose.
>>      
> I agree it's hypothetically possible, but have you ever seen an actual
> need for this in practice, a list where the recipients filter out messages
> that a more competently managed list would have rejected?
>    
John,

Efforts at protecting recipients with ADSP "all" or "discard-able" 
conflict with the message handling of properly run mailing-lists.  
Mailing-list handling does not need to change, even those that remove 
DKIM signatures.  With minor efforts, a transitional strategy that 
introduces sender authorization offers exceptions needed for "all" and 
"discard-able" conflicts.   The enhanced protection these policies 
afford is critical for financial institutions, whether for corporate or 
transactions messages.  Better source authentication is also 
increasingly needed to thwart a growing number of social engineering 
ploys, and to properly identify compromised accounts.  When 
mailing-lists include A-R headers, these can be audited by the sender.  
The sender's authorization then enables them to protect their 
authentication from otherwise trivial spoofing and to guard against 
message loss.

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 03 May 2010 11:02:18 +0100

On Fri, 30 Apr 2010 08:25:31 +0100, Douglas Otis <[email-masked]>  
wrote:

> On 4/29/10 6:06 PM, John Levine wrote:
>
>>  I just don't see how you can simultaneously say "throw away unsigned
>>  mail" and "don't throw away unsigned mail if a list says it used to
>>  be signed" unless you have some way to identify trustworthy lists.
>
> Agreed.  People might trust authentications of a From domain based upon
> valid Author Signatures, but they should not trust From domains based
> upon A-R header indications of previous Author Signatures without
> knowing how the A-R headers were processed.  Any assumption of proper
> processing would permit simple exploits and invite abuse.  Those most
> interested in determining proper A-R header processing by third-parties
> would be those with an interest in protecting their recipients, such as
> financial institutions.

Which is why A-R headers need to be signed by whoever created them Then at  
least you know where they came from and can adjust you policies  
accordingly.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 03 May 2010 11:06:55 +0100

On Fri, 30 Apr 2010 15:23:54 +0100, Michael Thomas <[email-masked]> wrote:

> On 04/30/2010 07:05 AM, McDowell, Brett wrote:

> Yeahbut... there are zillions of mailing lists out there. How do you  
> know the good ones
> from the bad ones? Keep in mind, of course, that bad guys can resign  
> too, and they can
> easily make themselves look like a mailing list if that's something that  
> gives them
> advantage.

Yes, but the fundamental property of mailing lists is that you sign up to  
them. So if you receive a message from a mailing list that you never  
subscribed to you (and the phisher in unlikely to know what you are  
subscribed to, except that you are certainly not subscribed to his bogus  
list) then you do not trust any signature created by that list manager.

Generally speaking, if you sign up to a list, you do so or a reason, and  
you have a pretty good idea of who is running the list and for what  
purpose.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 04 May 2010 10:07:24 +0100

--On 30 April 2010 15:33:51 -0600 "McDowell, Brett" <[email-masked]> 
wrote:

>
> Talking about the status quo is to talk about how every ISP/MBP (btw, is
> it common practice to refer to a "mailbox provider" as a MBP?)

I tend to use "ESP" - Email Service Provider.

>
> So the status quo is ugly at best.

Agreed.

> Is there any will in this group (aside from my own) to evolve the
> standards to improve the status quo?

There is here! As far as I'm concerned email is badly broken already.

> <soapbox>
> Are the rest of you as concerned about the damage fraud messaging can
> have to a user's computer, identity, and all systems on the Internet
> accessible from that computer?  I know I don't have to say this, but...
> this isn't just about stopping annoying ads for viagra.  And it isn't
> just about financial institutions' monetary losses due to account
> takeover attacks enabled by phishing.  It's about the trustworthiness of
> the Internet and addressing the A#1 channel criminals use today to
> undermine the integrity of this amazing infrastructure all of us have
> enjoyed and many of *you* have created. </soapbox>

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 04 May 2010 09:48:05 +0100

--On 30 April 2010 21:45:08 -0400 "John R. Levine" <[email-masked]> wrote:

>> authenticate senders. I don't think it's implausible that a recipient
>> might  have stricter rules than a list manager. It might be unusual, I
>> suppose.
>
> need for this in practice, a list where the recipients filter out
> messages that a more competently managed list would have rejected?

I've seen spam posted to mailing lists. Recently, I've seen lists targetted 
in more intelligent ways by spammers. For example, by using sender 
addresses in the domain of the list (quite a useful way of attacking 
academic lists, which tend to have lots of local users, but some non-local).

> R's,
> John

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 4 May 2010 10:17:36 -0400

> I tend to use "ESP" - Email Service Provider.

Oh dear, the industry I'm in would disagree with you. What would you
call a firm that sends out email for marketing/transactional purposes?

-- 
Jeff Macdonald
Ayer, MA

---

From: John Levine <[email-masked]>
Date: 4 May 2010 16:09:28 -0000

>academic lists, which tend to have lots of local users, but some non-local).

I believe it.  Are you saying the list managers make no effort to keep
the spam out of their lists?  Remember that every change to list
software that might be useful to let recipients identify spam that
leaks through a list could be used to keep the spam from leaking in
the first place.  Why go to extra effort to push the work out to the
subscribers?

Also, re your other discussion about list authentication, you're
right, we don't know what authentication lists do on their
contributors, but DKIM doesn't help there since DKIM most definitely
never says that the From: address is "real".  If you want strong
sender authentication, we already have S/MIME, and I wouldn't be
surprised if there were list software that could use it.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 05 May 2010 16:44:43 +0200

> I tend to use "ESP" - Email Service Provider.

I used to use ESP, but it may be confused with email marketing 
services. ISP may mean network provider. Mailbox provider is the 
less ambiguous term, IMHO.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 5 May 2010 12:01:16 -0600

> less ambiguous term, IMHO.

+1

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 07 May 2010 16:30:52 +0100

--On 4 May 2010 16:09:28 +0000 John Levine <[email-masked]> wrote:

>> I've seen spam posted to mailing lists. Recently, I've seen lists
>> targetted  in more intelligent ways by spammers. For example, by using
>> sender  addresses in the domain of the list (quite a useful way of
>> attacking  academic lists, which tend to have lots of local users, but
>> some non-local).
>
> the spam out of their lists?

No, but I don't think it's their job. As the site manager, that's my job in 
general. What the list managers can add is access controls, and 
authentication helps to improve the utility of such controls.

> Remember that every change to list

I'm not advocating extra effort to push the work out. I am advocating 
leaving in place information that recipients may (or may not) wish to use.

> never says that the From: address is "real".

"real"? A signature from the sender domain at least says that if it's not 
real, that's the responsibility of the sender domain owner, doesn't it? 
Then reputation services come into play. Which is where the answer to your 
first question comes in - the end recipient may have a very different view 
of the reputation of the sender than does the list. Or, it may wish to use 
the message content to modify its reputation score for the sender.

> If you want strong

---

From: "John R. Levine" <[email-masked]>
Date: 7 May 2010 13:07:34 -0400

> authentication helps to improve the utility of such controls.

Oh, we agree there, I wasn't distinguishing between the list and site 
manager, since at small sites they're often the same person.

> real, that's the responsibility of the sender domain owner, doesn't it?

No, all it says is "we signed this mail."  A signer with a good reputation 
will presumably rarely sign mail where the From: address actively 
misidentifies the sender, but that's a second order effect.

> the end recipient may have a very different view of the reputation of 
> the sender than does the list. Or, it may wish to use the message 
> content to modify its reputation score for the sender.

Once again, this sounds like a solution searching for a problem.  I've 
done the occasional bozofiltering in mailing lists, but because the people 
were bozos, not spammers.

>> If you want strong sender authentication, we already have S/MIME, and I 
>> wouldn't be surprised if there were list software that could use it.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 08 May 2010 01:41:55 +0100

Just a question/comment about these recent discussions.

Is there anything here that's not already noted in our
draft charter update that might be actionable and could
garner WG consensus?

I didn't see anything myself, but then there's been a
lot of mail so I may have missed something. If I've got
that wrong then please reply to this with your proposed
delta to the charter text Barry circulated earlier. (BTW,
I'll send that back to the list for a quick check in a
day or so before I forward it to Sean.)

Stephen.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 10 May 2010 13:03:43 +0100

--On 7 May 2010 13:07:34 -0400 "John R. Levine" <[email-masked]> wrote:

>> No, but I don't think it's their job. As the site manager, that's my job
>> in  general. What the list managers can add is access controls, and
>> "real"? A signature from the sender domain at least says that if it's
>> not  real, that's the responsibility of the sender domain owner, doesn't
>> it?
>
> No, all it says is "we signed this mail."  A signer with a good
> reputation will presumably rarely sign mail where the From: address
> actively misidentifies the sender, but that's a second order effect.

Right, and because the domain owner has signed the email, they can be held 
responsible for abuse. At least, to a greater extent than when the mail 
hasn't touched any system that they have any control over.

> done the occasional bozofiltering in mailing lists, but because the
> people were bozos, not spammers.

The problem is reputation assignment. Different recipients (of mail from 
the same list) will have different views of the sender's reputation.

But, the problem is real, and recognised. Mailing lists break signatures.

---

From: "John R. Levine" <[email-masked]>
Date: 10 May 2010 11:50:21 -0400

> hasn't touched any system that they have any control over.

It is certainly reasonable to say that the signer has a good reputation, 
so we will accept his mail.  But that's different from saying that the 
signer has a good reputation, so the From: address must be "real".

> The problem is reputation assignment. Different recipients (of mail from the 
> same list) will have different views of the sender's reputation.
>

It is certainly a fact that mailing lists break signatures.  But there are 
differences of opinion whether it's a problem.  Although I've seen plenty 
of assertions that it's a problem, we're a bit thin with real life as 
opposed to hypothetical scenarios where the broken signature leads to bad 
results.

The only one I've seen so far is the ADSP+list -> lost or rejected mail. 
I would say that is misuse of ADSP, not a list problem, since we were 
quite aware of it and in Appendix B of RFC 5617 we say not to do that.

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 10 May 2010 20:13:04 +0200

> opposed to hypothetical scenarios where the broken signature leads to bad 

Apart from ADSP rules, a broken signature must be treated as if there 
was no signature at all. That in itself is not the problem. The problem 
with broken signatures is that people will not buy into a technology 
(DKIM) if it will not cover a significant part of their e-mail. If the 
problem of MLM's breaking signatures can be eliminated, can be solved or 
(more likely) can be made smaller than it is now, this may lead to more 
willingness to adopt DKIM as basis for further steps (like reputation 
services). And the more DKIM is adopted and deployed, the more useful it 
becomes as basis for further developments.

/rolf

---

From: "John R. Levine" <[email-masked]>
Date: 10 May 2010 14:59:05 -0400

> Apart from ADSP rules, a broken signature must be treated as if there was no 
> signature at all. That in itself is not the problem. The problem with broken 
> signatures is that people will not buy into a technology (DKIM) if it will 
> not cover a significant part of their e-mail.

Of course.  That's why MLMs should sign their mail, or equvalently the MSA 
they use should sign it.  Problem solved, right?

Free bonus: MLMs can sign the list mail even if the contributor didn't 
sign it.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 10 May 2010 12:00:23 -0700

> misidentifies the sender, but that's a second order effect.

"misidentifies" covers quite a lot.

If I send mail from bbiw.net (well, actually, sbh17.songbird.com is my standard 
MSA) but label the From: field as being gmail.com, that's reasonable to classify 
as "misidentifying" the From: address, since songbird has nothing to do with gmail.

Operator-based signing is typically meaning that the message was posted by an 
authorized user.  There's absolutely no implication that the operator checked or 
enforced the contents of the From: field.

So, the "second order" effect you cite is probably much more indirect than that 
(third, fourth or fifth-order effect) and much narrower (abusive mislabeling, or 
somesuch).

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 10 May 2010 12:13:17 -0700

On 5/10/2010 11:13 AM, Rolf E. Sonneveld wrote:
>The problem
> (DKIM) if it will not cover a significant part of their e-mail.

They will not buy into a technology if its performance does not match their 
expectations.  That's a very different statement from yours.  It leads to focus 
on both expectations as well as performance. One of the problems, here, is with 
having expectations that do not match the goals and nature of the technology.

This is probably primarily due to believing that DKIM is saying something about 
the validity of the From: field, which it doesn't.

Another mismatch is believing that the absence of a DKIM signature means 
something, which it doesn't.

If the expectation is:  The presence of a valid DKIM signature, means that I 
have a reliable and accurate identifier I can feed into a reputation engine, 
then people will be happy to adopt it.

I've started doing a little experiment during DKIM presentations.  (Twice, so 
far, with another planned in June.

   1,  I ask the audience what they think DKIM does; a few responses are offered.

   2.  I then put up a slide that lists things people might often think that 
DKIM does.  So far, responses from the audience have been a strict subset of the 
list I put up.

   3.  I then tell the audience that only one item on the list accurately 
describes DKIM's function.

   4.  I then ask them to get which item it is.  They shout out some more 
guesses.  They are usually wrong.

Here's the list I've been using.  See if you know which item is correct and 
understand that all of the other items are /not/ what DKIM does:

      *  Means a message is not spam

      *  Guarantees delivery

      *  Puts a domain name on a message

      *  Validates a message

      *  Authenticates the author or origin of a message

      *  Authenticates the sender of a message

d/

-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 10 May 2010 15:43:38 -0400

> "misidentifies" covers quite a lot.

I used it to mean that the From: address doesn't have a reasonable 
connection to any of the persons or entities that composed the message, 
for some reasonable definition of reasonable.

> If I send mail from bbiw.net (well, actually, sbh17.songbird.com is my 
> standard MSA) but label the From: field as being gmail.com, that's reasonable 
> to classify as "misidentifying" the From: address, since songbird has nothing 
> to do with gmail.

No, that's not misidentification.  It may be something else, but we need 
more precise terminology, preferably that avoids loaded terms like 
"forgery".

> authorized user.  There's absolutely no implication that the operator checked 
> or enforced the contents of the From: field.

That entirely depends on what you know about the signer.  Two of the 
largest signers, Google and Yahoo, mechanically check that the user 
receives mail at the From: address.  One of the smallest, me, knows his 
users well enough to be confident that they won't do hostile address 
fakery even though I don't enforce anything mechanically beyond adding 
trace headers.  I have other opinions about other signers.

I'm realizing that a basic problem we have with explaining DKIM is that it 
makes semantic rather than operational assertions about messages. Since we 
are nerds, many of us deeply want to assign operational definitions, like 
"the people who know the passwords to the MTA that emitted this mail also 
know the passwords to the DNS server for the domain in the From: line", 
but they don't work, particularly for list mail in which the only 
operational definition of a good list is one where the recipients like 
what it sends.

So here's a scenario.  Let's say I run a political satire mailing list, to 
which members contribute wacky messages pretending to be from famous 
people like [email-masked] or [email-masked].  I use some technique 
not visible in the outgoing mail to ensure that the contributions are from 
list members (perhaps a password that's stripped out.)  Of course the list 
puts a shiny new DKIM signature on all its mail.  The list is triple 
opt-in with a cherry on top, and the subscribers await each list message 
all agog.  Filter that.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 10 May 2010 12:48:25 -0700

On 5/10/2010 12:43 PM, John R. Levine wrote:
>>> reputation
>> standard MSA) but label the From: field as being gmail.com, that's
>> reasonable to classify as "misidentifying" the From: address, since
>> songbird has nothing to do with gmail.
>

Your restricted model is entirely reasonable, but it does not match what many 
others in the community appear to mean.  Note the frequent (mis-) use of the 
word "forged".  So we need to be especially careful when introducing a 
pejorative label.  In particular, we need to be careful about the likely 
understanding of that label by readers.

>> Operator-based signing is typically meaning that the message was
>> posted by an authorized user. There's absolutely no implication that
>> the operator checked or enforced the contents of the From: field.
>

Requiring that verifiers know extensive details about the signing policies for 
all of the signatures they see doesn't scale.

> So here's a scenario. Let's say I run a political satire mailing list,
> to which members contribute wacky messages pretending to be from famous
> not visible in the outgoing mail to ensure that the contributions are
> from list members (perhaps a password that's stripped out.) Of course
> the list puts a shiny new DKIM signature on all its mail. The list is
> triple opt-in with a cherry on top, and the subscribers await each list
> message all agog. Filter that.

I wouldn't want to.  I /like/ that sort of mail...

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 10 May 2010 20:15:40 +0100

Agreed.

For those looking for some hybrid scheme, it should be noted SPF does 
not authenticate originating domains.  Domain reputation based upon SPF 
authorization is prone to exploitation, since many domains share common 
servers.  Ambiguities caused by shared IP address authorization makes it 
impractical to respond effectively by name.  In addition, 
Authentication-Results headers fail to capture the IP addresses of 
servers publicly issuing messages (over port 25) which also impairs IP 
address reputation checks of transactions handled by third-parties, such 
as mailing-lists.
> quite aware of it and in Appendix B of RFC 5617 we say not to do that.
The intended use of restrictive ADSP is to allow domains a means to 
limit acceptance of potentially misleading messages.   When is it okay 
for a trusted entity to permit acceptance of potentially misleading 
messages, and wouldn't use of additional domains lead to recipient 
confusion and invite more abuse?

Email reputation checks seldom reflect whether some From email addresses 
might be misused.  Use of DKIM in conjunction with a domain specific 
third-party authorization mechanism provides domains an effective means 
to better protect their recipients.  Lacking a domain specific 
third-party authorization scheme makes ADSP unsuitable for most 
domains.  Abuse is not limited to just transactional messages.  Being 
limited to transactional messages affords too little coverage to foster 
broad adoption.

-Doug

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 10 May 2010 15:56:24 -0400

Comments in-line at the risk of this getting overly long....

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John R. Levine
> Sent: Monday, May 10, 2010 3:44 PM
> To: [email-masked]
> Cc: DKIM List
> Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong
> Discussion
> 

That would be acceptable if you could avoid the use of the word
reasonable 3 times in a one sentence explanation of your intent.

> reasonable
> > to classify as "misidentifying" the From: address, since songbird
has
> nothing

We have been saying we need more precise terminology for years.....

> > Operator-based signing is typically meaning that the message was
posted
> by an
> > authorized user.  There's absolutely no implication that the
operator
> checked

Opinions of signers? This takes us dangerously into reputation territory
<G>.

> operational definition of a good list is one where the recipients like

The me part of we has looked deep into myself and found no such feelings
hiding in any nook or cranny.

> not visible in the outgoing mail to ensure that the contributions are
from
> opt-in with a cherry on top, and the subscribers await each list
message

Well, if one or more of your subscribers was at a domain that checks to
see if mail purporting to be from it actually came from one of it's
servers AND that domain was one of the spoofed emails ..... why yesiree
Bob, it would get filtered... but not on the basis of DKIM. I just love
hypothetical scenarios.....

If a DKIM signed message from the Moon to Jupiter is transported using
DTN.......

Mike

---

From: Steve Atkins <[email-masked]>
Date: Mon, 10 May 2010 12:09:28 -0700

> Free bonus: MLMs can sign the list mail even if the contributor didn't 

+1. It's pretty much a non-issue (unless you believe that DKIM is
magic fairy dust that will prevent all "fraudulent use of your brand").

It'd be nice if mailing lists didn't go out of their way to delete or
invalidate existing signatures, but if they happen to invalidate the
signature inbound it doesn't really break anything any sensible recipient
will be relying on, especially if the list signs all the mail it emits.

(I'd be much more concerned if the same issues cropped up with
end-user forwarding services, like acm.org, but they seem much
less likely to invalidate signatures than discussion lists.)

Cheers,
  Steve

---

From: Steve Atkins <[email-masked]>
Date: Tue, 25 May 2010 16:03:23 -0700

On May 25, 2010, at 3:38 PM, Brett McDowell wrote:

> On May 10, 2010, at 3:09 PM, Steve Atkins wrote:
> 
> I believe we can disagree without being disagreeable.  I'm sure there is no one on this list (or in the world) who thinks DKIM is magic fairy dust that will prevent all fraudulent use of a brand.

If ADSP is not there to prevent "fraudulent use of your brand", what
is it for?

While I don't think ADSP proponents actually believe it is magical brand
protection fairy dust, that is the operational model we're using when we're
discussing the usage of ADSP.

ADSP does not, and can not, provide significant operational value
in dealing with phishing, which is the only concrete example
anyone has brought forward. So we're left with "brand protection",
which is still plausible because it's so vague.

(If it were described as "Brand protection as applied to the section of
the byte sequence in the From: field that isn't the part usually displayed
to the end user" that would be less vague, but more obviously useless).

> I would like to think we are all on this list making a good faith effort to explore and debate the right way to deal with the status quo, including the option of sustaining it.  I personally don't agree with the position that the status quo should be sustained, but I respect both that position and those who articulate it.

Yes, this summary may be blunt and possibly even disagreeable, but
there comes a point when developing something that's going to affect
many, many people that you have to mention the elephant in the room -
which is that while lots of people involved have invested quite a bit of effort
and professional credibility in putting it together there's still no definition
of what problem it's supposed to solve, and the end result appears to
be pretty much useless for any concrete phishing or brand protection
scenario.

Cheers,
  Steve

---

From: Brett McDowell <[email-masked]>
Date: Tue, 25 May 2010 18:38:31 -0400

FWIW,

-- Brett

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 26 May 2010 12:42:52 +0100

> If ADSP is not there to prevent "fraudulent use of your brand", what

The problem is with the word "prevent". At best ADSP can mitigate the risk.

It says nothing about what a competitor might print on a packet of 
cornflakes, for example!

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 26 May 2010 09:22:32 -0400

> [email-masked]] On Behalf Of Steve Atkins
> Sent: Tuesday, May 25, 2010 7:03 PM
> To: DKIM List
> was no
> >>>> signature at all. That in itself is not the problem. The problem
with
> broken
> >>>> signatures is that people will not buy into a technology (DKIM)
if it
> will
> >>> Of course.  That's why MLMs should sign their mail, or equvalently
the
> MSA
> > I believe we can disagree without being disagreeable.  I'm sure
there is
> no one on this list (or in the world) who thinks DKIM is magic fairy
dust
> that will prevent all fraudulent use of a brand.
> 

A most pithy question deserving of an answer. ADSP does not "prevent
fraudulent use of your brand". Never has and never will. What it is
intended to prevent is "fraudulent use of your domain" that may or may
not be a brand. It is a specific tool targeted at a narrow problem.
Nothing more and nothing less. It does not prevent abuse of the display
name nor does it prevent the use of cousin domains as just two examples
of the many things it does not do. It is a point solution to a point
problem.

> discussing the usage of ADSP.

Have to disagree with you here Steve. It's not magical and as I pointed
out above, it is not strictly speaking "brand protection".

> which is still plausible because it's so vague.

The only reason that ADSP does not provide significant operational
benefits is that for the sake of compromise it was crippled at birth.
Speaking based on the experience of DKIM signing all mail for some
heavily abused domains since 2007, there is value that can be leveraged
in conjunction with other tools as part of an overall anti-abuse
program. 

> to the end user" that would be less vague, but more obviously
useless).

There is a very simple solution I have suggested in the past that can
and will likely be implemented once email authentication reaches a
critical mass. That is for MUAs to set the default implementation to NOT
display the display name if the mail is unauthenticated.

I would hope that the long term goal is to reduce the attack surface
available to abusers.
> 
> 
> > I would like to think we are all on this list making a good faith
effort
> to explore and debate the right way to deal with the status quo,
including
> the option of sustaining it.  I personally don't agree with the
position
> that the status quo should be sustained, but I respect both that
position
> and those who articulate it.
> 
> 
> which is that while lots of people involved have invested quite a bit
of
> effort

As I commented above, the only reason that ADSP as written appears to be
of little potential value is that it was intentionally made so. Consider
that one of the authors has pretty much always argued against its
usefulness and value. 

The ability to make assertions about a sending domains mail streams has
a proven track record in private peering arrangements between some
(large/well known) senders and receivers. There is clear potential value
to enabling an open and automated way of expressing these assertions
such that both sides of the equation (sending domain and receiving
domain) are able to scale. That we have failed to do so with the current
incarnation of ADSP does not change this.

Mike

---

From: Brett McDowell <[email-masked]>
Date: Wed, 26 May 2010 10:28:38 -0400

> If ADSP is not there to prevent "fraudulent use of your brand", what

To protect users from a type of crime (phishing) perpetrated in a particular channel (email).  It's not about protecting our brand.  It's about protecting our customers.

> in dealing with phishing,

Ummm... PayPal+Google+Yahoo have collectively blocked well over 100 million phishing attacks using DKIM+ADSP=discardable (if you include the out-of-band equivalent to ADSP=discardable that we had to put in place while we waited for a standard, that we now fully support and deploy).

> which is the only concrete example

Problem = phishing
Utility = just one sender + two mailbox providers have blocked over 100 million phishing attacks, many of those blocks also resulted in site take-downs.

The value of what we already have from your efforts in IETF is HUGE for consumer protection.  It could be even more useful with the kind of tweaks I've suggested for MLM's... and probably a few more flags/states for ADSP.

-- Brett

---

From: Brett McDowell <[email-masked]>
Date: Wed, 26 May 2010 10:33:59 -0400

+1

My favorite line from Mike's email is "there is value that can be leveraged in conjunction with other tools as part of an overall anti-abuse
program. "

An example of how this fits into an overall strategy is captured in a white paper PayPal published in 2008:

https://www.thepaypalblog.com/2008/04/a-practical-app/

(the link to the paper is in the last paragraph of that blog post)

-- Brett

---

From: John Levine <[email-masked]>
Date: 26 May 2010 15:55:14 -0000

>Problem = phishing
>Utility = just one sender + two mailbox providers have blocked over
>100 million phishing attacks, many of those blocks also resulted in
>site take-downs.

>The value of what we already have from your efforts in IETF is HUGE
 for consumer protection.

I believe this is a big win for DKIM, which I hope we can tell the world
about.

It has NOTHING WHATSOEVER to do with ADSP, since the two mailbox
providers are (quite reasonably) treating paypal and ebay as a special
case.

>It could be even more useful with the kind of tweaks I've suggested
>for MLM's... and probably a few more flags/states for ADSP.

We've gone around enough times why this would be bad for Paypal and
bad for everyone else, so I'll stop now.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 May 2010 09:10:06 -0700

> providers are (quite reasonably) treating paypal and ebay as a special

NOTHING WHATSOEVER is vast overstatement; ADSP makes the "special case" unnecessary,
so there aren't an unmanageable number of "special cases".

And do you know for a fact that they are a "special case" still?

Mike

---

From: Brett McDowell <[email-masked]>
Date: Wed, 26 May 2010 12:14:43 -0400

I respectfully disagree with you.  

We *were* a special case.  Soon we will not be a special case because ADSP will enable all mailbox providers, if they choose, to do for others what they have historically done for us.  That's the big win that only ADSP could ever enable.

Apparently such an announcement is going to come as a surprise to many of you on this list, but it shouldn't.  It's the logical conclusion of the ADSP work.

-- Brett

---

From: "John R. Levine" <[email-masked]>
Date: 26 May 2010 12:46:56 -0400

> We *were* a special case.  Soon we will not be a special case because 
> ADSP will enable all mailbox providers, if they choose, to do for others 
> what they have historically done for us.

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.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 09:58:29 -0700

> Apparently such an announcement is going to come as a surprise to many of you on this list, but it shouldn't.  It's the logical conclusion of the ADSP work.

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"

Cheers,
 Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 May 2010 10:11:09 -0700

>     _adsp._domainkey.paypal.com descriptive text "dkim=discardable"

Huh? What does that have to do with anything? John is wrong: ADSP allows them to
get rid of the "special case" handling by Y! and G. This is hardly controversial.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 10:13:18 -0700

> get rid of the "special case" handling by Y! and G. This is hardly controversial.

Could you expand on why you think that?

Cheers,
  Steve

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 10:42:09 -0700

> Could you expand on why you think that?

Michael claims off-list that he has no idea what I'm speaking of.

So, to be more specific, I'm implicitly asking two things.

    1. Should those domains be treated differently by the recipient ISP?

    2. How does ADSP help them make that decision?

There's probably a third followup question if the answer to "2" involves maintaining a list of domains, but that can wait.

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 May 2010 10:57:15 -0700

> There's probably a third followup question if the answer to "2" involves maintaining a list of domains, but that can wait.

Oops, I didn't mean those to be off-list... don't know how that happened. Given where this
is going, that may have been a blessing missed.

I really don't understand what the look-alike domain name has to do with anything. It's
well understood that ADSP doesn't claim to help that. But for bit-for-bit copies of the
discardable domain's name, Brett is right: ADSP allows his "special case" arrangement
with G and Y! to scale to anybody who might want to have the same "agreement". I don't
see why this is controversial.

Mike

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 26 May 2010 14:04:42 -0400

> Michael claims off-list that he has no idea what I'm speaking of.

I said "huh?" too.

>    1. Should those domains be treated differently by the recipient ISP?

perhaps the question is "are those two different entities?" I'd say as
far as the recipient ISP can tell, yes.

>    2. How does ADSP help them make that decision?

It doesn't,  nor do I think it claims to.

-- 
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 May 2010 11:20:28 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Wednesday, May 26, 2010 9:47 AM
> To: Brett McDowell
> Cc: [email-masked]

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.

You don't have to participate in the thought process if you find it irritating or repetitive, but please don't try to stop others, especially new people, that may want or need to go through it.  You never know, they might have something new and valuable to offer.  Or you could swing them around to your view, which builds consensus and only benefits you.

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.  

If you find it annoying, please just ignore or filter it.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 11:30:40 -0700

>> Michael claims off-list that he has no idea what I'm speaking of.

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.

If there's something else it's intended to address I'm all ears.

> far as the recipient ISP can tell, yes.

No, that's a very different question. A good one, but one that's
easier to answer.

Should mail from the two domains be treated differently? Delivered
or not delivered to the user, displayed differently to the user? That's
the only thing that has any effect on the issue of phishing in general.

> It doesn't,  nor do I think it claims to.

I agree, but that leads to the question as to what operationally
useful decision it can help with. Paypal claim it'll be a big win of
some sort once they're no longer treated as a special case,
rather just the same as every other domain.

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 May 2010 11:48:53 -0700

> is phishing or brand protection, as they're the only concrete problems

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.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 12:02:58 -0700

On May 26, 2010, at 11:48 AM, Michael Thomas wrote:

> charter.

I don't believe I am.

> ADSP doesn't claim to solve "phishing", it just allows bit-for-bit

We can't usefully discuss things like best practices or a revision of
the spec without some sort of concrete operational use case.

The only operational experience I've seen discussed so far is entirely
negative - it causes mail from mailing lists to be lost and leads to
recipients being unsubscribed from those lists.

We really need to come up with some positive operational experience,
or at least a theoretical situation where some may occur, before we
can talk about either best practices for using it or modifying the spec in
order to avoid the observed problems.

Paypal is claiming an operational benefit, but haven't actually
demonstrated that ADSP either provides that benefit, nor that
those benefits can't be provided in a significantly cheaper manner.

So we're left with a protocol that doesn't appear to be terribly
useful for any particular use case, and which is demonstrably
broken when used with mailing lists.

This thread started with the observation that ADSP was broken
w.r.t. mailing lists, and discussion of how the spec might be
changed such that it wasn't broken in that respect, yet would
still be effective for it's main purpose. We also have tangents
on how it should be deployed in practice ("What does 'discardable'
mean? Does it mean you should reject mail instead of discarding
it?")

And that leads to... what is the intended main purpose? Without
that, there's no way to decide whether the suggested changes
will improve things, or simply cause it to be more broken (via
increased complexity leading to reduced usage or incorrect
usage, for example), nor to provide appropriate advice on
deployment (other than "Don't, yet.").

Cheers,
  Steve

---

From: Barry Leiba <[email-masked]>
Date: Wed, 26 May 2010 15:45:40 -0400

<<Chair Interrupt>>

I want to shut off one aspect of this discussion, because it's wasting
time, making us go around in circles, and causing a lot of
misunderstanding.

The aspect that I'm shutting off is any variation on the idea that
because phishing succeeds despite any blocks on a particular domain
name (using look-alikes and other funny domain-name tricks),
protecting a domain name (for whatever value of "protecting" we want
to talk about) does not affect the ability to phish, and therefore is
not useful.

This working group has consensus that it IS useful to "protect" a
domain name.  That consensus is well established, and has been much
discussed.  Further discussion of that question is out of scope.
Let's please stop wasting time and effort on it.

We all agree that making it harder for someone to send mail with
"[email-masked]" in the "from" line does not stop phishing
attacks that fool recipients into thinking that the mail comes from
PayPal.  Nevertheless, we have rough consensus that it is useful to
make it harder for senders who are not PayPal to send mail with
"[email-masked]" in the "from" line.

-----

I'll also add that the chairs have the job of declaring consensus, of
declaring an issue resolved, and of declaring discussion closed.  I
ask that people avoid being dismissive in their responses, but I also
remind others that a dismissive response from a participant does not
enjoin anyone from continuing discussion.

Carry on.

-- Barry, as chair.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 13:11:57 -0700

> "[email-masked]" in the "from" line.

There's apparently a lot of disagreement, even within the active
participants of this mailing list, as to what ADSP does do.

As one specific example I do not believe there is consensus on
what threat ADSP is intended to thwart, and without that I don't
believe that it's possible to discuss how to deploy it or how to
modify it.

As an example - there is a suggestion that ADSP be weakened
such that it allows for unsigned mail sent through a mailing
list. It's not possible to judge whether that will terminally
weaken the protections offered by ADSP without knowing what
the threat it's intended to defend against is.

If the sole benefit to ADSP is to "protect the domain name
as used in the non-displayed part of the From: field" then
weakening it to allow unsigned mail through mailing lists
in the way suggested would break ADSP completely. OTOH,
if the real goal is to help with phishing attacks against domains
that are used solely to send B2C junk mail then there's a
fairly strong argument that mailing lists aren't a likely conduit
for phishing attacks against B2C bulk mailer targets.

If the chairs assert there is a consensus on what that threat
is, I'd appreciate it if they can state that with a couple of
concrete examples.

If there is not consensus on that, then I don't see how the
conversation about fixing the obviously broken bits of ADSP
or working on good deployment practices can usefully continue.

Cheers,
  Steve

---

From: Brett McDowell <[email-masked]>
Date: Wed, 26 May 2010 15:46:45 -0400

> those benefits can't be provided in a significantly cheaper manner.

I thought I had. Remember that business about 100 million phishing attacks being blocked (DKIM alone would not have delivered that... it was our policy assertion and the acceptance to act on that policy assertion that made this happen)?  

What do I need to show you guys before you accept that I have demonstrated that ADSP provides operational benefit?

---

From: Brett McDowell <[email-masked]>
Date: Wed, 26 May 2010 15:51:33 -0400

>>>>  _adsp._domainkey.paypal.com descriptive text "dkim=discardable"

I would like to answer your question... but I can't grok it from these two ADSP look-ups.  Are you asking about what we do if someone other than ourselves registers a cousin domain?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 14:00:54 -0700

> 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 p…

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.

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.

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.

> 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, and we will respond with the other ...". 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.

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.

(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).

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.

Cheers,
  Steve

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 20:28:17 -0700

On May 26, 2010, at 8:16 PM, Patrick Peterson wrote:

> 
> On May 26, 2010, at 12:02 PM, Steve Atkins wrote:
> 
>> 
>> <snip>
> ADSP as defined in RFC 5617 is the best place I know of to define ADSP's main purpose, namely: to enable senders to advertise policies related to how they would like unsigned messages to be handled and to aid receivers in assessing unsigned messages from such senders.

> 5617 excerpts include:
> "DomainKeys Identified Mail (DKIM) defines a domain-level
>   authentication framework for email to permit verification of the
>   source and contents of messages.  This document specifies an adjunct
>   mechanism to aid in assessing messages that do not contain a DKIM
>   signature for the domain used in the author's address.  It defines a
>   record that can advertise whether a domain signs its outgoing mail as
>   well as how other hosts can access that record."
> 
> "the legacy of the Internet is such that not all messages
>   will be signed, and the absence of a signature on a message is not an
>   a priori indication of forgery.  In fact, during early phases of
>   deployment, it is very likely that most messages will remain
>   unsigned.  However, some domains might decide to sign all of their
>   outgoing mail, for example, to protect their brand names.  It might
>   be desirable for such domains to be able to advertise that fact to
>   other hosts.  This is the topic of Author Domain Signing Practices
>   (ADSP).
> 
> Perhaps you believe this purpose to be unclear, wrong or, perhaps, simply wonderful. But I think the purpose stated in 5617 is a good place to start.

That describes the mechanics of what ADSP is currently defined to do, that's
all. It says nothing about *why*, other than "protect their brand names",
which is both ill-defined and something ADSP simply cannot do.

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...

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. 

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.

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.

Cheers,
  Steve

---

From: SM <[email-masked]>
Date: Wed, 26 May 2010 21:24:17 -0700

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.

Regards,
-sm

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 22:25:27 -0700

> 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

---

From: John Levine <[email-masked]>
Date: 27 May 2010 06:05:32 -0000

>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.

---

From: John Levine <[email-masked]>
Date: 27 May 2010 06:19:12 -0000

>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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 May 2010 02:55:58 -0700

> 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
> 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.
> won't help with phishing, the fact that it won't help with phishing isn't
ADSP alone does not afford complete protection.  No one has said 
otherwise.  ADSP needs extended.
> 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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 May 2010 06:08:37 -0700

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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 27 May 2010 10:05:58 -0400

> 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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 May 2010 07:39:46 -0700

> "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

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 27 May 2010 10:53:15 -0400

> 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.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 May 2010 11:45:41 -0700

On 5/27/10 7:53 AM, Jeff Macdonald wrote:
> 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,
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

---

From: Brett McDowell <[email-masked]>
Date: Thu, 27 May 2010 15:15:49 -0400

On May 27, 2010, at 10:39 AM, Michael Thomas wrote:

> 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

---

From: Brett McDowell <[email-masked]>
Date: Thu, 27 May 2010 15:30:43 -0400

On May 27, 2010, at 10:05 AM, Barry Leiba wrote:

> 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
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.

> before, fooling just as many recipients into thinking they're from

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.

> "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.

---

From: Brett McDowell <[email-masked]>
Date: Thu, 27 May 2010 15:36:35 -0400

> I'd be interested in seeing Brett's data and methodology too.

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)

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 27 May 2010 12:41:29 -0700

> 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

---

From: Brett McDowell <[email-masked]>
Date: Thu, 27 May 2010 15:46:56 -0400

> hard to discuss whether there's a better solution. 

Are you deliberately ignoring the data I provided... at your request for data?

> 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!

---

From: Brett McDowell <[email-masked]>
Date: Thu, 27 May 2010 16:04:44 -0400

> 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 s…

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 batt…

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. 

> 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 certificatio…

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. Som…

Any proposals?

---

From: Brett McDowell <[email-masked]>
Date: Thu, 27 May 2010 16:30:09 -0400

> correctness of your position, but we do not have access to the data to make an

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.  

> to make the defender (or attacker) feel superior while nonetheless failing to 

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.

> 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.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 27 May 2010 13:59:23 -0700

On 5/27/2010 1:30 PM, Brett McDowell 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.

>> 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, ummmm, challenging.  A 
perfect storm, of a sort...

>> 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

---

From: Steve Atkins <[email-masked]>
Date: Thu, 27 May 2010 14:22:42 -0700

> 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.

> 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 ex…

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.

---

From: Brett McDowell <[email-masked]>
Date: Thu, 27 May 2010 17:43:44 -0400

On May 27, 2010, at 2:05 AM, John Levine wrote:

> 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

---

From: Steve Atkins <[email-masked]>
Date: Thu, 27 May 2010 14:57:06 -0700

> Phishing emails using "paypal" in the From line:

That should be

>    61% not rejected.

Cheers,
 Steve

---

From: Brett McDowell <[email-masked]>
Date: Thu, 27 May 2010 19:06:34 -0400

I must have missed an email or something... what's the context for and/or source of this data?

---

From: Brett McDowell <[email-masked]>
Date: Thu, 27 May 2010 19:14:12 -0400

(disregard previous, I did miss this message Steve... I have the context now... a few comments below)

> 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.

> to be fixed or it needs to be allowed to die.

I vote for "fix".

> and effective and easy for consumers to understand.

Yes, wee support EV Certs too... defense in depth.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 May 2010 16:19:33 -0700

>> >  to be fixed or it needs to be allowed to die.
In agreement with both Steve and Brett. :^)

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 May 2010 16:19:33 -0700

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 27 May 2010 21:57:54 -0400

> 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 thi…

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, [email-masked], 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

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 27 May 2010 21:03:44 -0700

> 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.

> Phishing emails using "paypal" in the From line:

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.

> 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

---

From: John Levine <[email-masked]>
Date: 28 May 2010 04:14:10 -0000

>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

---

From: John Levine <[email-masked]>
Date: 28 May 2010 04:15:54 -0000

>before, fooling just as many recipients into thinking they're from

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

---

From: Steve Atkins <[email-masked]>
Date: Thu, 27 May 2010 21:28:45 -0700

> ADSP understands what it means.  Recent experience suggests that they

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

---

From: Steve Atkins <[email-masked]>
Date: Thu, 27 May 2010 22:08:04 -0700

> 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).

>> Legitimate email from paypal:

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:

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.

> 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.

+1

Cheers,
 Steve

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 May 2010 22:34:40 -0700

> 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

---

From: SM <[email-masked]>
Date: Fri, 28 May 2010 00:48:37 -0700

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

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 28 May 2010 18:24:59 +0200

On 27/May/10 20:45, Douglas Otis wrote:
> 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

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 28 May 2010 15:07:27 -0400

> 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?

---

From: "John R. Levine" <[email-masked]>
Date: 28 May 2010 15:32:16 -0400

> 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

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

---

From: Al Iverson <[email-masked]>
Date: Fri, 28 May 2010 14:59:25 -0500

> 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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 May 2010 13:23:55 -0700

> 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.
> a possibly more foundational role: it/characterizes/  DKIM signatures.
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.
> 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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 28 May 2010 13:26:28 -0700

On 5/28/2010 12:07 PM, Jeff Macdonald wrote:
> 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
> understanding of the ramifications.

Right.  That's true, as well as the difference in the basis for the entry.

> Therefore the data collected from

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

---

From: John Levine <[email-masked]>
Date: 28 May 2010 20:34:43 -0000

>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

---

From: Al Iverson <[email-masked]>
Date: Fri, 28 May 2010 16:09:26 -0500

> 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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 May 2010 14:24:17 -0700

On 5/28/10 2:09 PM, Al Iverson wrote:
> On Fri, May 28, 2010 at 3:34 PM, John Levine<[email-masked]>  wrote:
>    
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

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 28 May 2010 23:24:46 +0200

> 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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 May 2010 19:01:21 -0700

> 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