Subject: [ietf-dkim] Straw poll results

From: John Levine <[email-masked]>
Date: 9 Aug 2010 17:45:28 -0000

In article <[email-masked]> you write:
>However, if there's a need to trust the original sender, and you don't 
>quite trust the list to get that right for you, ...

It appears that we can discard this concern as counterfactual.  I
asked how people sort their list mail, and here's what I found:

  From: address       0.5  (Steve said he sorts on both from and list)

  List ID or similar: 8.5

  To: or Cc:.         3 (approximation to sorting by list name)

  rcpt-to address:    1 (unique address per list, I gather)

The overwhelming majority sort list mail by the identity of the list,
not by anything else.  The one person who sometimes sorts by From:
said that verifying the address wasn't an issue.

Unless people can offer real life examples of situations where they
remotely verify the identity of list contributors beyond using the
name or address on the From: line, I hope we can put this meme of
preserving incoming DKIM signatures to bed permanently.

I realize there's all sorts of hypothetical situations one might
imagine, but since we have over three decades of actual list practice,
it seems unlikly that any important model of list usage isn't already
in use somewhere now.

R's,
John

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

---

From: "John R. Levine" <[email-masked]>
Date: 9 Aug 2010 14:41:05 -0400

> You're assuming that how end-users sort list messages is the same
> as how DKIM verifiers might operate on list messages. Is that a
> good assumption? Or do you mean something else when you say
> "sort"?

I suppose I could go back and specifically ask people how their spam 
filters handle list mail as opposed to how they sort it, but I'd be rather 
surprised if the answers were different.  We're pretty high end users 
here, in my case the filtering and the sorting are intermixed and I doubt 
I'm the only one in that situation.

My point is simple: everyone handles mail from lists using the identity of 
the list, not the identity of the contributor.  Despite three decades of 
experience with mailing lists, arguments to the contrary say "someone 
might" rather than "we do".*

I hope we all agree that it is a waste of our time to design complicated 
mechanisms to solve problems that don't actually exist.

R's,
John

* - well, other than Steve A who said he sometimes does but he doesn't 
need signatures to do so
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 Aug 2010 11:45:22 -0700

> mechanisms to solve problems that don't actually exist.

WTF?

I thought that view was 20 years out of date for the IETF.  (Much longer for 
some other, unnamed SDOs, of course.)

d/

-- 

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Aug 2010 19:25:12 +0100

Hi John,

I think I generally agree with the overall conclusion that expecting
signatures to verify after list processing isn't worth the effort,
but I'm not sure your logic below is sound...

(Just asking, and not as chair or anything:-)

S.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 09 Aug 2010 11:57:39 -0700

On 08/09/2010 11:41 AM, John R. Levine wrote:
> the list, not the identity of the contributor.

Another vivid illustration of the fallacy of the excluded middle.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 09 Aug 2010 11:29:41 -0700

On 08/09/2010 10:45 AM, John Levine wrote:
> In article<[email-masked]>  you write:

Somebody needs to tell John that what "people" (= end users) do with
their mail, list or otherwise, is not the entire universe of possibilities
of using DKIM. How people sort their mail isn't a useful gauge of utility.

Mike

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 09 Aug 2010 21:55:06 +0200

> the list, not the identity of the contributor.  

Why do you simplify handling of list mail to sorting and filtering, 
ignoring two other important list handling activities:

1. reading mail
2. responding to mail

In both activities the From address (and possibly other fields like 
Reply-To and Sender) plays an important role. From a recipients point of 
view I'm not interested in what path the mail of John has travelled to 
my Inbox. And maybe the question boils down to what is DKIM: are we only 
interested to asap jump from DKIM to domain reputation, or do we also 
see the domain assertion statement in the DKIM spec:

<quote>
   The ultimate goal of this framework is to permit
   a signing domain to assert responsibility for a message, thus
   protecting message signer identity and the integrity of the messages
   they convey while retaining the functionality of Internet email as it
   is known today.
</quote>

> Despite three decades of 

I fully agree.

/rolf

---

From: "John R. Levine" <[email-masked]>
Date: 9 Aug 2010 16:11:57 -0400

> Why do you simplify handling of list mail to sorting and filtering, ignoring 
> two other important list handling activities:
>
> 1. reading mail
> 2. responding to mail

Well, OK.  Can you offer some non-hypothetical situations where you would 
read or respond to list mail differently if there were extra assurance on 
identity of the list contributor?

