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

From: Ian Eiloart <[email-masked]>
Date: Wed, 02 Jun 2010 12:46:36 +0100

--On 28 May 2010 13:26:28 -0700 Dave CROCKER <[email-masked]> wrote:

>
> On 5/28/2010 12:07 PM, Jeff Macdonald wrote:
>> But I'd like to see if I understand the difference your are trying to
>> highlight between a manually maintained list and a self published
>> list.
>
> There is a key semantic difference which, I believe, makes for a key
> difference  in utility.
>
> In a manually maintained list, there is an independent assessment of what
> domain  names are worth worrying about.  (The independence is from the
> owner of the  domain.  The assessment might be by a third part or it
> might be by the recipient.)
>
> The owner-based list is a statement by the domain owner, themselves, of
> what  domains the recipient should handle in a particular way.
>
> An important problem with this latter model is how noisy it is.  Both the
> domain  owner and the transmission process introduce significant errors.
>
> By contrast, the former model can incorporate a conformance metric into
> the  decision whether to list the domain.
>

Actually, the difference is less than you think. It's quite possible to 
combine both models. Spamassassin, for example, allows you to maintain a 
list of domains for which you should treat SPF or DKIM matches or fails in 
a particular way. For example, you could tell spamassassin to blacklist SPF 
fails for certain domains, or whitelist messages DKIM signed by certain 
domains.

Effectively, you're applying your own domain reputation system, and using 
SPF or DKIM published information to make the reputations more usable.

Similarly, with ADSP you don't have to rely on published information, and 
when information is published, you don't have to guess whether the 
publisher is competent. You can maintain your own list of domains that you 
trust to get ADSP right, and use standard software to apply that judgement. 
Several benefits are gained from ADSP:

1. Code reuse: Although you may choose to maintain your drop list, you 
don't have to write software for your MTA, you can just configure it.

2. Discoverability: You can find out from ADSP publications that the sender 
cares about this stuff. OK, it's still a leap to add them to your drop 
list, but you do at least have somewhere to start. If a large sender and 
receiver come to a private agreement about DKIM use, then only they 
benefit. If they choose to use ADSP to implement that agreement, then other 
mail systems can also benefit.

3. Discussability: given that it's a standard, potential users can read 
about best practice, and senders and receivers have a common language to 
talk about how things should work.

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

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

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 05:48:14 -0700

On 6/2/2010 4:46 AM, Ian Eiloart wrote:
> --On 28 May 2010 13:26:28 -0700 Dave CROCKER<[email-masked]>  wrote:
...
> combine both models.

You do not discuss "combining" the models.  You discuss a tool that supports 
both.  Juggling two things is not the same as combining them.

In any event, the scope of this working group does not include design of 
filtering engines.  It stops with providing filtering engines additional 
information.

My previous point was -- and remains -- that the fundamental semantics of 
self-published information about a signer is entirely different from assessment 
information about that signer that is published by someone else.  No software 
design eliminates that difference.

> SPF or DKIM published information to make the reputations more usable.

That's not a "reputation" system.  It's possibly useful information, but it's 
not "reputation" as the term is typically used in the industry.

d/
-- 

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

---

From: John Levine <[email-masked]>
Date: 2 Jun 2010 13:20:41 -0000

>trust to get ADSP right, and use standard software to apply that judgement. 

Manual drop lists are a fine idea, but what do they have to do with ADSP?

>don't have to write software for your MTA, you can just configure it.

I'm happy to reuse the manual drop code in Spamassassin.  I still don't
see what it has to do with ADSP.

>list, but you do at least have somewhere to start.

Here's a thought experiment: let's say you have your list of domains
that are known to be phish targets that sign their mail, so you drop
unsigned mail, and they all happen to publish ADSP.  Someone's ADSP
record goes away.  Is it more likely that they've stopped signing
their mail, or that their ADSP record is temporarily messed up?  Why?

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Jun 2010 09:33:57 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John Levine
> Sent: Wednesday, June 02, 2010 9:21 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong
> Discussion
> 

<snip>

> their mail, or that their ADSP record is temporarily messed up?  Why?
Signing their mail does not equal ADSP. "Knowing" they sign their mail
does not equal ADSP. As you have pointed out, ADSP does not equal manual
drop lists. 

The fact that someone's ADSP record - absent any other data points -
goes away, tells us nothing other than their ADSP record went away.
There could be any number of reasons as to why it went away. 

Are we now going to have to write a draft for casting goat bones to
determine the meaning of standards implementations and operational
practices? 

It's really quite simple. If there is no longer an ADSP record then ADSP
is not applicable. Doesn't matter whether they are still signing or not
signing. If a domains DNS records returned an NXDOMAIN on a lookup would
you insist on doing something other than saying the domain doesn't
exist?

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 08:47:45 -0700

On 6/2/2010 6:33 AM, MH Michael Hammer (5304) wrote:
> It's really quite simple.

This is the crux of the disparity of views.

Those of use who note that none of this is simple worry about adoption and 
success barriers, noting that new services have a long and problematic history 
and that more efforts fail than succeed.

We also note that operational details often are far more complicated and/or 
costly than designers anticipate.

In other words, as soon as the effort moves outside of a few people's minds, 
nothing about this is simple.  (Well, given the track record of new protocols, 
in general and security-related protocols in particular, I suppose it is simple 
and reasonable to anticipate failure.)

d/
-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Jun 2010 12:12:25 -0400

For shame Dave. Taking one sentence out of context is something I would
not have expected from you.

When I say "It is simple" in response to Johns artificially constructed
hypothetical, this is not the sweeping statement of the universe you are
trying to present it as.

