Subject: [ietf-dkim] draft-levine-dkim-adsp-00

From: John Levine <[email-masked]>
Date: Sat, 24 May 2008 00:54:40 -0400 (EDT)

This is a revision of draft-ieft-dkim-ssp-02, our proposal for ssp-03.

I think it's fair to say it represents a consensus of Steve Atkins, Jon 
Callas, Dave Crocker, Tony Finch, Michael Hammer, Ellen Siegel,
Wietse Venema, and me.

The major changes since -02 are:

* change name to ADSP
* take out the tree walk
* don't try to define our own existence check, but do make ADSP apply only
   to domains that exist
* clean up cruft related to stuff taken out

R's,
John

---------- Forwarded message ----------
Date: Fri, 23 May 2008 21:22:57 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>

A new version of I-D, draft-levine-dkim-adsp-00.txt has been successfuly submitted by John Levine and posted to the IETF repository.

Filename:	 draft-levine-dkim-adsp
Revision:	 00
Title:		 DKIM Author Domain Signing Practices (ADSP)
Creation_date:	 2008-05-23
WG ID:		 Independent Submission
Number_of_pages: 19

Abstract:
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 they sign their outgoing mail, and
how other hosts can access those records.

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 23 May 2008 22:43:31 -0700

> The major changes since -02 are:

The draft and an rfcdiff between ssp-03 and levine-dkim-adsp-00 are posted at:

   <http://dkim.org/ietf-dkim.htm#working>

d/
-- 

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

---

From: Arvel Hathcock <[email-masked]>
Date: Sat, 24 May 2008 09:58:31 -0500

> * don't try to define our own existence check, but do make ADSP apply only

Your draft still contains a step 2 which defines an existence check.
I think this is perfectly acceptable but am wondering whether you 
intended to include it?

--SNIP--
    2.  The host MUST query DNS for an MX record corresponding to the
        domain (with no prefix).  This query is made only to check the
        existence of the domain name and MAY be done in parallel with the
        query made in step 1.  If the result of this query is an NXDOMAIN
        error, the domain does not exist and the algorithm terminates.
--END SNIP--

Perhaps there isn't a conflict here anymore?  Your step 2 is perfectly 
acceptable to me.

However, your section 4.4 is less clear than the original draft because 
you're using simply "domain" in several places rather than "Author 
Domain" which therefore could introduce the question "which domain are 
they talking about".

Arvel

---

From: Douglas Otis <[email-masked]>
Date: Sat, 24 May 2008 08:10:21 -0700

> Domain" which therefore could introduce the question "which domain are

There has also been a change to use Author instead of Author Domain,  
which is simply wrong.  In addition, this still includes the  
transactions made against parent domains.

-Doug

---

From: John Levine <[email-masked]>
Date: Sat, 24 May 2008 11:20:52 -0400 (EDT)

That snip isn't in the draft I posted.  Any chance you're looking at the 
wrong version?

On Sat, 24 May 2008, Arvel Hathcock wrote:

> I think this is perfectly acceptable but am wondering whether you intended to 
> include it?
>
> --SNIP--
> you're using simply "domain" in several places rather than "Author Domain" 
> which therefore could introduce the question "which domain are they talking 
> about".
>
> Arvel
>
>
>
>
>

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: Arvel Hathcock <[email-masked]>
Date: Sat, 24 May 2008 10:49:27 -0500

> That snip isn't in the draft I posted.  Any chance you're looking at
 > the wrong version?

 >  <http://dkim.org/ietf-dkim.htm#working>

That link takes you to a page where there are other links to your -00 
draft and rfcdiff.  Maybe that page isn't updated yet?

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Sat, 24 May 2008 09:22:17 -0700

apologies.  it pointed to the wrong document.  it's now fixed.

d/

-- 

   Dave Crocker

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 24 May 2008 18:23:29 +0200

Arvel Hathcock wrote:
 
> I'm looking at the thing Dave posted a link to

Apparently he forgot a critical "D" in asp vs. adsp.  Check out

<http://tools.ietf.org/rfcdiff?url1=http%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-ietf-dkim-ssp&url2=http%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-levine-dkim-adsp-00&difftype=--html>

Depending on your environment try "--hwdiff" instead of "--html".

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Sat, 24 May 2008 17:57:51 +0200

For the record, I think this is a bad idea, as it forces more steps to 
bringing us to closuNow we will have people posting issues on a 
replacement draft.  It also circumvents the issue tracking that has 
taken place.   I also find it remarkable, sad, and offensive to other 
authors that a co-author of the working group draft couldn't  get alone 
either with his fellow authors or use the working group process to 
propose changes he would like, but instead went backroom dealing.

> The major changes since -02 are:
There never was a tree walk.  You know this, and your and others' 
repeated use of this term has been misleading, and perhaps demonstrates 
a fundamental misunderstanding that you yourself have.

> * don't try to define our own existence check, but do make ADSP apply only

AND this is not what the working group has agreed upon AND it is poor 
protocol design to underspecify a behavior.  In general this approach 
that you folks are taking leads to interoperability problems and 
inexplicable behavior.  Taken to extreme one could simply define the 
ADSP record format.  What we are left with now is some vague hope that 
people will be able to intuit anomalous behavior based on what software 
is running on the recipient's end.  We have experience with that in the 
browser world.  I don't care to recreate such a fiasco.  Do you?

