Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 25 Jul 2010 02:36:17 -0700

(More review of old chatter...)

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of J.D. Falk
> Sent: Tuesday, June 22, 2010 11:07 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-
> 00 (fwd)
> 
> > I still don't get why it's ok for John Levine to publish a list which
> > says that it's ok to discard unsigned mail from paypal.com, but st00pid
> > for paypal.com to publish the same thing. That is the essence of his
> > jihad against adsp.
> 
> Because presumably verifiers will trust John's process for compiling
> this list more than they'd trust any random schmoe with the ability to
> create TXT records.
> 
> (If paypal were representative of all domains, this wouldn't be a
> concern.)
> 
> Personally, I think we'll need lists like this for a while in order to
> gain more experience and determine best practices, and THEN we can
> decide whether to change (or even scrap) ADSP to reflect those
> practices.

I've engaged some of you off-list trying to understand why ADSP is fundamentally different than the private agreements known to exist between PayPal and some large email service providers.  I get the philosophical arguments, but from a standards body perspective I remain stymied.

I'm finally beginning to buy that something akin to DBR may be necessary, but it's still weird to me that the point is that the average sysadmin can't be trusted to do ADSP right.  But then why, for example, can he/she be trusted to do DNS or SMTP or even TCP/IP right without some sort of vouching or reference service asserting competence?

The whole point of standards is to publish a mechanism for accomplishing something so that two parties that have never interacted in that specific way before can do so without some kind of out-of-band prior arrangement.  In that sense these statements about ADSP create some cognitive dissonance that I haven't been able to resolve yet.

-MSK

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

---

From: John Levine <[email-masked]>
Date: 25 Jul 2010 15:48:51 -0000

>I'm finally beginning to buy that something akin to DBR may be
>necessary, but it's still weird to me that the point is that the
>average sysadmin can't be trusted to do ADSP right.  But then why,
>for example, can he/she be trusted to do DNS or SMTP or even TCP/IP
>right without some sort of vouching or reference service asserting
>competence?

It's a perfectly reasonable question.  To me, the problem with ADSP is
that if we imagine the process of delivering a message to be a running
race, ADSP is a gun pointed at your foot offered to you at the finish
line.

As we all know, admins can and do screw up anything, but with most
mistakes, the damage directly affects them.  If you screw up your MX,
your own incoming mail won't work.  If you screw up your ADSP, your
mail will work fine, while other people's mail systems will
mysteriously lose mail.

Experience with SPF -all suggests that people who get it wrong will
insist that it's somenoe else's problem to fix, by baroque workarounds
like SRS and recent proposals to intuit that a message with a broken
signature is coming through a legitimate mailing list and that the
list verified the signature. Also, regardless of what the spec says,
few recipients would ever use it as anything more than a mild hint to
a scoring system.

Standards work well when the benefit from implementing them correctly
is shared, and the pain of screwing up is also shared.  ADSP offers
trivial benefits to the vast majority of domains that are not phishing
targets and to the recipients of mail from them, and pain that
predominantly falls on the other end from the one that screwed up.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 26 Jul 2010 10:50:04 +0200

On 7/25/10 5:48 PM, John Levine wrote:
> > for example, can he/she be trusted to do DNS or SMTP or even
> > TCP/IP right without some sort of vouching or reference service
> > asserting competence?
>
>  It's a perfectly reasonable question.  To me, the problem with ADSP
>  is that if we imagine the process of delivering a message to be a
>  running race, ADSP is a gun pointed at your foot offered to you at
>  the finish line.
>
>  mistakes, the damage directly affects them.  If you screw up your
>  MX, your own incoming mail won't work.  If you screw up your ADSP,
>  your mail will work fine, while other people's mail systems will
>  mysteriously lose mail.

For domains targeted in phishing attacks, ADSP allows system admins to 
do it "right" only when no informal third-party service is ever used.  
These informal services, such as mailing-lists, are not suitable for 
transparent authorization, and result in message loss when the 
"discardable" assertion is made.  When "all" is made, results are not 
actionable due to uncertainty from possible informal service use.  
Unfortunately, the remedy recommended for informal services is to deploy 
unprotected subdomains.  This is clearly the "wrong" thing when 
attempting to mitigate phishing.  Such a tactic invites more phishing 
and more victims amidst increased confusion.

