Subject: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault

From: "J.D. Falk" <[email-masked]>
Date: Tue, 14 Sep 2010 12:35:09 -0700

...but not for the reasons the anti-ADSP folks keep bringing up.

DKIM is failing because every discussion about actually /using/ DKIM inevitably gets stuck in the same old argument about ADSP.  Doesn't even matter what the argument is about anymore; it stops all forward progress every time.  And we keep letting it happen -- actively participating, even, including me.

Continuing to argue these same points over and over is disrespectful of our colleagues both on and off this list, and of the IETF process.

So I'm going to stop, and I beg you all to join me.

Stop arguing, and start writing drafts.  Let us discuss the drafts instead of attacking each others' intractable positions for the Nth time.  If you think ADSP will bring about the end of all human communication, WRITE A DRAFT EXPLAINING WHY.  If you think something else, write that instead.

Yes, I know it requires more effort, but what we've been doing so far clearly isn't working.

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

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Sep 2010 15:54:30 -0400

J.D. Falk wrote:
> DKIM is failing because every discussion about actually /using/ 
> DKIM inevitably gets stuck in the same old argument about ADSP.

Should you tell you something. Ignorance doesn't work either.

> Doesn't even matter what the argument is about anymore; it stops 
> all forward progress every time.  And we keep letting it happen -- 
> actively participating, even, including me.

The problem was that we allowed an author who never believed in policy 
to take over SSP, removed all the 3rd party considerations and renamed 
it ADSP.  But he thought that would kill all the 3rd party signer issues.

> 
> Continuing to argue these same points over and over is disrespectful 
> of our colleagues both on and off this list, and of the IETF process.

So what you really asking if POLICY in general should be throw out, 
disrespecting all that that believe it would be useful?

> So I'm going to stop, and I beg you all to join me.

And this this has been the problem, shut policy advocates using 
Consensus by Osmosis - that hasn't worked either, maybe it should tell 
you something.

> Stop arguing, and start writing drafts.  

We did.  DSAP and TPA and SSP was written.  Policy opponents killed 
those efforts. Two RFC standards were written for the Policy 
functional requirements and Threads Analysis which included Policy 
considerations. Policy opponents killed those which to ignore the 
security concerns with unrestricted resigners.

The issue it doesn't go away.

Murray drafted the MLM I-D and that still isn't acceptable by the 
policy opponents.

> Let us discuss the drafts instead of attacking each 
> others' intractable positions for the Nth time.  

You promise not to attack Policy Advocates if they reintroduce new or 
rehash 3rd party signer protocol I-Ds?

> so far clearly isn't working.

That I agree - opening minds on 3rd party signing issues might help, 
or perhaps getting a new editor for ADSP to fix its bugs might work too.

Either way, you have to open your mind on POLICY otherwise it is a 
waste of time, but the issues don't go away.

Moving DKIM to experimental status might work too until we figure out 
how to add a protocol protection security layer to it.  It doesn't 
have one.

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

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 14 Sep 2010 22:30:53 +0200

> So I'm going to stop, and I beg you all to join me.

+1.

> Yes, I know it requires more effort, but what we've been doing so far clearly isn't working.

+1.

Period.

/rolf

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 14 Sep 2010 15:27:34 -0600

...and implement what you think should work before making an issue of it in IETF.  

That's been my #1 lesson this year (I'm new to IETF).  I originally was actually worried about blowback by the community if a large entity like ourselves and few other household names just went off and deployed something with capabilities that overlap with proposals being floated in the IETF, without participating in those debates or aligning with those proposals.  But what everyone has been telling me is that it would be better in fact to go and deploy something before drafting the I-D and debating it here.  This is the main reason why I went quiet on these lists since the Barcelona MAAWG meeting (until this week).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Sep 2010 14:34:56 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of McDowell, Brett
> Sent: Tuesday, September 14, 2010 2:28 PM
> To: J.D. Falk
> Cc: DKIM List
> Subject: Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
> 

+ULONGMAX

We're long past the point where arguing as furiously as possible about theory yields useful results.  It's time for some data to back up our various ideas.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Tue, 14 Sep 2010 15:01:20 -0700

> Yes, I know it requires more effort, but what we've been doing so far clearly isn't working.

The problem is that the two things have badly conflicting requirements. DKIM is based on a domain-based identifier that's independent of the From: domain, and that's where much of it's value comes from. ADSP is based on a domain-based identifier that must remain identical to the From: field at all times, and that's where it's sole value comes from. ADSP intrinsically conflicts with the original design case for DKIM, despite being piggy-backed on to it.