Eliot

---

From: "Al Iverson" <[email-masked]>
Date: Sat, 24 May 2008 11:52:29 -0500

> propose changes he would like, but instead went backroom dealing.

I have to agree with Eliot here. I'm disappointed by the private
sausage making party.

> browser world.  I don't care to recreate such a fiasco.  Do you?

Arvel suggested a straw poll regarding whether or not the NXDOMAIN
check should be removed or not. Along with him, I would like to know
what the numbers are for both sides in this debate. I strongly second
his request.

I think that might be a bit better than just publishing a new draft
spec with it yanked out, based on a small subset of participants only,
based on a back room deal.

Regards,
Al Iverson

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com -- Chicago, IL, USA
Remove "lists" from my email address to reach me faster and directly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Sat, 24 May 2008 09:58:00 -0700

Al Iverson wrote:
> check should be removed or not. 

The phrasing of the query for a poll is a challenge, here.

A specific query, only for "whether or not the NXDOMAIN check should be 
removed or not" is particularly limited.  And the difference between ssp-03 
and draft-levine-dkim-adsp is not as simple as 'removing" NXDOMAIN.

What do you feel are the technical deficiencies of draft-levine-dkim-adsp?

d/

-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Sat, 24 May 2008 19:16:07 +0200

> What do you feel are the technical deficiencies of draft-levine-dkim-adsp?

While I obviously answered this question it is still the wrong 
question.  The RIGHT question is "What do you think are the technical 
deficiencies of the working group draft?"  That is - unless you want to 
set us back ANOTHER five months.

Eliot

---

From: Arvel Hathcock <[email-masked]>
Date: Sat, 24 May 2008 12:52:18 -0500

> What do you feel are the technical deficiencies of draft-levine-dkim-adsp?

The biggest problem of course is that it's not a working group document.

If we're to start working now on other documents then Doug Otis is ahead 
of you guys in line since he's had a replacement offering for some time. 
  Let's not start down that road.

Let's just get on with having the chairs conduct a straw-poll.  The 
question is pathetically simple:  Should the next draft of the working 
group document retain the NXDOMAIN check or not?  Yes or no.  This is 
really easy folks.

If there is insufficient consensus either way then we can either give up 
or work toward some compromise language.

-- 
Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Sat, 24 May 2008 13:10:13 -0500

> The phrasing of the query for a poll is a challenge, here.

Nope.  The question is on the removal of the NXDOMAIN step from the 
working group draft.  One side wants that, the other side doesn't.  It's 
no more challenging than when we followed the exact same procedure for 
removal of the "tree-walk" step.  Both sides have explained their case 
and it's now time for the chairs to figure out where the consensus is 
(my opinion).

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Sat, 24 May 2008 11:37:24 -0700

Arvel Hathcock wrote:
> working group draft.  

That's one question, yes, but there are more.  While I'm not sure it captures 
the available choices, here's an attempt:

There really are two sets of choices:

Degree of requirement
---------------------

1. Make a domain 'validity' test mandatory.

2. Make a 'validity' test optional (SHOULD vs. MAY)

3. Remove a 'validity' test

Type of 'validity' test
-----------------------

1. NXDomain

2. RFC2821bis

I suspect there are more choices for type of test, but these are the two that 
are obvious.  Unfortunately each of the listed choices has some problems. In 
addition there is the problem that the industry already conducts these tests, 
but in a variety of ways.

Basically, the industry does not have a solid, de facto NXDomain standard.  It 
has a small number of common choices, but 'common choices' is different from 
'definitive, single choice'.  If this working group insists on defining a 
single, definitive test, then it is running some risks with industry adoption, 
since we are attempting to constrain existing practice.

The RFC2821bis test potentially has multiple queries, meaning higher overhead. 
But it is semantically deeper, with respect to validity for email-related use.

It also seems likely that the more definitively the working group attempts to 
specify (standardize) this particular test, the more it will be subject to 
review by the larger Internet email technical community, for architectural 
impact.  But, of course, that's just my own opinion.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sat, 24 May 2008 12:09:02 -0700

> apologies.  it pointed to the wrong document.  it's now fixed.

Folks,

I've added both inline and side-by-side versions of the rfcdiff output to the 
web page.

d/
-- 

   Dave Crocker

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 24 May 2008 21:15:36 +0200

Arvel Hathcock wrote:
 
> The question is pathetically simple:  Should the next draft of the´
> working group document retain the NXDOMAIN check or not?  Yes or no.

Yes.  There was no plausible or coherent argument against this check.
If receivers do this anyway they have a result in their cache, fine.

I'd like to see a WG ADSP draft without the old "parent domain" magic,
after that a PubReq, and maybe some fine tuning for Authentication-
Results if necessary.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Sat, 24 May 2008 12:27:20 -0700

> There really are two sets of choices:

ADSP is an extension showing the level of a domain's use of DKIM with  
SMTP.  Since this is being introduced into existing infrastructure,  
requests for ADSP records are therefore optional.  In addition,  
compliance with ADSP should not mandate more transactions than a  
receiving host finds merit in making.  ADSP can recommend a series of  
SMTP related checks using SHOULD to reduce the number of domains where  
an ADSP records would be required to preclude spoofing with otherwise  
non-SMTP sub-domains.

> 3. Remove a 'validity' test

To ensure interchange, ADSP MUST indicate which protocol has adopted  
DKIM.