Or to put it another way, if someone has put an S/MIME signature on a 
messsage sent through a list, does that affect the way you respond?

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 09 Aug 2010 22:42:56 +0200

John R. Levine wrote:
> Well, OK.  Can you offer some non-hypothetical situations where you 
> would read or respond to list mail differently if there were extra 
> assurance on identity of the list contributor?

Until recently I used an anti-spam software package that provided the 
functionality of whitelisting based on the From address.

/rolf

---

From: "John R. Levine" <[email-masked]>
Date: 9 Aug 2010 16:48:20 -0400

> functionality of whitelisting based on the From address.

I believe it, I have procmail rules that do approximately the same thing.

Did you find that useful when handling mail from lists?  Surely you didn't 
try to whitelist everyone who ever contributed to every list you ever 
read.

I'm not trying to pick on you, but I would like to understand if there is 
any non-hypothetical spam or delivery management of list mail by 
contributor address.  So far it's all "well, someone might."

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Mon, 09 Aug 2010 13:56:07 -0700

On 08/09/2010 01:48 PM, John R. Levine wrote:
> any non-hypothetical spam or delivery management of list mail[...]

Again, the excluded middle that spam/etc pays any attention at all whether
something is "list mail", whatever that means.

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 9 Aug 2010 16:26:19 -0400

> messsage sent through a list, does that affect the way you respond?
It's not at all clear to me that the answer to that question is in any way 
related to the work of the working group.  What would we design differently if 
the answer was yes (or no)?

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Aug 2010 17:16:33 -0400

> of using DKIM. How people sort their mail isn't a useful gauge of utility.

+1.

Trying to make some sense of this, I presume John's main point is that 
the 8522.From has lesser value from a sorting and trusted list 
distribution standpoint and that most (if not all) of the trust would 
be based on a (presumed) dominant filtering and recognized trusted 
list-id header.

In other words when a list message contains a signature signed by the 
list domain and the domain matches the 5822.List-ID domain, such as 
the mail from this list:

   DKIM-Signature: d=mipassoc.org;
   List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>

Then a trusted list-id domain recognized by the user makes the 
security issues related to trust using the 2822.From is less significant.

Well, never mind the idea that MLS software makes it an option to add 
List-XXXX headers, although an DKIM updated MLS would probably need to 
enforce it for DKIM support, we still have the 5+ year plus issues of 
1st vs 3rd party signature faults.

All we would be doing here is shifting the 2822.From domain DKIM 
signature correlation to a different header id and we would have a 
presumption it will always be 1st party LIST DOMAIN signature.

If there was one major consensus from all sides, documented in the 
Thread Analysis and translated into the SSP functional requirements is 
that everyone agreed the 1st party self-asserting valid DKIM 
signatures need no policy lookup confirmation.  A valid 1st party 
signature is only possible when the 1st party domain prepared it to be 
publicly validated. The only security thread was internal compromising 
of the the domain.

The problem and WG conflicts has always been how to deal and control 
of unsolicited, unexpected, anonymous and abusive 3rd party signatures.

So I see no difference here using a LIST-ID domain as the "binding 
correlation" with DKIM signature.  What if its a 3rd party LIST signature?

   DKIM-Signature: d=mipassoc-BAD-GUY.org;
   List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>

If the user sorts by LIST-ID, he will still have the possible valid 
signatures from unknown 3rd party domains and the only way to resolve 
this takes us back to square one - 1st versus 3rd party expectations 
using a DKIM augmented technology concept where the list-id domain 
exposes the "expectations" for signatures - either from a policy 
record or from some reputation databases.

Either way, Using 5322.From or 5322.List-ID domain bindings, the 1st 
vs 3rd party signing expectation issues are still there.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Douglas Otis <[email-masked]>
Date: Mon, 09 Aug 2010 14:18:39 -0700

> mechanisms to solve problems that don't actually exist.
John,

Don't lose sight of ADSP's intended purpose. This addressed a problem 
only significantly affecting a very small percentage of email domains.  
Nevertheless, the experience of financial loss drove forward efforts at 
finding a solution.

The ADSP dkim=all tpa-sig; assertion will not require mailing lists to 
change their practices.   Efforts in resolving the issue rests with the 
targeted domains.

Sorting by the mailing list only works when the recipient subscribes to 
the list, and that the list has indeed issued the message.   The intent 
behind the "complexity" of the TPA-Label scheme is to utilize any 
existing method to ensure the list represents the message source, based 
upon guidance offered by the targeted Author Domain.