In Johns example he is trying to conflate "I believe that someone always
signs their mail" with ADSP. These are two different animals. Notice
that he didn't indicate whether the person used "ALL" or "DISCARDABLE".
He artificially gave us a binary set of choices when in fact there are
many more choices available.

The whole point of having a standard is to avoid the voodoo and
guessing. If John or someone else were really that concerned about a
particular domain's signing circumstances I would expect him/them to
contact the domain in question. The whole point of a standard is to
avoid the one-on-one checking. Now during initial rollouts I would
expect people to do some validation and checking.

You are absolutely correct that we should anticipate failures. That does
not mean we should anticipate FAILURE from a reasonably crafted
standard. We cannot protect foolish people from doing foolish things to
themselves. This is another case of King Canute.....

Document, yes.
Educate, yes.
Protect from themselves, no.

BTW John, I want to thank you for teaching me to invoke this.

Mike

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Wednesday, June 02, 2010 11:48 AM
> To: MH Michael Hammer (5304)
> Cc: [email-masked]
> in general and security-related protocols in particular, I suppose it
is
> simple

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 09:30:32 -0700

> not have expected from you.

After all this time, I am glad to hear that I can still surprise you...

FWIW I took it out of context entirely knowingly.  Frankly, I wasn't interested 
in the particular topic.

As I said, I think that that captures the critical difference in what drives the 
two sides of these various-but-really-identical debates.  The particular context 
wasn't the point.  The difference in attitudes about /any/ of these topics is 
the point.

> guessing.

Right.  And a standard that is not adopted or used does not achieve this. 
Worrying very carefully about adoption barriers -- who will adopt it and why -- 
is essential to this, but we have not been succeeding in getting answers to hard 
questions here.

> standard.

Actually, yes it does.  That is exactly my point.

A side effect of living in Silicon Valley is seeing how often carefully crafted 
startups fail.  Good ideas and a well-designed product are not sufficient to 
guarantee success, absent properly matching the /perceived/ needs of the folks 
who will use it /and/ the folks who will pay for it.

> We cannot protect foolish people from doing foolish things to

The benefit of that perspective is acknowledging limitations.  The danger is not 
putting in enough effort to make things appropriately usable and/or not putting 
enough effort into crafting a value proposition that is compelling to the target 
audience.

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 02 Jun 2010 12:16:06 -0400

>their mail, or that their ADSP record is temporarily messed up?  Why?

Or, I suspect most likely, they thought they were signing everything and then later something changed or they discovered they missed a piece of their infrastructure,  so they've retracted the policy until they've corrected the problem. 

Scott K

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jun 2010 14:24:58 -0400

> Well, you'd process that mail as if... there were no ADSP policy because... there's no ADSP policy.

I guess I agree, since I would use a credible manually maintained 
list and ignore the ADSP whether or not there was any.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Jun 2010 14:29:47 -0400

> From: John R. Levine [mailto:[email-masked]]
> Sent: Wednesday, June 02, 2010 2:25 PM
> To: Brett McDowell
> Cc: MH Michael Hammer (5304); [email-masked]

I can't help myself. This image of John sitting at a desk with his quill
and inkwell manually maintaining his credible list by the light of a
whale oil lamp keeps popping into my minds eye. How scalable is that
list John?

So

---

From: Brett McDowell <[email-masked]>
Date: Wed, 02 Jun 2010 14:14:26 -0400

> It's really quite simple.

Agreed.

BTW, I'm actually agreeing to this statement in the context it was made :-)

> If there is no longer an ADSP record then ADSP
> is not applicable.

Do we really need to publish informational guidance on this point?  If yes, then let's do it.

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jun 2010 15:28:09 -0400

> In terms of public information, we are in production with DKIM verification/blocking today with two mailbox providers.  We'd like to be in production with say... two hundred by some near-term date certain.  Hence the need for ADSP.

This is a non-sequitur, but we've been through it before so I won't keep 
beating the greasy spot where the horse used to be.

R's,
John

---

From: Brett McDowell <[email-masked]>
Date: Wed, 02 Jun 2010 14:35:20 -0400

On May 28, 2010, at 12:14 AM, John Levine wrote:

>> So I understand your line of reasoning. But today, I believe ADSP can
>> provide a benefit. Brett has data that supports that.
> 
> Once again, we have a pernicious confusion between manually maintained
> drop lists and ADSP.
> 
> Brett has data that supports the former, not the latter.

I disagree, but here's some new data that might better illustrate the case for ADSP.

The case is even stronger from the mailbox providers' perspective since they would be working with orders of magnitude more senders.

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jun 2010 15:38:14 -0400

> whale oil lamp keeps popping into my minds eye. How scalable is that

If ye towne cryer dost distribute such a liste to manye and divers mail 
servers, as scalable as ye do wante.

I agree it would be useful to have a way to discover whose mail is signed 
and usefully discardable.  But there's little reason to think that 
self-publication along the lines of ADSP will do it successfully.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Jun 2010 15:52:31 -0400

> Sent: Wednesday, June 02, 2010 3:38 PM
> Cc: DKIM List
> Subject: RE: [ietf-dkim] list vs contributor signatures, was Wrong
> Discussion
> 

This addresses distribution of the list, not maintaining the list. Ye
olde add/change/delete issue. And of course there is the question of
whether folks will trust (the generic) you as widely as a solid
standards based approach for self-publication.

> self-publication along the lines of ADSP will do it successfully.

There's little reason to think it won't. Time wounds all heels. As I've
said before, I believe ADSP is crippled.... intentionally so. There were
compromises of various sorts in order to be able to get the document
out. One need only look at the discussions around SSP drafts 1- I think
it was 13 or so).  Could it be fixed? Possibly. Will it be fixed?
Doubtful. It is unlikely that there will be sufficient will or consensus
from this working group for such an effort to be successful.

Mike