-Doug

---

From: John Levine <[email-masked]>
Date: 24 May 2008 20:06:07 -0000

>If receivers do this anyway they have a result in their cache, fine.

Nobody I know of is arguing against checking to see if the domain
exists.  The question is whether ADSP should define what domain
existence means, or defer to other definitions.  Inventing our own
definition is, as I think I've said in other messages, a rather severe
case of mission creep.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Sat, 24 May 2008 14:26:34 -0700

On May 24, 2008, at 12:09 PM, Dave Crocker wrote:

> I've added both inline and side-by-side versions of the rfcdiff  
> output to the web page.

Dave,

Could you offer the same for:
  http://www.ietf.org/internet-drafts/draft-otis-dkim-adsp-02.txt

The HTML version is at:
  http://www.sonic.net/~dougotis/id/draft-otis-dkim-adsp-02.html

The diff between ssp-03 and this draft is at:
http://www.sonic.net/~dougotis/dkim/rfcdiff-ssp03-otis-adsp-02.html

This is similar to John's draft, but this draft limits ADSP to SMTP,  
and makes use of _normal_ RFC2821 validity checks.  No mission creep.

This draft also avoids restrictions on the DKIM identity parameters,  
since the _only_ relevant issue is whether a message should be signed  
by an Author Key Domain, and not whether the message affirms an  
Author's identity.  Non-essential identity requirements unnecessarily  
coerces author identity affirmation, erodes user privacy, and may  
break ADSP compliance.  Identity affirmation _must_ remain optional  
with or without ADSP.  Again, no mission creep.

Identity affirmation is evident whenever a DKIM signature's identity  
parameter can encompass an enclosed email-address.  Identity  
affirmation is fully independent of whether a message containing an  
Author Domain should have been signed by an Author Key Domain.   
Identity parameter restrictions by ADSP take DKIM beyond where the WG  
charter permitted, and may even require multiple signatures whenever  
an identity other than the Author is affirmed.  The signing domain  
should be free to decide on whose behalf the message is being signed  
without violating ADSP compliance.

Simply by making a requirement that a message containing an Author  
Domain be signed by an Author Key Domain, the Author Key Domain is  
able to curb fraudulent messages without also indicating the message  
is being signed on behalf of the Author.  Author identification is to  
be found with S/MIME or OpenPGP.  ADSP and DKIM should only ensure the  
Author Domain better controls SMTP acceptance of messages containing  
the Author Domain.  For whom the Key Domain signs on behalf of is  
their business.  ADSP should only be able to stipulate that a message  
containing an Author Domain should be signed by an Author Key Domain.

A definition of Author Key Domain is in this draft. For example, this  
also avoids references to "Alleged Author", as identity affirmation is  
_not_ the goal.

---

The relevance of this issue is important is better understood by  
reviewing a possible extension to ADSP.  While making this change,  
there also remains and error on the webpage http://www.dkim.org/ietf-dkim.htm#documents 
  that was mentioned when last seeing you in person.

Could you please correct the reference at:

http://www.dkim.org/ietf-dkim.htm#documents
,---
|Early SSP Proposals (replaced by draft-ietf-dkim-ssp)
|
|# DKIM Third-Party Authorization for Sender Signer Practices (TPA- 
SSP), draft-otis-dkim-tpa-ssp-00
'---

The draft-otis-dkim-tpa-ssp-00 never replaced nor was replaced by the  
ssp draft.  The draft's name has been updated and can be placed under:

Extensions to ADSP:
# DKIM Third-Party Authorization for Author Domain Signing Practices,  
draft-otis-dkim-tpa-adsp-00

  http://www.ietf.org/internet-drafts/draft-otis-dkim-tpa-adsp-00.txt

The HTML version is at:
  http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-adsp-00.html

-Doug

---

From: "Al Iverson" <[email-masked]>
Date: Sat, 24 May 2008 16:28:10 -0500

On Sat, May 24, 2008 at 1:10 PM, Arvel Hathcock <[email-masked]> wrote:
> Nope.  The question is on the removal of the NXDOMAIN step from the working
> group draft.  One side wants that, the other side doesn't.  It's no more
> challenging than when we followed the exact same procedure for removal of
> the "tree-walk" step.  Both sides have explained their case and it's now
> time for the chairs to figure out where the consensus is (my opinion).

I agree with Arvel.

Dave, I don't think this necessarily torpedoes what you and John are
trying to do. As mentioned to me, 10 of the 22 people who participated
in the past vote gave their approval for, or were involved in creation
of, this current draft. That's not a majority, but it's not far from
it. I think it might survive a vote.

The reason I am cranky about this is because it feels watered down and
only half-useful to avoid any specificity around the domain existence
check. I am worried that it will result in poor guidance for
implementation in software, and by extension, poor implementation in
software.

But, if that's what is carried by even a straw poll, that pretty much
settles it, and I'd get on board.

Best,
Al Iverson

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 24 May 2008 23:51:38 +0200

John Levine wrote:

> The question is whether ADSP should define what domain
> existence means, or defer to other definitions.

Saying what result NXDOMAIN means can't be seriously wrong.

RFC 4408 uses "rcode 3", not "NXDOMAIN".  If you like that
better it is okay, as defined in RFC 1035.  So let's add
RFC 1035 to the normative references, and be done with it.