No amount of reactive domain reputation foo will provide a solution 
within this problem space.

-Doug

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 09 Aug 2010 23:38:18 +0200

> the answer was yes (or no)?

Let me try to explain. If the identity of the list contributor is of any 
value to the receiver of an MLM-distributed message, then it is 
important to (try to) preserve the original DKIM signature across an MLM 
redistribution of the message (if at all possible). If however the 
identity of the list contributor is of no value whatsoever, we should 
not bother about preserving the original DKIM signature.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Aug 2010 17:41:06 -0400

> contributor address.  So far it's all "well, someone might."

 From what I can see, Yahoo.com Online mail interface has two options 
to white list mail, otherwise all new mail goes into the a SPAM box first.

1) White list the 2822.From (which it calls "Sender") by adding its to 
the user's contact list,

2) Creating a filter, which from I see does not allow 5322.Header rules.

This is the filter form:

Filter name: ______________
sender:     _______________ [_] sender match case
recipient:  _______________ [_] recipient match case
subject:    _______________ [_] subject match case
body:       _______________ [_] body match case
Move to Folder:	______________

The only way I was able to white list a test list was to use a Subject 
rule for [LIST_NAME] to move it to a folder LIST_NAME.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 9 Aug 2010 17:52:19 -0400

On Monday, August 09, 2010 05:38:18 pm Rolf E. Sonneveld wrote:
> > It's not at all clear to me that the answer to that question is in any
> > way related to the work of the working group.  What would we design
> > differently if the answer was yes (or no)?
> 
Not at all.

If the receiver is going to act differently to signed or unsigned mail from 
certain domains, then it's important to preserve the signature or change the 
domain.  For receivers of non-trivial scale they aren't in a position to know 
what mail they are receiving is MLM-distributed, so the question of how they 
would treat MLM-distributed mail is irrelevant because they don't and can't 
segregate it that way.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Mon, 9 Aug 2010 14:22:35 -0700

> the answer was yes (or no)?

If a recipients handling of an inbound email from a mailing list varies
depending on whether you can authenticate the original author (the
>From field) or not, then there may be some value in helping mailing
lists tunnel authentication through in a way that allows you to
authenticate the original author.

If it doesn't, there isn't.

If none of the members of this list would handle an inbound email from
a mailing list depending on whether they can authenticate the original
author or not, nor point at a concrete example of people ding so, that
would suggest it's not a common requirement. Which would suggest it's
not worth considering how to support it for DKIM, which seems to be at
least tangentially related to what we're doing here.

Cheers,
  Steve

---

From: Douglas Otis <[email-masked]>
Date: Mon, 09 Aug 2010 15:12:41 -0700

> would treat MLM-distributed mail is irrelevant because they don't and can't
Scott,

You are right to suggest that receivers don't know how to segregate MLM 
mail from the rest of the Internet.  But with the TPA-Label approach, 
the mailing-list does not need to change the Author Domain. Using a 
single transaction, the TPA-Label scheme provides targeted domains a 
means to indicate whether their message might be carried by a 
third-party service, whether the service has been authorized, and how 
this service can be authenticated.  In this way, only the code checking 
ADSP compliance needs to change, and not all the various mailing-lists 
and MUAs designed to inter-operate with their existing practices.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 9 Aug 2010 18:13:55 -0400

> least tangentially related to what we're doing here.

This assumes mail from MLMs is treated differently than other mail.  While 
individual users may (and probably do) treat it differently, receivers of non-
trivial scale don't and can't.

Scott K

---

From: John Levine <[email-masked]>
Date: 9 Aug 2010 22:44:47 -0000

>Let me try to explain. If the identity of the list contributor is of
>any value to the receiver of an MLM-distributed message, ...

We're going in circles here.

Please see Steve A's recent message.

R's,
John

---

From: John Levine <[email-masked]>
Date: 9 Aug 2010 22:48:51 -0000

>This assumes mail from MLMs is treated differently than other mail.
>While individual users may (and probably do) treat it differently,
>receivers of non- trivial scale don't and can't.

Sigh. Anyone who uses gmail would know that your assertion is just
plain wrong.

And in any event, even if your assertion were true, so what?  Our
working assumption is that receivers will use valid DKIM signatures to
whitelist mail from signers they like.  How does it matter whether the
signer happened to be a related to a list?

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Mon, 9 Aug 2010 15:52:04 -0700

> trivial scale don't and can't.

I agree, in general.