So any document that puts forth even basic good practices for DKIM usage for monitoring sender reputation (use d= to differentiate mail streams) is going to be anathema to ADSP requirements (d= must be the same as the From: domain).

And any ADSP-driven set of requirements (mailing lists should not only re-sign any mail they re-send, they should alter the From: address to match) is going to be considered nonsensical by people who consider DKIM a way to tie an identity cookie to a message.

And, as we've seen, any compromise document is hated by pretty much everyone, even assuming you can get there.

Cheers,
  Steve

---

From: John Levine <[email-masked]>
Date: 15 Sep 2010 00:13:10 -0000

>  But what everyone has been telling me is that it would be better in
> fact to go and deploy something before drafting the I-D and debating
> it here.  This is the main reason why I went quiet on these lists
> since the Barcelona MAAWG meeting (until this week).

Yes indeedy.

Keeping in mind that no good deed goes unpunished, you can be sure that
whatever Paypal does, you'll get complaints about it, but it sure would
be nice to have running code we can poke and try out and see how useful
it is.

R's,
John

Minor niggle: the order of writing the code and the I-D is not
critical.  It's not a bad to do them at the same time, so that you can
circulate the I-D among people whose opinons you value and get
possibly helpful suggestions before the concrete around the code
hardens too much.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Sep 2010 20:12:12 -0400

+1.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Sep 2010 21:11:14 -0700

Based on that (rather precise) description, aren't ADSP's requirements a proper subset of the DKIM requirements?  If so, I'm not sure I agree with "badly conflicting", but it does frame future discussion quite nicely.

For example, if DKIM enables the identification of mail streams, isn't the one ADSP covers just a specific instance of a mail stream?

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Steve Atkins [[email-masked]]
Sent: Tuesday, September 14, 2010 3:01 PM
To: DKIM List
Subject: Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault

Cheers,
  Steve

---

From: "McDowell, Brett" <[email-masked]>
Date: Wed, 15 Sep 2010 08:43:18 -0600

> For example, if DKIM enables the identification of mail streams, isn't the one ADSP covers just a specific instance of a mail stream?

BTW, one thing I think we can agree on and find value from in these pre-deployment email discussions is terminology.  I ran into a problem at the last MAAWG during a panel discussion where my understanding of "3rd-party signature" is what someone else meant by "2nd-party signature".  What is the real definitions of "1st-party", "2nd-party" and "3rd-party" signatures in the context of DKIM and ADSP, i.e. in the context of i= and d= and from: values?

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 15 Sep 2010 11:02:42 -0400

> BTW, one thing I think we can agree on and find value from in these pre-deployment email discussions is terminology.  I ran into a problem at the last MAAWG during a panel discussion where my under…

I believe only the ADSP documents talk about 3rd party, and it is
defined as d= not From Domain.

These are 3rd party:

DKIM-Sig: ... d=dkim.bar.com
From: [email-masked]

DKIM-Sig: ... d=beer.com
From: [email-masked]

I believe Patrick defined 2nd party to be:
DKIM-Sig: ... d=dkim.bar.com
From: [email-masked]

the maawg meeting was a first that I've heard that.

First party is of course:

DKIM-Sig: ... d=bar.com
From: [email-masked]

BUT I really thinking making such distinctions is the wrong approach.
It really doesn't matter what type of signature it is. I'd even
advocate for a DKIM update that would cause all signatures to be 2nd
or 3rd to enforce the point.

-- 
Jeff Macdonald
Ayer, MA

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Sep 2010 15:45:29 +0100

I totally agree that this pointless repetition is...pointless.

Barry and I have asked folks to stop that kind of thing a number
of times with no real success. (As demonstrated by the last
few days messages.)

Perhaps this time people will be more responsible, we'll see.

I also think that the fewer people that take the bait, the
quicker these threads peter out. So each person who decides
not to hit "send" quite so readily is helping.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Sep 2010 15:52:00 +0100

> BTW, one thing I think we can agree on and find value from in these pre-deployment email discussions is terminology.  I ran into a problem at the last MAAWG during a panel discussion where my under…

How does that relate to the current WG work items?

If it does, please start a specific thread the editor
can make sense of.

If it doesn't, do you think its really a good idea to
ask folks to get involved in a discussion of definitions
now?