Nobody wanted to "redefine" NXDOMAIN, this is just a name
for "rcode 3" in a header file.  

> Inventing our own definition is, as I think I've said in
> other messages, a rather severe case of mission creep.

Doug's proposal wrt q=mx would be mission creep, the stuff
that didn't make it into 2821bis, and ADSP isn't the place
to try it again, his proposal needs its own RFC.

If the q=mx recipe could be confused with more ambitious
concepts let's use another example, or no example at all:

Implementors are supposed to know how this works, and if
they don't know it they can read RFC 1035.

 Frank

---

From: Arvel Hathcock <[email-masked]>
Date: Sat, 24 May 2008 17:43:39 -0500

> 3. Remove a 'validity' test

'Validity' is your term.  The rest of us are debating existence in DNS.

 > Basically, the industry does not have a solid, de facto NXDomain
 > standard.

Since at least 1987 DNS standards have described NXDOMAIN completely and 
they tell us it's purpose and meaning as well as when and how we might 
expect to receive it.  This is good enough for me at least.

 > If this working group insists on defining a single, definitive test,
 > then it is running some risks with industry adoption, since we are
 > attempting to constrain existing practice.

How could anyone credibly attempt to constrain existing practice on the 
grounds that "Well now, you know, ADSP doesn't do it that way."  So 
what?  What ADSP defines for ADSP applies only to ADSP.

> impact.  But, of course, that's just my own opinion.

I guess this is meant to threaten the WG's work effort with something 
akin to a tax audit.

-- 
Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Sat, 24 May 2008 17:48:49 -0500

> definition is, as I think I've said in other messages, a rather severe

Nobody I know is trying to define what domain existence means.  This is 
done for us in the DNS RFC's in the form of NXDOMAIN.   All we want to 
do is use NXDOMAIN to avoid a rather severe and easily perpetrated 
exploit of an otherwise workable protocol.

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Sat, 24 May 2008 19:35:25 -0500

> settles it, and I'd get on board.

Let me be clear as well.  I'd also quickly get behind changing the 
existing draft concerning NXDOMAIN along the lines of what's been done 
in the levine draft should that be what's needed to move forward.

Arvel

---

From: [email-masked] (Wietse Venema)
Date: Sun, 25 May 2008 09:34:04 -0400 (EDT)

> or work toward some compromise language.

The least ambiguous ways to validate an author domain are a) get an
NXDOMAIN result for the author domain; b) talk to an authoritative
SMTP server for the author domain, which is obviously not practical.

DNS lookup per RFC 2821 section 5 provides only an approximation
of what author domains are valid: not every A/AAAA/whatever record
corresponds to a valid origin of email. So we might just as well
keep it simple and settle for the existing NXDOMAIN check.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Sun, 25 May 2008 13:53:11 -0700

On May 24, 2008, at 2:51 PM, Frank Ellermann wrote:

> John Levine wrote:
>
>> The question is whether ADSP should define what domain existence  
>> means, or defer to other definitions.
>
> RFC 4408 uses "rcode 3", not "NXDOMAIN".  If you like that better it  
> is okay, as defined in RFC 1035.  So let's add RFC 1035 to the  
> normative references, and be done with it.
>
> Nobody wanted to "redefine" NXDOMAIN, this is just a name for "rcode  
> 3" in a header file.

Adopt the language found in RFC2821, or perhaps reference the relevant  
section.  To offer a strategy for minimizing undesired traffic that  
might occur when dealing with spoofed domains while verifying DKIM and  
ADSP, emphasis should be placed on checking MX records first.  MX  
first is currently defined in RFC2821 for discovering SMTP servers.

>> Inventing our own definition is, as I think I've said in other  
>> messages, a rather severe case of mission creep.
>
> Doug's proposal wrt q=mx would be mission creep, the stuff that  
> didn't make it into 2821bis, and ADSP isn't the place to try it  
> again, his proposal needs its own RFC.

This is to verify the Author Domain offers records required to support  
SMTP.  The first record sought by RFC2821 is the MX record.  The otis- 
dkim-adsp-02 draft includes notes to indicate how ADSP discovery  
_might_ change whenever SMTP mandates MX records for the acceptance of  
public message exchanges.  This change would minimize possibly  
dangerous levels of undesired traffic directed against non-SMTP  
domains due to email-address spoofing.  Even if that change is never  
needed, this draft clearly stipulates the ADSP related domain has  
adopted DKIM for SMTP.

Why is defining the protocol adopting DKIM in the practice assertion  
mission creep?  Defining the protocol adopting DKIM is absolutely  
essential, but this is not done in Jim's or John's drafts.  Not  
defining the protocol might prove disruptive when a domain's ADSP  
assertions are applied against protocols that have as yet not adopted  
DKIM for what might become a range of messaging protocols.  It is far  
too early to make assumptions about which protocols will or will not  
implement DKIM.  Since declaring the protocol has been excluded from  
the ADSP record, it is essential and necessary to define the  
_specific_ public messaging protocol in the draft itself.  That is not  
mission creep, that is a must.

> If the q=mx recipe could be confused with more ambitious concepts  
> let's use another example, or no example at all:
>
> Implementors are supposed to know how this works, and if they don't  
> know it they can read RFC 1035.

Typically ADSP records will not be discovered for many years and  
perhaps decades to come.  Discovering whether an Author Domain exists  
offers less value than knowing whether resource records essential for  
SMTP exist.  Even more importantly, when limited to domains publishing  
SMTP discovery records, the number of domains needing to publish ADSP  
records is significantly reduced.