A reputation or vouching service will be unable to properly determine a 
domain's signing compliance, and whether informal third-party services 
are ever used.  Without a simple relationship assertion between targeted 
domains and informal third-party services being supported,  reputation 
or vouching will also remain problematic, where just blame being 
redirected.  Any recommendation from vouching or reputation services 
would be "ready-fire-aim" with system-admin's feet still suffering, but 
now beyond their control, while phishing continues unabated.

The number of domains being phished takes the problem beyond the realm 
of any effective manual response.  A scheme that allows informal 
third-party services, only after confirmation of a header field,  allows 
recipients a proactive means to recognize different message sources.  
There is an article discussing this at:

http://us.trendmicro.com/imperia/md/content/us/trendwatch/researchandanalysis/64_avoiding_the_whack-a-mole_anti-phishing_strategy__july_22__2010_.pdf

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Jul 2010 07:51:30 -0700

> mail will work fine, while other people's mail systems will

This is such a bizarre take. If my web server starts putting out 500
internal errors because of misconfiguration, the clients "lose" their
http content too. That most certainly directly affects my http server
just like it does mail: I'm not putting those servers out on the net
for giggles, it's because I *want* my content to be distributed.
So the argument that there is not fate sharing is bogus on its face.

If mail operators can't be bothered to configure mail correctly, it's
their problem. They shouldn't be mollycoddled because that just encourages
more bad behavior.

Mike

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 26 Jul 2010 18:24:34 +0200

> The whole point of standards is to publish a mechanism for accomplishing something so that two parties that have never interacted in that specific way before can do so without some kind of out-of-b…

I think it's because, when you implement most protocols, if your end is broken then you can't even talk to the other end.  With ADSP, if your end is broken then you can still talk SMTP and even sign with DKIM, but the other end may silently discard your message.  There's no feedback.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 26 Jul 2010 21:13:10 +0200

> I think it's because, when you implement most protocols, if your end is broken then you can't even talk to the other end.  With ADSP, if your end is broken then you can still talk SMTP and even sig…
It's not lack of feedback causing unsubscribes on mailing lists.  Don't 
blame sysadmin for these problems.  ADSP, as currently defined, is 
unable to accommodate informal third-party services when attempting to 
offer protection from phishing.  Rather than adhering to the "practice" 
aspect of ADSP assertions, ADSP's "discardable" changed this into advice 
on message handling, analogous to the "-all" of spf.  Avoiding use of 
subdomains avoids confusing recipients recognition of the trusted 
domain, where use of unprotected subdomains just shifts the phishing 
problem.  There is no getting this right.

A vouching service is unlikely to offer a fix either.  How would a 
vouching service know better than the Author Domain?  I would not want 
to be on the hook when getting this wrong. It would be better to allow 
senders the latitude for getting this right, and making their own 
explicit determinations.  We have the technology. :^)

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Jul 2010 17:06:43 -0700

> I think it's because, when you implement most protocols, if your end is broken then you can't even talk to the other end.  With ADSP, if your end is broken then you can still talk SMTP and even sig…

But that's basically true of the entire mail system these days. It's also why
getting ARF/FBL's widespread would be a generally Good Thing. ADSP doesn't
really change anything one way or the other.

Mike

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 27 Jul 2010 09:36:45 +0200

On Jul 26, 2010, at 9:13 PM, Douglas Otis wrote:

> vouching service know better than the Author Domain?

They wouldn't, so a smart vouching service would be working WITH the author domain to get it right.  But that's a business decision, not a protocol decision.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Jul 2010 10:33:04 +0200

On 7/27/10 9:36 AM, J.D. Falk wrote:
>  They wouldn't, so a smart vouching service would be working WITH the
>  author domain to get it right.  But that's a business decision, not a
>  protocol decision.

J.D.