One implication of that is that if you're planning to do something with
email that will break if there's a MLM involved, it's broken[1].

Cheers,
  Steve

[1] We could call this "The SRS lemma".
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Aug 2010 19:08:30 -0400

>> It's not at all clear to me that the answer to that question is 
>> in any way related to the work of the working group.  What would 
>> we design differently if the answer was yes (or no)?

> not bother about preserving the original DKIM signature.

This is why I believe that the current GOOD CITIZEN centric approach 
is very hard to resolve without addressing the "BAD CITIZEN" model 
first or at the very list, the GOOD CITIZEN model should not come at 
the expect at diminishing the high beneficial value of the BAD CITIZEN 
model.

It is a conflict an engineering philosophy and I believe once we 
acknowledge one can not exist without the other, this issue with 
continue in perpetuity.

What you speak of is about trust, something something about the 
message that allows you to believe it is OK?

Consider the contrary question, what is it about the message that 
makes you NOT TRUST the message?

Lets say that we some how invented a way to RESTORE THE INTEGRITY OF 
THE ORIGINAL SIGNATURE so its no longer a factor and I changed my MUA 
or online mail web interface to support and present all four ideas:

      5322.FROM domain
      5322.DKIM signing domain (d=)
      5322.ADSP as a function of 5322.FROM domain
      5322.LIST-ID domain

and I'm going to add a 5th new idea here (data point) called LDSP 
(List Domain Signing Policy)

      5322.LDSP as a function of 5322.LIST-ID domain.

Idea #1:

If the 5322.ADSP result is DISCARDABLE, the DOMAIN is making a public 
policy statement:

       NO ONE CAN SIGN MAIL FOR US. ONLY WE CAN SIGN MAIL.
       This is called a 1st party signing only policy.

The question is why would you (speaking in general) ignore this very 
powerful data point if you see your list message is signed by the list 
and not by the domain?  The original signature is intact. But the 
policy said only they sign mail - no one else.

Doesn't that say there is someone WRONG, not GOOD, about this message? 
even with an original valid signature intact?

Idea #2

Lets say you trust all mail coming from this list because it is signed 
by the list domain.  You feel reasonable secured it is valid GOOD 
message when it is signed by the list and also if any, the original 
domain signature is intact.

But what if the DKIM signature domain is not signed by the list?  What 
it is a 3rd party, for example?

     From: <[email-masked]>
     DKIM-Signature: d=FROM-DOMAIN.COM
     DKIM-Signature: d=OTHER-RESIGNER.COM
     List-Id: <[email-masked]>

Would you have a lower trust of this message?  Would it still matter 
if the original signature is valid but the list signature is valid but 
resigned by some other unknown domain?

Idea #3:

Let say that we have this new LDSP (List Domain Signing Policy) 
protocol which is a small change to ADSP by instead of anchoring off 
the 5322.From domain, LSDP anchors off the 5322.List-ID domain.

Let say that LIST-DOMAIN.COM has a LDSP policy of:

     DKIM=DISCARDABLE

which says:

     LIST-DOMAIN.COM is the only domain that can sign list messages
     coming from this list.  No one else is expected to sign as a
     3rd party.

Would you still trust this list even when there is an explicit LDSP 
policy exposing to the world that it has an exclusive and  restrictive 
1st party signing policy?

So basically, all I am saying that regardless of how its down, there 
is always the issue of not getting what is expected and before you can 
even trust a list-id or from domain, you need to factor everything all 
the failing about it.

If you trust a LIST-ID domain, thats that mean that only it can sign 
mail? What happens when its some other domain?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Aug 2010 00:16:18 +0100

Folks. I suspect we're not longer involved
in a straw poll of any kind in this thread.

If there are points arising, please start
new threads.

Otherwise, it'd be great if folks could spend
their time commenting on Murray's draft, as
some have already done.

Thanks,
Stephen.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 9 Aug 2010 19:27:05 -0400

> Sigh. Anyone who uses gmail would know that your assertion is just

There's a difference between "claims to be from an MLM" and "From an MLM".  
Today there isn't much value in making the claim, so no one bothers.  It would 
be unfortunate if we recommended something that caused List-ID headers to be 
less useful because people found value in spoofing them.
 
> signer happened to be a related to a list?
If I'm a consumer of your list of domains that you're convinced sign all their 
mail and I get an unsigned message from one of them, I'm bound to be extra 
suspicious of that.  "Oooh, it came from a mailing list so I don't care" isn't 
the most likely response.