Such testing is not mission creep.  The test is simply based upon SMTP  
being the focus of ADSP assertions.  Although DKIM can be used by many  
different protocols, what other public message exchange protocol is to  
be assessed by ADSP assertions?  Not indicating the public exchange  
protocol being protected by ADSP would be remiss.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Sun, 25 May 2008 18:21:06 -0400

> The biggest problem of course is that it's not a working group document.

And a bigger problem is that no one spoke up, or those who did were 
quickly shun including cursed out of the group.  Just as Al stated - 
"private sausage making" party.   It was nothing less than shameful coup 
d'etat and the chairs well, unfortunately, allowed it to happen.  It 
leaves a bitter taste in the IETF process for those are new at it.

-- 
Sincerely

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 May 2008 11:30:36 +0100

> or work toward some compromise language.

I plan to start such a strawpoll (*) this week. I just want to check the
wording of the question with the authors of draft-ietf-dkim-ssp first
to make sure they're happy they'll be able to take action based on
whatever results we get.

Stephen.

(*) Actually, a couple of people have asked me to use the term
"consensus call" instead of strawpoll. I don't mind either way, but
just so everyone's clear, I think these amount to the same thing
in a case like this where we've some specific text we do or don't
want to keep/change.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 26 May 2008 11:18:14 +0100

On Sat, 24 May 2008 22:26:34 +0100, Douglas Otis <[email-masked]>  
wrote:

> by an Author Key Domain,...

WRONG! It MUST be signed by *every* Author Key Domain (in the event there  
are severl authors with different domains in the From header).

> Domain be signed by an Author Key Domain, the Author Key Domain is
                       ^^
                      each

-- 
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, 26 May 2008 11:21:12 +0100

> group document retain the NXDOMAIN check or not?  Yes or no.  This is

It is no earthly use asking whether the NXDOMAIN check should be removed  
without at the same time stating what is intended to be put in its place,  
since the answer to the question may be very dependent on that.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 26 May 2008 11:26:33 +0100

On Sun, 25 May 2008 21:53:11 +0100, Douglas Otis <[email-masked]>  
wrote:

> being the focus of ADSP assertions.

But SMTP IS NOT, and CANNOT BE the focus of ADSP assertions, simply  
because a message may be gatewayed in and out of SMTP umpteen times during  
its journey from original sender to ultimate recipient.

The true "focus of ADSP assertions" is "all those protocols which rely  
upon DSN as a part off their addressing mechanisms".

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 May 2008 00:28:58 -0700

On May 26, 2008, at 3:18 AM, Charles Lindsey wrote:

>> This draft also avoids restrictions on the DKIM identity  
>> parameters, since the _only_ relevant issue is whether a message  
>> should be signed by an Author Key Domain,...
>
> WRONG! It MUST be signed by *every* Author Key Domain (in the event  
> there are severl authors with different domains in the From header).

Review Section 2.4 definition of Author Key Domain and Section 2.5 the  
definition of Author.  The check does not depend upon an identity  
parameter nor limit the check to single Author Domain.

It could be more productive to recommend what text in the draft should  
change.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 May 2008 00:32:20 -0700

On May 26, 2008, at 3:26 AM, Charles Lindsey wrote:

>> Such testing is not mission creep.  The test is simply based upon  
>> SMTP being the focus of ADSP assertions.
>
> because a message may be gatewayed in and out of SMTP umpteen times  
> during its journey from original sender to ultimate recipient.

Messages containing addresses unrelated to SMTP will always  
potentially conflict with ADSP.  The otis-dkim-adsp-02 draft makes a  
statement:
,----
|Application of ADSP by Mail User Agents (MUAs) might need
|to be offered as an option, to accommodate messages exchanged
|over different public protocols.
'----

Perhaps this text should be expanded to include both protocol gateways  
and MUAs.  A receiving host should be able to decide what (non-SMTP)  
message source it will accept over SMTP.  In addition, it should not  
be an insurmountable hardship that, for a message address to be  
acceptable for SMTP, the domain needs to support SMTP.

It seems rather ludicrous to claim address-spoofing is to be  
prevented, and then not define what protocol generates and accepts the  
protected address.  With either John's or Jim's versions, the protocol  
adopting DKIM is never defined.  As a result, these issues have been  
ignored and definitely not resolved.

> The true "focus of ADSP assertions" is "all those protocols which  
> rely upon DSN as a part off their addressing mechanisms".

There is no assurance that an undefined protocol will use DNS, since  
there are already such protocols available.  The draft should indicate  
limitations imposed when adopting ADSP.  Due to high levels of abuse,  
any gateway left open is likely to be abused once acceptance is  
otherwise restricted.  This issue can not be glossed over by  
suggesting other protocols will also be using DNS.  How does that even  
help?  What do you see as the goal of ADSP?

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 May 2008 12:44:17 -0700

Folks,

People have reached a level of saturation and exhaustion on the question of
doing an existence/validity check, to see whether a name is registered [and
intended for email use.]

Over the last couple of days I've been having a private exchange, trying to
lay out the logical underpinnings to the arguments for and against such a
test, stepping through requirements and challenges for this, within the
context of ADSP.