Also, how does it relate to the subject line?

Please don't respond to this on the list unless you have to.

S.

---

From: "McDowell, Brett" <[email-masked]>
Date: Wed, 15 Sep 2010 09:30:29 -0600

> or 3rd to enforce the point.
That seems aligned with Steve's point about DKIM's value coming (only?) when the d= value is not the same as the domain-name in the from: field.  So according to you (and Steve?) the IETF should pass a normative requirement that all verified email be hired out to 3rd parties?!  That strikes me as very anti-Internet.

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 15 Sep 2010 11:54:51 -0400

> That seems aligned with Steve's point about DKIM's value coming (only?) when the d= value is not the same as the domain-name in the from: field.  So according to you (and Steve?) the IETF should pa…

Ah, you just enforced my point. Review the 3rd party definition again.

This is considered 3rd party. Even though it is controlled by the same entity.

same with this example.:
DKIM-Sig: ... d=aol.com
From: [email-masked]

It seems Stephen considers this off topic, so anything further should
be taken off-list.

-- 
Jeff Macdonald
Ayer, MA

---

From: Steve Atkins <[email-masked]>
Date: Wed, 15 Sep 2010 09:01:26 -0700

>>> BTW, one thing I think we can agree on and find value from in these pre-deployment email discussions is terminology.  I ran into a problem at the last MAAWG during a panel discussion where my und…

There is none in the context of DKIM, as DKIM doesn't say much about the RFC-822 From:.

> That seems aligned with Steve's point about DKIM's value coming (only?) when the d= value is not the same as the domain-name in the from: field.  So according to you (and Steve?) the IETF should pa…

I think you're not reading carefully, and you're twisting Jeff's words and mine to a point that bears no resemblance to what either of us said.

Note that "d=dkim.bar.com" (or, more realistically, "d=transactional.bar.com") are very plausible d= values that someone sending mail "from" [email-masked] may use.

A big part of the value of DKIM is that you can use different d= values for mail from the same RFC-822 From: address. That includes d= values that are controlled by the sender as well as d= values controlled by others.

As an example, Paypal sends both transactional email, spam and normal employee email. The transactional email and employee mail is wanted by recipients. The spam is hated by recipients. The reputation of the three mail streams will be very different, and you'll want to keep them separated as much as possible so that the spam doesn't affect the delivery of the transactional messages too badly.

So you may well sign the spam with just "d=bulk.paypal.com", while you'd sign the employee mail with "d=corp.paypal.com". And the transactional - you might sign it with both "d=transactional.paypal.com" and (hypothetically) "d=thismailistransactional.andwanted.andtheypaidus.returnpath.com".

None of those are "first-party" signatures, as the ADSP docs describe it. But the strength isn't that they're *not* "d=paypal.com" or "d=bar.com". The strength is that they don't *have* to be. Because they don't have to be, it allows you to use different d= values using domains you control to differentiate the mail streams.

Note that if you want to use ADSP for both the spam and the transactional mail you send from the RFC-822 From: of paypal.com you'd need to sign them both with "d=paypal.com". That means that those two mail streams would share the reputation of that d= field, and your transactional mail would risk being blocked due to the spam you send.