Companies are good at shooting themselves in the foot in respect to 
helping bad actors phish. (blush)  The other foot injury involves their 
email being rejected or discarded.  Unfortunately, these two goals are 
in conflict when making ADSP assertions.  Unless the targeted 
organizations or institutions forgo all informal third-party services, 
such as mailing-lists, it is not possible to get ADSP right.  
Ironically, following recommendations being proposed for mailing-lists 
is likely to make phishing worse.

These conflicts are not resolved by adding another layer of management 
unless the question being asked is extended with respect to messages 
lacking Author Domain signatures. The considerations should not be what 
is easy for senders, but whether excluding phishing is easy for recipients.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 27 Jul 2010 16:14:47 +0200

> is likely to make phishing worse.

Mailing lists are a separate issue.  I don't think it's helpful for a 3rd party to vouch that lists are lists, and that's not what John's draft does.

---

From: John Levine <[email-masked]>
Date: 27 Jul 2010 15:35:12 -0000

>Mailing lists are a separate issue.  I don't think it's helpful for a
>3rd party to vouch that lists are lists, and that's not what John's
>draft does.

The goal of my draft was to provide a way publish lists of domains for
which there is a net benefit to the recipient from dropping unsigned
mail.  I believe this is what people want from ADSP, but it can't
provide for reasons we needn't rehash.

I do think there could be benefits from identifying categories of
senders, e.g., this is a bank, this is a government, and maybe this is
a discussion list.  It's pretty obvious how you could add them to VBR,
but that's not what I did here.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Jul 2010 11:28:09 +0200

> provide for reasons we needn't rehash.
Rather than the Author Domain making an ADSP assertion, the Author 
Domain instead subscribes to a vouching service where ADSP is therefore 
ignored or over ruled?  Does this mean Author Domains are unwilling to 
publish "discardable", whereas a vouching service would be?

Why is a vouching service in a better position to make a decision that 
are in conflict with what the Author Domain would have or has 
published?  What makes this a hard decision?  It seems this will result 
in denying use of any informal third-party service.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 28 Jul 2010 07:28:20 -0400

> Your spec limits the use of the DBR to Author Domains... is there a
> compelling reason to not just let it apply to any domain?

I don't see the point of using it on other domains.  Nobody expects the 
signature to match anything else.

R's,
John

>
> Ellen
>
> On Tue, Jul 27, 2010 at 11:35 AM, John Levine <[email-masked]> wrote:
>

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 29 Jul 2010 16:09:45 +0100

--On 26 July 2010 18:24:34 +0200 "J.D. Falk" 
<[email-masked]> wrote:

>
> I think it's because, when you implement most protocols, if your end is
> broken then you can't even talk to the other end.  With ADSP, if your end
> is broken then you can still talk SMTP and even sign with DKIM, but the
> other end may silently discard your message.  There's no feedback.
>

About 90% of the email sent to my personal email address ends up in a Gmail 
junk mail folder, that I never check. There's no feedback there, either.

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

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 29 Jul 2010 20:53:40 +0200

On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote:

> --On 26 July 2010 18:24:34 +0200 "J.D. Falk" <[email-masked]> wrote:
> 
> About 90% of the email sent to my personal email address ends up in a Gmail junk mail folder, that I never check. There's no feedback there, either.

As far as SMTP is concerned, that mail was successfully delivered.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 29 Jul 2010 12:10:47 -0700

> As far as SMTP is concerned, that mail was successfully delivered.

In both cases, yes.

If the recipient chooses to discard the email there's no obligation to
notify the sender - and I can't think of any existing case where the
recipient does so - let alone notify a third party.

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Jul 2010 12:26:50 -0700

On 07/29/2010 11:53 AM, J.D. Falk wrote:
>> --On 26 July 2010 18:24:34 +0200 "J.D. Falk"<[email-masked]>  wrote:
>>

How is this different than border mta's that 500 the message or 200 and silently
discard? This happens billions of times every day and has been for more than
10 years. At least with ADSP, a FBL has a little bit more concrete reason of why
it did that.

Mike