I'm posting a highly edited version of the two sides, here, in the hope that 
we can look at details, rather than just reiterating our summary judgements 
about how essential or irrelevant the test is.

Since I'm totally biased, I'm not likely to create the "pro" side very well,
so I've tried to use the other participant's statements, and believe my
editing has not altered their intent. Still, if you think I've gotten the
"pro" side wrong, blame me, but also tell me how to fix it.

PRO
---

> ADSP is supposed to arm the domain owner with a means of protecting his 
> *name space* from unauthorized use in an email From: header.  ADSP is 
> supposed to arm the mail receiver with a means of detecting unauthorized 
> domain use in an email From: header.

> The domain owner will publish ADSP records for everything he possibly can. 
> However, it is impossible for him to publish ADSP records for host names 
> within his name space which do not exist.  It is ridiculous to expect a 
> domain owner to put an ADSP record everywhere he possibly can while knowing
>  at the same time that an attacker can completely by-pass this by just 
> making up an arbitrary host name.

> We're saying it's important for the algorithm to distinguish between "No 
> ADSP due to the domain owner's failure to provide it" and "No ADSP because 
> the domain is bogus and ADSP couldn't have been provided by anybody."

> It's mission-critical to prevent ADSP from complete uselessness through 
> affixing an arbitrary host value to a domain that otherwise has done 
> everything ADSP allows to protect itself. Please understand that an 
> attackers use of "[email-masked]" *still reflects badly* on
> paypal.com and the domain owner of paypal.com would definitely put a stop
> to that if he could.

> If an NXDOMAIN check is not performed _THEN_ it becomes trivial for an 
> attacker to circumvent ADSP.

> It's certainly meaningful protection to prevent abuse through use of 
> arbitrary host names.

CON
---

I suspect a critical issue is the exact meaning of "name space". As used
here, it appears to refer to everything under the 'root' of an owner's
domain.  That is, it is meant to cover an entire sub-tree, rather than to a
specific, single, registered string.

For any given (specific) domain name, the owner always has the ability to
register an ADSP record.  This protects that specific name. By publishing an
ADSP record the owner says "Every legitimate message with this exact domain
name string in the From: field is signed with this same, exact domain string".
Any use of that name in the From: field without a signature will be detected.
An attacker cannot bypass the direct protection of that specific name. Any
message that does not contain that signature is detected as problematic.

What this means is that direct ADSP registration protects all registered names
that the domain owner has chosen to protect. So, the concern behind the
existence test (NXDomain or the like) is not whether the domain owner chose to
protect any particular name but whether the domain owner is using it.

The existence check sets the goal of protecting unused names under a some
domain name "root".

The "still reflects badly" statement asserts that such unauthorized use of an 
unregistered name will hurt the reputation of an organization's "root" domain. 
The assumption is that a specific domain name and all of the names under it 
will share the same reputation.

This is an eminently intuitive and reasonable concern.  If paypal.com has a 
reputation, it is certainly reasonable to assume that phisher.paypal.com will 
share it. However the real-world impact of such generalization of reputation 
will be to defeat one of the major benefits of using domain names: 
Differential reputations within a domain.

We *want* different reputations for transactions.paypal.com and
newsletter.paypal.com and corporate.paypal.com.  Remember that these names
that are used to sign with DKIM are voluntarily chosen by the signer.  If they
use different strings, they intend different assessment. If we assume an 
inheritance, tree-based model for reputation, such as with paypal.com, we 
eliminate this very useful ability to discriminate among different mail 
streams coming from an organization.

This design ability with domain name-based reputation exactly matches the data
we have seen posted to the mailing list about actual reputation usage: 
Reputation data for IP Addresses covers ranges, yes. But the statements about
domain name use say they are tied to a specific, complete name, not a string
that is the root of a sub-tree.

In terms of the affirmative, proactive model of DKIM and ADSP, seeking to
protect unregistered names creates is, therefore, wasted overhead.

An existence query might be worthwhile in terms of other concerns and models,
but it has nothing to do with the scope of this working group.  Worse, it sets
entirely inaccurate expectations for DKIM and ADSP.

OK... start shooting.

d/

ps.  The above does not deal with an important additional test:  If there is 
to be a test, given that there is a range of established industry practice, 
how is this working group to define a particular standard that will appeal to 
the industry?

-- 

   Dave Crocker

---

From: "J D Falk" <[email-masked]>
Date: Wed, 28 May 2008 17:01:22 -0400