(There are some obvious fixes that could be applied to ADSP to reduce that problem, but I'll leave that as an exercise for a different thread).

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Wed, 15 Sep 2010 12:12:15 -0400

McDowell, Brett wrote:

> BTW, one thing I think we can agree on and find value from 
> in these pre-deployment email discussions is terminology.  I ran 
> into a problem at the last MAAWG during a panel discussion where 
> my understanding of "3rd-party signature" is what someone else meant 
> by "2nd-party signature".  What is the real definitions of 
> "1st-party", "2nd-party" and "3rd-party" signatures in the context 
> of DKIM and ADSP, i.e. in the context of i= and d= and from: values?

Brett,

I can't speak of how "2nd party" is used within DKIM framework, but 
you can  review RFC 5016 with defines the terminologies for POLICY.

                      Requirements for a
     DomainKeys Identified Mail (DKIM) Signing Practices Protocol

              http://tools.ietf.org/html/rfc5016

2.  Definitions and Requirements Language

    o  Domain Holder: the entity that controls the contents of the DNS
       subtree starting at the domain, either directly or by delegation
       via NS records it controls.

    o  First Party Address: for DKIM, a first party address is defined to
       be the [RFC2822].From address in the message header; a first party
       address is also known as an Author address.

    o  First Party Signature: a first party signature is a valid
       signature where the signing identity (the d= tag or the more
       specific identity i= tag) matches the first party address.
       "Matches" in this context is defined in [RFC4871].

    o  Third Party Signature: a third party signature is a valid
       signature that does not qualify as a first party signature.  Note
       that a DKIM third party signature is not required to correspond to
       a header field address such as the contents of Sender or List-Id,
       etc.

    o  Practice: a statement according to the [RFC2822].From domain
       holder of externally verifiable behavior in the email messages it
       sends.

    o  Expectation: an expectation combines with a practice to convey
       what the domain holder considers the likely survivability of the
       practice for a receiver, in particular receivers that may be more
       than one SMTP hop away.

    o  DKIM Signing Complete: a practice where the domain holder asserts
       that all legitimate mail will be sent with a valid first party
       signature.

---

From: "McDowell, Brett" <[email-masked]>
Date: Wed, 15 Sep 2010 10:18:39 -0600

(sorry Stephen, but I had to reply to this one)

> I think you're not reading carefully, and you're twisting Jeff's words and mine to a point that bears no resemblance to what either of us said.

As it turns out, you are completely correct and I withdraw that comment.  It just shows how entirely confused I was about what you and Jeff meant by 3rd-party signatures (which Jeff clarified in his response).  Jeff's definition of 3rd-party signature is entirely different from what I thought it meant (and what other experts have responded to me with off-list BTW).

I've taken this conversation off-list.  
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 15 Sep 2010 17:25:13 +0100

--On 14 September 2010 15:27:34 -0600 "McDowell, Brett" 
<[email-masked]> wrote:

> That's been my #1 lesson this year (I'm new to IETF).

I note that you've also returned with a non-discardable paypal email 
domain. :) So, Paypal have collectively learned that separating mailstreams 
is important (or, at least helpful) when using ADSP. It makes all the 
discussion of ADSP/MLM incompatibility moot, if you can route around it 
like that.

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

---

From: Graham Murray <[email-masked]>
Date: Wed, 15 Sep 2010 19:11:15 +0100

"McDowell, Brett" <[email-masked]> writes:

> BTW, one thing I think we can agree on and find value from in these
> pre-deployment email discussions is terminology.  I ran into a problem
> at the last MAAWG during a panel discussion where my understanding of
> "3rd-party signature" is what someone else meant by "2nd-party
> signature".  What is the real definitions of "1st-party", "2nd-party"
> and "3rd-party" signatures in the context of DKIM and ADSP, i.e. in
> the context of i= and d= and from: values?

To apply the 'normal' and commonly used in other contexts (eg contracts
and insurance) definitions.

The sender is the first party.

The recipient(s) jointly and individually are the second party.

Anyone else is a third party.

I have never heard anyone talk about 2nd party signatures.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 15 Sep 2010 19:32:52 -0000

>I have never heard anyone talk about 2nd party signatures.

S/MIME has 2nd party signatures, where you encrypt something using the
recipient's public key.  ADSP has no equivalent.

And as Steve noted, DKIM has no Nth party signatures for any N, so
let's stop here.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 15 Sep 2010 12:54:38 -0700

> recipient's public key.  ADSP has no equivalent.

Signatures means authentication.  authentication uses the sending-side private 
key.  Receive-side public keys are used for privacy, not authentication.

Here's where you get to supply the point that a) defines 2nd party sig for 
s/mime, and b) makes clear that I'm wrong...

As of now, I've no idea what your statement about S/MIME means.

d/
-- 

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Sep 2010 19:57:31 +0200

Hi J.D.,

What an interesting conversation you've stoked! 

> Continuing to argue these same points over and over is disrespectful of our colleagues both on and off this list, and of the IETF process.

Without getting all emotional about all of this, I would think first
things first.  If we could sort the identification of the {user domain
entry point or enterprise root/top level or whatever you want to call
that thing above .ac.uk or .com or sf.ca.us} domain, and it is something
that we would like to have, then that will offer us a number of
interesting opportunities.  Thanks to Dave Crocker for not letting that
one go.  It's work that needs doing, albeit perhaps not here, even
though we may benefit.  FWIW I have some thoughts as to how this might
go, if some people are interested.  I will *not* be in Beijing to
discuss them, but would be happy to do so if folks want to hear about them.

Eliot