Which is why the whole straw poll is irrelevant.  Since the D in DKIM is 
Domain, it's really no concern how individuals filter mail.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 9 Aug 2010 19:31:53 -0400

> [1] We could call this "The SRS lemma".

Yes.  It's very similar.

One needs to decide what factors one cares about the most.  I said a few 
threads ago that I don't think there is a completely satisfactory solution.  I 
think the possibilities are roughly:

1.  Fix lists so that signatures survive.

2.  Have MLMs change the domain of the message.

3.  Have mail get rejected/discarded/etc.

There are variants of all three possibilities, but none that will satisfy 
everyone. 

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Mon, 9 Aug 2010 16:42:26 -0700

> 3.  Have mail get rejected/discarded/etc.

4. Write off ADSP as broken, do something useful instead.

(Just for completeness).

> There are variants of all three possibilities, but none that will satisfy 

Yup.

Cheers,
  Steve

---

From: John Levine <[email-masked]>
Date: 9 Aug 2010 23:42:41 -0000

>If I'm a consumer of your list of domains that you're convinced sign
>all their mail and I get an unsigned message from one of them, I'm
>bound to be extra suspicious of that.  "Oooh, it came from a mailing
>list so I don't care" isn't the most likely response.

I can't speak for other hypothetical lists of domains who sign all
their mail, but the domains on my small but real drop list send no
mail to mailing lists.

I suppose it is hypothetically possible that there would be well run
lists that would leak the occasional forged message from some ESP
domains.  But since that happens now basically never, I don't see any
reason to spend any effort on it.  Maybe you'd look at the list's
signature and deliver it, maybe you'd look at the drop list and drop
it, leading to one filtering error in umpteen million messages.  If
that's the worst problem you have with your mail filtering, you don't
have any problems.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 Aug 2010 16:54:59 -0700

> 4. Write off ADSP as broken, do something useful instead.

A less hostile and possibly more productive phrasing of this is:

    4. Accept that ADSP has a tightly constrained range of use and that this 
does not include mail processed through an MLM

d/
-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Mon, 9 Aug 2010 17:29:19 -0700

On Aug 9, 2010, at 4:54 PM, Dave CROCKER wrote:

>   4. Accept that ADSP has a tightly constrained range of use and that this does not include mail processed through an MLM

Scott already covered that in point 3, I think ("Have mail get rejected/discarded/etc.").

Cheers,
  Steve

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 Aug 2010 17:31:46 -0700

> Scott already covered that in point 3, I think ("Have mail get rejected/discarded/etc.").

I didn't read that as the same thing.  I think I understand why one might, but 
the semantics really are different.

Reaction versus prevention...

d/
-- 

   Dave Crocker

---

From: Graham Murray <[email-masked]>
Date: Tue, 10 Aug 2010 06:51:13 +0100

> less useful because people found value in spoofing them.

Which is where such tools as SPF and DKIM, and even ADSP discardable,
are useful. The MLM could usefully publish '-all' SPF records, DKIM sign
all mail passing through it and assert that any mail purporting to be
via its lists which is not signed may be discarded. Though for ADSP to
help detect spooked List-ID headers, the MLM, rather than the submitter,
would have to be considered the Author domain.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 11 Aug 2010 13:51:32 +0200

>>> [1] We could call this "The SRS lemma".

However, it's wrong.  As a counterexample, S/MIME or PGP encryption will 
break if there's a MLM involved, but they're not broken.

>> 1.  Fix lists so that signatures survive.

This has to be plan A.

> 4. Write off ADSP as broken, do something useful instead.

Agreed.  As a fact, I've had to disable ADSP in my DKIM-filter, because I'm 
unable to whitelist every MLM.

>> There are variants of all three possibilities, but none that will satisfy 

Since someone asked about the difference between signing digests vs 
individual list messages, let me put a similar question:

   DKIM practices put much concern in preserving the integrity of an author's
   text.  Yet, when the same text is quoted in replies, it is subject to
   arbitrary changes, and nobody cares.

   Given that, why cannot we relax integrity requirements when a message is
   destined to a list, as if the list just "quoted" it?

As a practical possibility, a verifier may dump correctly signed List-Post 
addresses from incoming messages onto a database.  Let's call it the server's 
"participating MLMs DB."  When a signer is about to sign mail to a 
participating MLM, it puts l=0 and only signs the fields "From", "Date", and, 
if we wish to formalize the reason, "ADSP-Required".