> doing an existence/validity check, to see whether a name is registered [and

*agree*

> OK... start shooting.

I don't care about the existence/validity check.  In the real world, that
check already happens (in most cases) before any authentication checks, so
it doesn't matter to me and is unlikely to matter to anyone else outside of
the IETF whether that query is mentioned in the ADSP draft or not.

On the other hand (which may not even be connected to the first hand),
there's clearly a strong desire for some domain owners to be able to assign
the same ADSP to everything within their namespace -- and there are clearly
real-world cases where it's appropriate to do so.

I do, however, see a problem with making it the default.  Borrowing Dave's
examples, transactions.paypal.com and newsletter.paypal.com and
corporate.paypal.com are different entities operated by different
departments with different business logic.  One or more may even be
outsourced.  The default should NOT be to tie those together.

On yet a third hand, many verifiers will probably choose not to walk the
tree back to some undefined point.  We can call it SHOULD, but we can't call
it MUST.

So, my proposal:

1. flip a coin at MAAWG in a couple weeks (no reason to wait for IETF 72) to
decide whether to mandate an existence/validity check;

2. add an appropriately named flag to ADSP to allow domain owners to say
"this same policy applies to everything within this namespace," with
appropriate warnings that verifiers may ignore it.

-- 
J.D. Falk
Return Path

Work with me!
http://www.returnpath.net/careers/

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 May 2008 15:07:09 -0700

On May 28, 2008, at 12:44 PM, Dave Crocker wrote:
> PRO
> ---
>
>> ADSP is supposed to arm the domain owner with a means of protecting  
>> his *name space* from unauthorized use in an email From: header.  
>> [...]  If an NXDOMAIN check is not performed _THEN_ it becomes  
>> trivial for an attacker to circumvent ADSP.

Only determining whether a domain exists to confirm a legitimate lack  
of an ADSP record prohibits use of wildcards by other protocols.  SMTP  
is not the only reason DNS is used.  As you indicated initially, the  
test is to verify whether a domain might support SMTP.  This can be  
confirmed by checking the existence of MX or A records, where of  
course the domain would be disqualified when it does not exist (As it  
would for RFC2821).  Some companies use internal exchanges using lists  
within private name space.  Even the minimal requirement that a domain  
exists within DNS requires a means to make exceptions.  ADSP imposes  
the same need.

> CON
> ---
>
> I suspect a critical issue is the exact meaning of "name space". As  
> used here, it appears to refer to everything under the 'root' of an  
> owner's domain.  That is, it is meant to cover an entire sub-tree,  
> rather than to a specific, single, registered string.

Parent domain would be a better term than "root".

> The existence check sets the goal of protecting unused names under a  
> some domain name "root".

Disagree.  Checking for evidence of SMTP support prevents domain  
spoofing independent of any parent domain.  This check will not convey  
any parent domain related policies.

[...]

> The assumption is that a specific domain name and all of the names  
> under it will share the same reputation.

The assumption is customers will recognize a parent domain and believe  
a message containing an email-address within the parent domain is  
equally controlled by the parent domain.

It seems both you and Jim's SSP draft have a concept of identities  
useful for reputation confused with ADSP records and DKIM identity  
parameters.  Only the DKIM key domain can be safely bound to a  
reputation.

> newsletter.paypal.com and corporate.paypal.com.  Remember that these  
> names that are used to sign with DKIM are voluntarily chosen by the  
> signer.  If they use different strings, they intend different  
> assessment. If we assume an inheritance, tree-based model for  
> reputation, such as with paypal.com, we eliminate this very useful  
> ability to discriminate among different mail streams coming from an  
> organization.

Being able to assert the practice of a domain is independent of any  
domain reputation.  Only when a common Key Domain is used, would  
reputations be shared.  The use of common Key Domains is completely  
within the control of parent domains and is fully independent of the  
ADSP practice assertions made by Author Domains (when these differ).   
This argument is flawed since it is based upon a false premise.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 May 2008 15:20:21 -0700

On May 28, 2008, at 2:01 PM, J D Falk wrote:

> So, my proposal:
>
> 1. flip a coin at MAAWG in a couple weeks (no reason to wait for  
> IETF 72) to decide whether to mandate an existence/validity check;

MAAWG is not an open forum.

> 2. add an appropriately named flag to ADSP to allow domain owners to  
> say "this same policy applies to everything within this namespace,"  
> with appropriate warnings that verifiers may ignore it.

There is already a flag saying just the opposite.  Such a construct,  
lacking any recommended strategies, might induce receiving hosts to  
walk up domain trees.  Such behaviour could lead to serious problems  
beyond the control of those concerned only with sending email.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 May 2008 09:48:46 +0200

Hi J D,
> appropriate warnings that verifiers may ignore it.

How does a receiver determine the appropriate source of authority if an 
ADSP record does not exist for the actual [2]822.From line?

Eliot

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 29 May 2008 11:34:36 +0100

On Wed, 28 May 2008 20:44:17 +0100, Dave Crocker <[email-masked]> wrote:

> names
> that are used to sign with DKIM are voluntarily chosen by the signer.

In that case, paypal.com can easily publish a strong ADSP record for  
transactions.paypal.com and weaker ADSP records for newsletter.paypal.com  
and corporate.paypal.com. The important thing is to ensure that  
[email-masked] is treated as strong rather than as weak. If we  
don't protect that domain, then every phisher on the planet will promptly  
use it.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 May 2008 11:42:15 +0100

Folks,

In case anyone's unclear.

This (and Doug's document too) are not WG drafts, so we shouldn't
spend time/effort discussing their details on the list since we
do have a WG draft which we want to finish.

Stephen.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 May 2008 12:51:53 +0200

Dave Crocker wrote:
>   However the real-world impact of such generalization of reputation

I think the keyword in the above paragraph is "assume".  People pro 
assume that there is some relationship of some form between the parent 
and child domain.  It is a weak relationship at best because the mere 
existence of an ADSP record obviates the need for such a check.

The above quoted text  makes assumptions about how reputation systems 
will work into the future.  One thing we hear a lot about in other 
contexts is reputation portability.  If paypal were to create a new 
service, it would want to borrow from its reputation.  An ability to 
express some means at the domain level would provide for that 
portability.  Absent that it has to go through the whole rigmarole all 
over again.

But somewhere here I believe we've digressed into another issue...

> that is the root of a sub-tree.

There is almost nothing there, and the field is nascent.

Eliot

---

From: John Levine <[email-masked]>
Date: 29 May 2008 14:17:30 -0000

> One thing we hear a lot about in other contexts is reputation
> portability.  If paypal were to create a new service, it would want
> to borrow from its reputation.  An ability to express some means at
> the domain level would provide for that portability.  Absent that it
> has to go through the whole rigmarole all over again.

Well, you know, I think it's convenient for the front and back doors
of my house to share the same key, but that doesn't mean that I also
think that key should unlock every door in the state of New York.

One of the design points of DKIM is that signatures can be from any
domain you control, and that a message can have multiple signatures.
If you want a bunch of mail to share the same reputation, sign it all
with the same domain.  If the From: domain in some or all of the mail
is something else and you want to use ADSP, also sign it with the
From: line domain.  If you want an existing domain's reputation to
port to a new one, maybe you should sign with both for a while.  This
is how we've expected DKIM to work all along.

Reputation portability is indeed important, but I don't see why one
would want to implement it by default fuzzy domain matching, with all
the phish vulnerabilities that opens up, particularly when DKIM
already provides straightforward workable ways to do it.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 May 2008 16:35:27 +0200

> is how we've expected DKIM to work all along.

ADSP is all about what happens when there *isn't* a signature.  How do 
you determine the scope of the policy?  No enterprise on earth would say 
that they want to have thousands of touch points for that.  That's been 
my point.  So I think we've gotten off track here.  And perhaps the best 
approach is for us to find a room at MAAWG and talk this out.

> already provides straightforward workable ways to do it.

Why do you say the matching is fuzzy?  Again, we're talking about the 
case where the signature is not there.

Eliot

---

From: John Levine <[email-masked]>
Date: Thu, 29 May 2008 10:58:17 -0400 (EDT)

> ADSP is all about what happens when there *isn't* a signature.  How do you 
> determine the scope of the policy?  No enterprise on earth would say that 
> they want to have thousands of touch points for that.

Of course not.  You treat mail from [email-masked] the same 
way you treat mail from [email-masked], most likely with great 
scepticism.  You can't blacklist your way out of the lookalike domain 
problem; you can only whitelist the domains you have some reason to trust.

> And perhaps the best approach is for us to find a room at MAAWG and talk 
> this out.

If you want.  But it's still not going to change the dismal fact that you 
can't blacklist your way out of the lookalike domain problem.

> Why do you say the matching is fuzzy?  Again, we're talking about the case 
> where the signature is not there.

I get a lot of mail from cisco.com, and I have an opinion about mail from 
that domain.  ADSP might even help me refine my opinion about mail from 
cisco.com that doesn't have a signature.  But whatever my opinion about 
cisco.com is, it does not extend to other domains that resemble cisco.com, 
even those domains that happen to contain the string cisco.com in them 
somewhere.  That's the fuzzy matching nobody's going to do.

As I've been saying over and over, there is no reason to give subdomains 
the same mail reputation as a parent domain, and a lot of reasons 
NOT to do so.  If you want to share reputations, DKIM signatures let 
you do so by sharing signing domains.

R's,
John

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 29 May 2008 15:39:06 +0000

> PRO

<snip>

> > paypal.com and the domain owner of paypal.com would definitely put a stop

ADSP doesn't require reputation, so I think the above is out of scope.

> CON

<snip>

> will share the same reputation.

Again ADSP doesn't require reputation so I don't see this as a valid
CON. Are there any other objections to the other PROs that were listed?

> protect unregistered names creates is, therefore, wasted overhead.

This is going with the assumption that such checks were done beforehand.
Would there be less objection if the existence check was optional IF
such test was done by a previous component?

> entirely inaccurate expectations for DKIM and ADSP.

If ADSP was the only component done in conjunction with SMTP, would the
above statements still be true?

The only expectation I have for DKIM is it provides a verifiable
identity. Nothing more. Does DKIM seek to prevent other protocols from
using this identity as they see fit?

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 29 May 2008 15:59:55 +0000

On Thu, 2008-05-29 at 12:51 +0200, Eliot Lear wrote:

<snip>

> If paypal were to create a new 

I believe the above is off topic. However, if paypal was smart, it would
of signed its messages with a d= parameter that doesn't match any domain
currently used in their email, say d=corp.rep.paypal.com.

If they wanted to provide separate reputations for each service and be
able to take advantage of a established reputation, they'd sign twice:

d=corp.rep.paypal.com
...
d=123.rep.paypal.com

AND if they wanted ADSP, they'd sign 3 times.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 29 May 2008 09:20:40 -0700

John Levine wrote:
>> to borrow from its reputation.  
...
> already provides straightforward workable ways to do it.

Eliot,

Typical discussions about reputation portability have been based on use of IP 
Addresses.  The need for portability is due to being forced to use different 
IP Addresses.  Using domain names as identifiers changes the entire game. For 
one thing, it permits the reputation to be based on a far more stable identifier.

To whatever extent we want reputations to be able to be "portable" we need to 
make sure it does not conflict with desires to keep them separate.

d/
-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 May 2008 19:40:51 +0200

> one thing, it permits the reputation to be based on a far more stable identifier.

And of course I agree.

> make sure it does not conflict with desires to keep them separate.

And I agree as well.

Eliot