Subject: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree

From: Dave Crocker <[email-masked]>
Date: Sun, 06 Apr 2008 23:06:25 -0700

Folks,

This issue encompasses some others, but I believe it is more basic and therefore 
informs the others and therefore needs to be resolved separately:

    There is a basic difference between trying to protect a single domain name, 
versus trying to protect an entire sub-tree.

1.  The DNS was not designed with sub-tree operators.  The wildcard mechanism is 
a very narrowly-defined capability and is useless in the face of 
underscore-based naming, since the underscore node really defines an attribute 
of the domain name it is under, rather than defining a true "name".

     What this leaves us with is attempting to invent mechanisms that turn out 
to do only a partial job, at best.

2.  Some of the sub-tree effort is for administrative convenience.  Some is for 
expanded semantics.

     It's not clear that the specification is clear about this distinction.

     It is not clear that the specification is clear about the motivations that 
make it mandatory to add sub-tree mechanisms to the specification.

3.  At least one of the sub-tree mechanisms is attempting to glean information 
from the absence of publisher action.  Let me explain:

     I believe the desire with checking the A record is similar to the idea 
behind having ADSP in the first space.

     That is:

         a) DKIM is for declaring the presence of an accountable identity.  If a 
signature is present, you know something.  If it is absent, you know nothing extra.

         b) ADSP attempts to tell you something, in the absence of a signature. 
It does that by defining something else that must be present.  If the ADSP 
record is present, you know something.  If it is absent, you know nothing extra.

         c) Checking for the presence of an A record is intended to try tell you 
something in the absence of an explicit action by the domain owner.  That's it's 
flaw: It is intuiting ADSP information from non-ADSP action.

     While there is nothing wrong with checking the A record, it's semantics 
have literally nothing (directly) to do with ADSP.

All of the above is of course implies some specific actions, but for this note, 
my real goal is to get much more explicit discussion and consensus about the 
difference between protecting a single domain name, versus protecting a tree of 
names, and to get consensus about each of these as separable goals.

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: Mon, 07 Apr 2008 09:06:36 +0200

Dave, Chairs,

Why isn't this a duplicate of Issue 1402 
<https://rt.psg.com/Ticket/Display.html?id=1402>?  By my recollection, 
this topic alone has been discussed at at least two - and possibly three 
- working group meetings.  Please advise.

Eliot

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 7 Apr 2008 09:23:32 +0200

Dave Crocker wrote:
 
> I believe the desire with checking the A record is similar to
> the idea behind having ADSP in the first space.

I don't understand this, the I-D does not talk about A records.

> Checking for the presence of an A record is intended to try
> tell you something in the absence of an explicit action by
> the domain owner.  That's it's flaw: It is intuiting ADSP 
> information from non-ADSP action.

If that's about step 2 in chapter 4.2.2 of I-D.ietf-dkim-ssp-03,
that verifies the existence of the author domain by any query,
recommending MX for this purpose.  If the author domain doesn't
exist the result is "error".  It is one of the four results in
chapter 3.2 (no ADSP, all, discardable, nxdomain).

> While there is nothing wrong with checking the A record, it's
> semantics have literally nothing (directly) to do with ADSP.

If the author domain does not exist it cannot receive mail, as
there is no A, no AAAA, and no MX, among others.  That check is
not directly related to ADSP, it generally makes sense, maybe
it should be done as first step.  Is that the "new issue" here ?

Related:  Apparently the I-D does not mention domain literals.
I think it should say something, domain literal isn't nxdomain.

 Frank

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Apr 2008 09:42:29 +0100

> - working group meetings.  Please advise.

It does look similar. Dave - can you differentiate this
from 1402?

Stephen.

> ------------------------------------------------------------------------
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 07 Apr 2008 09:58:54 -0400

Eliot Lear said the following:
> By my recollection, 

This topic has definitely been discussed a number of times.  And Stephen 
and I have discussed Dave's note from today, and think it's appropriate 
to continue the discussion a bit.  We need to keep it focused and come 
to a clear conclusion -- the problem is that we don't think we really 
have agreement on this question.

The particular point in Dave's note that troubles me, and that I don't 

> from the absence of publisher action.  Let me explain:
...
>> have literally nothing (directly) to do with ADSP.

I agree with that assessment, but more importantly, I think the working 
group doesn't yet agree on whether he's right or not.  So let's clear 
this up with a focused discussion that gets one of the following results:
* We have consensus that ADSP should explicitly say that in the absence 
of an ADSP record you have no information, and you treat the message as 
you did before DKIM/ADSP existed.  Any other processing might be 
proposed as an extension, in another document.
* We have consensus that there IS a well-defined process that we 
recommend following in the absence of an ADSP record, and that having 
the ADSP document define this is within scope for the base document.

Yes, this discussion is in scope for now.  Let's keep the discussion on 
track, and resolve this quickly.

Barry, as DKIM working group chair
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Mon, 07 Apr 2008 17:33:48 +0200

Barry:
> group doesn't yet agree on whether he's right or not.

As Frank points out, that's not what the draft says.  The draft says 
that you can pick *any* record.  The purpose is simply to determine 
whether the domain exists.  The argument is semantically different, 
particularly when you discuss this in terms of the recommended query, an 
MX record.  The worst you can say is that there is an interdependency 
between the deployment of MX records and ADSP records in the very same 
domain.  The only reason you have to do the query is because of the 
additional labels applied.  If you want to get away from this you need 
to use a new RR.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Apr 2008 10:45:29 -0700

Barry Leiba wrote:
> This topic has definitely been discussed a number of times.  

The focus of my note wason the contents of the specification, not on previous 
discussion.

I'll repeat that distinction:  The current draft does not deal with exact-name 
vs. sub-tree issues as an explicit point of distinction; it has bits of each 
scattered around.  As such, the specification is, at best, confusing on the 
distinction, nevermind incomplete on the tree construct.

But with respect to the working group's history of discussing this topic I'll 
first thank Eliot for citing the recently-closed Issue.  It was quite 
instructive to go back and read the associated mailing list thread.

I strongly encourage others also to do read that thread

      <http://mipassoc.org/pipermail/ietf-dkim/2006q4/006377.html>

since I think it substantiates my concerns, rather than resolves them:

      1. The cited thread shows a complete lack of anything one might call 
consensus.

      2. The cited thread pretty much shows a complete lack of coherence.

      3. I have no idea what the basis was for the chairs declaring the matter 
resolved. This is an inherent problem with closing items by fiat and without 
explanation.

Bottom lines:

     a. There is a difference between having discussed something and having 
resolved it.

     b. The current draft is, at best, confusing about the distinction of exact 
vs. tree

     c. There is no technical means for doing a clean, efficient and thorough 
job of "protecting" a sub-tree, when using the DNS.  It wasn't designed for that 
use and it doesn't handle it for scenarios such as DKIM needs. Consequently, it 
is not surprising that the current specification's component mechanisms for 
"protecting" a sub-tree are partial, at best.

> group doesn't yet agree on whether he's right or not. 

Right about what?

There is a factual assertion that an existing A record will have been created 
for reasons other than ADSP.  That's a statement of fact, not opinion.  A 
records are not created for any purpose having to do with ADSP.

If someone disagrees with the statement of fact, they need to substantiate it. 
And, yes, if they force such an exercise, I'll substantiate my assertion of 
objective fact.

Since the A record is not created for ADSP, how can its semantics have anything 
to do with ADSP?  Again, this is in the realm of objective fact, not opinion or 
preference.  So I'm unclear what the working group could disagree with.  (I'm 
concerned that we are in the realm of operating on the basis that the working 
group could formulate a consensus that 2+2=5 and the fact that there is 
consensus would resolve the matter.)

So, Barry, please clarify what you mean by "the working group doesn't yet agree 
on whether he's right or not."

>    So let's clear 

I believe I understand this choice.

> the ADSP document define this is within scope for the base document.

I am pretty sure I do not understand this alternative, but I'm pretty sure it 
does not respond to the concerns I raised.

d/
-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Mon, 07 Apr 2008 20:25:41 +0200

Dave,
> distinction, nevermind incomplete on the tree construct.

Can you suggest wording?

> I strongly encourage others also to do read that thread

As a matter of fact the way the issue was resolved was through Jim 
Fenton's presentation at the last IETF, and not so much through online 
discussion.  This having been said, the chair's have spoken and I won't 
delve further into why I think that issue should remain resolved.

>       1. The cited thread shows a complete lack of anything one might call 

That's because the consensus was formed at the meeting, as the minutes 
and Jim's presentation shows.  Be sure to look at those too.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Apr 2008 11:45:20 -0700

>> distinction, nevermind incomplete on the tree construct.

Let me nip this in the bud:  No.

I believe the entire effort to do more than deal with an exact-match names is a 
mistake and that all component details that attempt to expand the scope should 
be removed from the specification.

So the "suggested wording" I would offer is to remove text from the 
specification, not add it.

> and Jim's presentation shows.  Be sure to look at those too.

I seem to recall that decisions are not made at working group meetings.  They 
are made on the mailing list.

So I'd be curious for a citation on the mailing list where the consensus from 
the meeting was reviewed and confirmed.

d/

ps.  Yes, this is all painful.  It is also a good lesson about why being careful 
with process is particularly important for topics that are complex and poorly 
understood.

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Mon, 07 Apr 2008 11:18:32 -0700

Since the Chairs have ruled that this warrants yet further discussion...

> versus trying to protect an entire sub-tree.
Two comments:

(1) It's worth being careful about the word "protect"; the draft doesn't 
use it (except once, in a somewhat different context) and we should be 
careful about setting an expectation that publication of ADSP confers 
protection.  There is benefit to the publisher that may be viewed as 
protection that comes from the use of ADSP information by verifiers, but 
it is indirect and only to the extent that ADSP records are retrieved 
and used.

(2) ADSP does not publish information about entire subtrees, only about 
domains and labels within an immediate domain.
> to do only a partial job, at best.

Underscore-based names have no special standing within DNS (such as 
definition of attributes), other than the fact that they are illegal as 
hostnames but are legal for some other purposes.

DNS wildcards are indeed useless in the face of name prefixes, which is 
why ADSP does not depend on nor use them.  The mechanism described in 
the draft may be viewed as doing a "partial job" but we still need to 
consider whether what it does is useful.  I believe it is.
> make it mandatory to add sub-tree mechanisms to the specification.

Again, I reject the premise that this a sub-tree mechanism.

What are the "expanded semantics" to which you refer?

> have literally nothing (directly) to do with ADSP.

ADSP is not checking the A record, as others have pointed out.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 7 Apr 2008 11:50:09 -0700

On Apr 7, 2008, at 8:33 AM, Eliot Lear wrote:

> Barry:
>>> 3.  At least one of the sub-tree mechanisms is attempting to glean  
>>> information from the absence of publisher action.  Let me explain:
>>>
>> ...
>>
>>>>   c) Checking for the presence of an A record is intended to try  
>>>> tell you something in the absence of an explicit action by the  
>>>> domain owner.  That's it's flaw: It is intuiting ADSP information  
>>>> from non-ADSP action.
>>>>
>> I agree with that assessment, but more importantly, I think the  
>> working group doesn't yet agree on whether he's right or not.
>
> particularly when you discuss this in terms of the recommended  
> query, an MX record.  The worst you can say is that there is an  
> interdependency between the deployment of MX records and ADSP  
> records in the very same domain.  The only reason you have to do the  
> query is because of the additional labels applied.  If you want to  
> get away from this you need to use a new RR.

This could be generalized as a domain spoofing issue.  Before SMTP  
receivers expend resources validating signatures, a check of the  
originating domain's validity eliminates the expenditures of  
validating signatures for domains that otherwise are determined  
invalid through the lack of inbound SMTP servers.  Protecting  
resources is not a trivial matter, as DKIM demands more of receivers.

Querying any record may not be conclusive.  When either network  
providers or domains themselves inject synthesized wildcard records,  
sub-domains unrelated to valid message email addresses will appear to  
exist.  To prevent this situation from being exploited, specific  
checks for MX or A resource records indicate at least possible support  
of SMTP servers by the domain.  The recommendation in issue 1547  
simplifies this test.  Without MX resource records being found,  
receivers could conclude ADSP records below the '_adsp.' prefix do not  
exist either.

While DKIM is not limited to SMTP, the purpose for ADSP seems related  
to the spoofing of SMTP message sources.  After all, methods of  
message exchange involving prior arrangements are unlikely benefited  
by ADSP.  As such, ADSP should stipulate this limitation as this would  
better ensure proper use.

It seems some aspect of this concern appears to have been closed in  
issue 1551.  The tracking note only indicates 'resolved' by the Philly  
meeting consensus.  There is nothing within the minutes indicating  
what discussion took place or what aspect of this issue had been  
resolved or rejected.

While MUA related protocols may be used in conjunction with SMTP, the  
public exchange of messages using SMTP is where ADSP offers benefit.   
If messages from sources other than those initially from SMTP are to  
be covered by ADSP, is there a list of these initial non-SMTP message  
sources?  Such a list could permit a review of ADSP's impact on these  
different protocols.  The introduction and even details related SMTP  
error codes seem to indicate ADSP is a mechanism intended to operate  
in conjunction with messages initially exchanged by SMTP, and then  
secondarily through MUA related protocols.  What problem would be  
created by making a statement that ADSP is intended to benefit  
messages initially exchanged using SMTP?

-Doug

---

From: <[email-masked]>
Date: Mon, 7 Apr 2008 11:45:22 -0400

-----Original Message-----
From: [email-masked] on behalf of Barry Leiba
Sent: Mon 4/7/2008 9:58 AM
To: [email-masked]
Subject: Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree

...

Barry,
slight modification 
"* We have consensus that ADSP should explicitly say that in the absence 
of an ADSP record you have no information, and you treat the message as 
you did before DKIM/ADSP existed." 

We need to stop there as the rest of the sentence could include checking the credit score of a domain's owner as an DKIM/ADSP extension which may have value for an implementation but not a consensus document describing the value of a policy/practice.
thanks,
Bill Oxley

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Apr 2008 13:05:34 -0700

> Fenton's presentation at the last IETF, and not so much through online 

OK.  So I have now also reviewed:

    1. Issue 1534 and its associated thread:

       <https://rt.psg.com/Ticket/Display.html?id=1534>

    2. Minutes from Philadelphia

    3. Jim Fenton's slides from Phili

    4. The mailing list archive since Philadelphia

What I find is absolutely nothing that deals with any of the points I raised. 
And by "deals with" I mean contains substance.

Certainly the thread associated with 1534 shows no consensus and not much focus. 
Jim's slide have nothing on the topic, other than a listing of one of the two 
relevant Issues, and the Phili minutes do not make mention of this issue at all. 
And I find nothing in the mailing list archive that discusses it.

Since it is not possible to prove a negative, I'm going to again have to ask 
that those asserting that this matter was discussed and resolved need to 
document it.  And I mean point to concrete materials that confirm the claim, in 
both referenced Issues, that the matter was resolved.

As for the very reasonable requests that I clarify how the issue I am raising is 
different from the two cited Issues, here's my best effort:

    1.   There has been no requirement stated, carefully discussed, and clearly 
resolved, that ADSP must deal with a sub-tree or anything other than a single 
domain name.  What seems to have happened, for some, is a de facto assumption 
that it is requires.

         However it is not in the charter and it is not in the requirements. No 
mailing list discussion (and I will claim no face2face meeting) has discussed 
this requirement carefully and to resolution.

    2.   There is a difference between specifying component mechanisms, versus 
discussing concepts and approaches that motivate those mechanisms.  The current 
specification contains no clear statement of what it is trying to do, with 
respect to covering implicit or subordinate (or superior) names.

    3.   The DNS does not permit covering multiple names competently, for uses 
such as ADSP is attempting.  Any effort by ADSP to compensate for this 
deficiency must be, at best, partial and probably also experimental.

Previous working group discussions in this area -- including those cited as 
Issue 1402 and Issue 1534 -- have at most mentioned the higher level issues of 
trying to covering more than a single domain name.  However they have not 
discussed the conceptual distinction, nor have they discussed or resolved the 
requirement, nor have they resolved basic technical limitations.

If someone needs more explanation that distinguishes this Issue that I am 
raising and what has come before, they need to provide some detail.

> and Jim's presentation shows.  Be sure to look at those too.

Which of his slides shows this?

d/

-- 

   Dave Crocker

---

From: "Siegel, Ellen" <[email-masked]>
Date: Mon, 7 Apr 2008 15:41:16 -0400

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Jim Fenton
> Sent: Monday, April 07, 2008 2:19 PM
> To: [email-masked]
> Cc: [email-masked]
> > This issue encompasses some others, but I believe it is more basic
and
> therefore

Jim, in your presentation to the ESPC you brought up the fact that one
reason to encourage sub-domains to publish 'unknown' ADSP records was so
that they wouldn't inadvertently inherit an ADSP record from a parent
domain. 

As long as such inheritance is possible, i.e. that a subdomain can
automatically inherit from a parent domain, it must be true that we're
discussing subtrees. 

If we retain that capability, inadvertent or not, in the spec, I think
we need to call it out explicitly and discuss how to counter it. 

However, I agree with Dave that it may be cleaner to just exclude the
possibility of inheritance rather than try to deal with the fallout. 

> >      What this leaves us with is attempting to invent mechanisms
that
> turn out
> > 2.  Some of the sub-tree effort is for administrative convenience.
Some
> is for
> information
the
> idea
> > It does that by defining something else that must be present.  If
the
> ADSP
> tell you
> semantics

---

From: [email-masked] (Wietse Venema)
Date: Mon, 7 Apr 2008 16:14:24 -0400 (EDT)

> a) DKIM is for declaring the presence of an accountable identity.
> If a signature is present, you know something.  If it is absent,
> you know nothing extra.
>
> b) ADSP attempts to tell you something, in the absence of a
> signature.  It does that by defining something else that must be
> present.  If the ADSP record is present, you know something.  If
> it is absent, you know nothing extra.
>
> c) Checking for the presence of [any DNS] record is intended to try

To clarify a perhaps overlooked point: the existence of [any DNS]
record for the Originator domain does NOT imply that it is a valid
email origin.  If the record is absent, then we know nothing that
the absence of the ADSP record for that domain didn't already tell
us. Any suggestion to the contrary is probably a mistake.

> While there is nothing wrong with checking [any DNS] record, it's

	Wietse

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 7 Apr 2008 22:57:03 +0200

Dave Crocker wrote:

> it is not in the requirements

<JFTR>:
 <http://tools.ietf.org/html/rfc5016#section-4.2>
 "Deployment Consideration 2: Subdomain Coverage"

 | Thus, it would be advantageous for SSP to not
 | only cover a given domain, but all subdomains
 | of that domain as well.

 I'm unhappy with some points in RFC 5016, and I
 still have enough of all sub-domain issues after
 the efforts in 2004, but the topic is mentioned
 in RFC 5016.
</JFTR>

> Which of his slides shows this?

I see no #1534 in the nine IETF 71 PDF pages, and
no 1534 in the jabber log.  #1543 was discussed.

 Frank

---

From: <[email-masked]>
Date: Mon, 7 Apr 2008 20:47:29 +0000

> Date: Sun, 6 Apr 2008 23:06:25 -0700
> From: [email-masked]
> Subject: [ietf-dkim] New Issue: protecting a domain name vs. protecting a	domain tree
> 

Dave,

Like others I am guessing that you are referring to section 4.2.2 step 2. In  that step it explicitly says that you can check for any record you want and the semantics of the returned record itself are basically irrelevant only the existence of some response other than NXDOMAIN matters. In the case of an NXDOMAIN I didn't read that section as intuiting any policy. It just says to return an error which I read as something different than, return some specific result. Since the domain doesn't exist the administrator can't have been expected to create a policy for it so error seems like the right answer to me.

Otherwise to create policies for all of my domains I would have to create policies not just for all existing sub-domains of that domain (which I personally would support) but all conceivable sub-domains of a domain (which I don't think I would).

Robert

_________________________________________________________________
Pack up or back up–use SkyDrive to transfer files or keep extra copies. Learn how.
hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_skydrive_packup_042008

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Apr 2008 14:32:25 -0700

[email-masked] wrote:
> Like others I am guessing that you are referring to section 4.2.2 step 2.

Yup.

>    Since the domain doesn't exist the administrator can't have
> been expected to create a policy for it so error seems like the right answer
> to me.

That presumes the goal of protecting an entire sub-tree.

Absent that goal, the goal is to cover domains that have ADSP records.  Very 
different scope of effort.

> Otherwise to create policies for all of my domains I would have to create
> policies not just for all existing sub-domains of that domain (which I
> personally would support) but all conceivable sub-domains of a domain (which
> I don't think I would).

Again, creating records for every conceivable name -- and no, I can't imagine 
any reasonable administrator attempting that -- is only an issue if there is a 
belief that ADSP can 'protect' all names in a sub-tree.

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Mon, 07 Apr 2008 14:01:34 -0700

> automatically inherit from a parent domain, it must be true that we're

There is an important difference.  The subtree of example.com includes 
everything ending in .example.com such as a.example.com, b.example.com, 
and even f.e.d.c.b.a.example.com.  ADSP does not cover the subtree; it 
covers only labels in the immediate example.com domain.

> we need to call it out explicitly and discuss how to counter it. 

There are two ways to counter that capability:  either the subdomain 
publishes an ADSP record, or the parent domain publishes its ADSP record 
with the t=s flag as described in section 4.2.1 (or, conceivably, 
both).  Another possibility, I suppose, is to apply an Author Signature 
to the message which makes ADSP irrelevant as long as it isn't broken.

> possibility of inheritance rather than try to deal with the fallout. 

It's not cleaner for a domain that wishes to publish ADSP and has 
thousands of hostnames in the same domain now faces the prospect of 
publishing thousands of ADSP records, and doesn't have tools to automate 
this process.

My comment at ESPC was that I believe it would be a Best Practice for 
Coalition members to routinely publish, or have published, explicit ADSP 
records for domains that they send from.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 07 Apr 2008 15:14:28 -0700

Wietse Venema wrote:

ADSP is doing the converse of that:  it takes the non-existence of [any
DNS] record for the Author Domain as an implication that it is NOT a
valid email origin, or more accurately reports if that is the reason
there isn't an ADSP record for that domain.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 7 Apr 2008 16:01:02 -0700

On Apr 7, 2008, at 2:01 PM, Jim Fenton wrote:

>> automatically inherit from a parent domain, it must be true that  
>> we're discussing subtrees.
>
> There is an important difference.  The subtree of example.com  
> includes everything ending in .example.com such as a.example.com,  
> b.example.com, and even f.e.d.c.b.a.example.com.  ADSP does not  
> cover the subtree; it covers only labels in the immediate  
> example.com domain.

When the policy record below _adsp.example.com contains a parameter  
that precludes validity for sub-domains below example.com, then it  
must be expected this is being used.

>> If we retain that capability, inadvertent or not, in the spec, I  
>> think we need to call it out explicitly and discuss how to counter  
>> it.
>
> publishes an ADSP record, or the parent domain publishes its ADSP  
> record with the t=s flag as described in section 4.2.1 (or,  
> conceivably, both).  Another possibility, I suppose, is to apply an  
> Author Signature to the message which makes ADSP irrelevant as long  
> as it isn't broken.

Sub-domain coverage concerns _how_ policy records are discovered when  
_not_ published within sub-domains containing email-address with  
either none or invalid signatures.

>> However, I agree with Dave that it may be cleaner to just exclude  
>> the possibility of inheritance rather than try to deal with the  
>> fallout.
>

This can be resolved by qualifying possible valid domains with the  
existence of resource records needed to discover SMTP servers.  This  
limits the instances where ADSP records are need to those nodes that  
contain SMTP discovery resource records.

> My comment at ESPC was that I believe it would be a Best Practice  
> for Coalition members to routinely publish, or have published,  
> explicit ADSP records for domains that they send from.

In that case, there is no need for ADSP.  Change the ADSP draft to  
simply say use ESPC data to ascertain DKIM signature requirements.   
Perhaps ADSP draft should change into a standard format for this data.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Mon, 7 Apr 2008 19:19:23 -0400 (EDT)

Jim Fenton:
> ADSP is doing the converse of that: it takes the non-existence
> of [any DNS] record for the Author Domain as an implication that
> it is NOT a valid email origin, or more accurately reports if that
> is the reason there isn't an ADSP record for that domain.

The problem is that "valid email origin" is a subset of all the
names that resolve in the DNS. In other words, there are false
positives in the algorithm that continues when [any DNS] record
lookup succeeds.

	Wietse

---

From: Jim Fenton <[email-masked]>
Date: Mon, 07 Apr 2008 16:49:04 -0700

> positives in the algorithm that continues when [any DNS] record

That's true; that's why the result from ADSP in this case is, or should 
be, "Unknown".  But I don't see that in the spec; it simply indicates 
that no ADSP record was present, and the spec isn't giving enough 
guidance about what to do in that case.  In ssp-01, it had said 
"non-suspicious" in this case, and apparently this got lost when 
suspiciousness was removed.

Thanks for spotting that.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 07 Apr 2008 16:56:35 -0700

> no 1534 in the jabber log.  #1543 was discussed.

As I noted in http://mipassoc.org/pipermail/ietf-dkim/2008q1/009713.html 
, issue #1534 fell through the cracks when I was preparing my slides for 
Philadelphia and was not discussed.  I had suggested that it not be 
closed without the opportunity for some discussion.

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 8 Apr 2008 04:30:19 +0200

Jim Fenton wrote:
 
> , issue #1534 fell through the cracks when I was preparing my slides

No problem, for the known reasons I (try to) stay out of sub-domain
discussions.

Swapping steps 1 and 2 in 4.2.2 might make sense:  If an author-domain
does not exist looking for an ADSP is pointless, result "nxdomain" is
bad enough.

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Tue, 08 Apr 2008 10:03:05 +0200

Dave,

1402 and 1534 were specifically mentioned and discussed in Philly in 
Jim's presentation 
<http://www3.ietf.org/proceedings/08mar/slides/dkim-0.pdf>.  In fact, 
between the two they've been discussed at multiple meetings.    We know 
this because the mechanism has changed over time and was presented as it 
changed.  You can continue to traipse through the minutes of previous 
meetings (my own recollection and the minutes confirm 
<http://www.ietf.org/proceedings/07mar/minutes/dkim.txt> that is that 
the group spent time on this very issue in Prague).  You did not 
object.  My own recollection of the Prague discussion was that we 
specifically considered the positives and negatives of tree walking as 
well as a domain existence query, but perhaps the audio i lying around 
if you want to go to more detail.

Putting aside that procedural issue, the fundamental basis for your 
concern is that there are two independent systems that have no basis for 
interdependency.  But your premise is false, and the issue is 
specifically raised in the current -03 draft, here:

>    2.  _Verify Domain Exists._ The host MUST perform a DNS query for a
>        record corresponding to the Author Domain (with no prefix).  The
>        type of the query can be of any type, since this step is only to
>        determine if the domain itself exists in DNS.  This query MAY be
>        done in parallel with the query made in step 2.  If the result of
>        this query is an "NXDOMAIN" error, the algorithm MUST terminate
>        with an appropriate error.
>        
>           NON-NORMATIVE DISCUSSION: Any resource record type could be
>           used for this query since the existence of a resource record
>           of any type will prevent an "NXDOMAIN" error.  MX is a
>           reasonable choice for this purpose is because this record type
>           is thought to be the most common for likely domains, and will
>           therefore result in a result which can be more readily cached
>           than a negative result.

No A record required, as Frank and I mentioned earlier.

Perhaps I have missed some text that you are referring to.  Could you 
correct me?

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Tue, 08 Apr 2008 10:49:32 -0700

Eliot,

I am trying to be careful and specific in the things I am posting, here, and you 
and others need to be the same. My goal is to get discussion going.  Yours 
appears to be to stop it. Unfortunately, that has often been at the root of 
problems in this working group.

Let me repeat the bottom line, once again:

      There is nothing in the mailing list archive that demonstrates working 
group rough consensus on the matter of extending ADSP's scope to include more 
than a single, exact-match name.

      The record *does* contain discussion about the problems with attempting 
this expanded scope.

So please stop repeating broad references that turn out to be invalid or off the 
point.  The substantiation for this assessment is in the remainder of this 
message...

Eliot Lear wrote:
> <http://www3.ietf.org/proceedings/08mar/slides/dkim-0.pdf>.

"1402   Duplicate of 1534    Applicability of SSP to subdomains"

The above text contains the only reference to either of the documents in Jim's 
slides.  To the extent that it "proves" discussion took place, it is content free.

And let's get very clear about something:  I did not say there was no 
discussion.  So your "proving" that discussion took place in Philadelphia is not 
the issue.

>    In fact, 
> changed.

Since I didn't claim otherwise, I'm not sure what your point is.

In any event, it would be nice to see documentation of the details in such 
discussion and what it's conclusions were.

But most importantly we need to see documentation of consensus on the mailing 
list.

You do not address this fundamental IETF requirement. And by "address" I mean 
point to specific details that provide confirmation.  Generic document 
references don't help, particularly when it turns out that they do not prove 
your point.

   You can continue to traipse through the minutes of previous
> the group spent time on this very issue in Prague). 

1. For perhaps the third time: the minutes do not contains the strings 1402 or 
1534. The only reference to "tree" is:

    "Discussion focuses on subdomains, wildcards, tree-walking."

While, yes, it's entirely reasonable to take that as proof that something was 
said, it does not provide any content.  In particular, it doesn't even describe 
the claimed conclusions.

> You did not 

Concerns about sub-tree details have been expressed repeatedly and broadly over 
the months.

Whether I, in particular, voiced them in Philadelphia, seems to be a rule you 
are attempting to enforce as meaningful and I can't guess why.

> interdependency.  

I'm pretty sure that what I said does not strictly map to your characterization 
of it.

Were you attempting to engage in constructive dialogue, rather than shut this 
thread down, the question of its equivalence or difference strikes me as 
potentially useful for improving everyone's understanding of the issue.  So it's 
a shame that you have chosen to take such an adversarial stance.

>    But your premise is false, and the issue is 

Qouting an entire passage always feels comforting.  However I do not see which 
bits of text are on point or how.  To the extent that your own comment is meant 

> No A record required, as Frank and I mentioned earlier.

my constantly referring to A record probably is, indeed, distracting.  I'm happy 
to substitute all of my references to A with NXDOMAIN.  I believe it does not 
change any of the technical, administrative or operational concerns I raised.

> Perhaps I have missed some text that you are referring to.  Could you 

I don't understand what you are asking for.  Text that says what?

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 08 Apr 2008 11:05:24 -0700

I'm going to see whether we can actually have some constructive dialogue in this 
thread, by posting a message responding to a point that Eliot raised in a 
message that had a different focus:

...
> have literally nothing (directly) to do with ADSP.

(and, for completeness, please modify the above:  s/ A / NXDOMAIN /.)

Eliot said:
>>      the fundamental basis for your 

The semantics of a non-ADSP DNS record certainly were not intended to be 
relevant to ADSP. And I doubt anyone is going to claim that non-ADSP DNS records 
were created for the purose of ADSP use.

Whether ADSP can reasonably extract some semantics is an entirely reasonable 
line of question.

What we need to see is discussion and consensus that it can and does and that 
the benefits outweighs the costs.

An nice example of a counter-argument is:

 > positives in the algorithm that continues when [any DNS] record

One interpretation of this point is that the presence of a DNS entry (that is, a 
'failure' to get an NXDomain) might be meaningful, but the scope of its meaning 
is much broader than ADSP.  Once again:  A mechanism possibly worth pursuing, 
but outside of ADSP.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 08 Apr 2008 12:36:03 -0700

Stephen Farrell wrote:
>> One interpretation of this point is that the presence of a DNS entry 
>> (that is, a 'failure' to get an NXDomain) might be meaningful, but the 
>> scope of its meaning is much broader than ADSP.  
> 
> I'm not following that. Can you give an example? Even if its partly
> speculative, it'd help me understand your point. (And in this case,
> I guess speculation as to future uses of DNS might be valid, since
> the current absence of entries is what we're proposing to use.)

DKIM and ADSP fit into a larger framework of filtering activities.  I hope there 
is nothing controversial about that assertion.

It means that there are many analyses and tests that are outside the scope of 
DKIM (and ADSP).

Some filtering engines query for an NXDOMAIN today, independent of DKIM or ADSP.

That's a pretty clear indication that its meaning and utility are not tied to ADSP.

d/

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Apr 2008 20:16:07 +0100

> Whether ADSP can reasonably extract some semantics is an entirely reasonable 

Right. And that's the basis on which Barry and I think this worth
discussing again.

> is much broader than ADSP.  

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Apr 2008 20:12:13 +0100

Can we just park the "was consensus reached/documented" aspect
of this thread for a couple of days? I'll go back through the
archive and see if the ball was dropped (by Barry and I) or not.
But that'll take a day or two.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Apr 2008 22:24:10 +0100

> Right. And that's the basis on which Barry and I think this worth

Sorry, I should have said "a basis" above. Its been pointed out to me
that Dave's concern is broader than just the above which is fair enough.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Apr 2008 22:29:14 +0100

Dave Crocker wrote:
>>> (that is, a 'failure' to get an NXDomain) might be meaningful, but 
>>> the scope of its meaning is much broader than ADSP.  
>>
> DKIM and ADSP fit into a larger framework of filtering activities.  I 
> hope there is nothing controversial about that assertion.
> 
> It means that there are many analyses and tests that are outside the 
> scope of DKIM (and ADSP).
> 

All that seems clear. I guess however, it still doesn't help me
with (an example of) why ADSP making a query and reacting to an
NXDOMAIN response as currently spec'd may be problematic.

I think the logic for the WG not wanting ADSP to be able to
expliticly state "no mail" was correct, but that this case seems
different, hence the request for an example.

S.

---

From: <[email-masked]>
Date: Tue, 8 Apr 2008 21:02:08 +0000

> Date: Mon, 7 Apr 2008 14:32:25 -0700
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]

I think I would describe my goal more narrowly than that. I don't think that any ADSP record should be protecting anything more than the exact domain the record is entered for. I also think it is worthwhile for it to be possible for a domain administrator to be able to cover everything within his administrative control with their own records if they want to do that.

The case we're talking about here is not whether or not it is worthwhile to protect the whole domain sub-tree but what to do when encountering something that is definitionally NOT part of the domain sub-tree (remember we're talking about NXDOMAIN cases here only, not intuiting anything about any actual domains). Since these things are not domains then saying that searching for a domain policy for them returns an error seems entirely reasonable to me.

Robert

_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_042008

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 08 Apr 2008 18:34:30 -0500

> NXDOMAIN response as currently spec'd may be problematic.

There is absolutely nothing in the least bit problematic about an 
NXDOMAIN query.

If Dave wants this functionality removed he must build and demonstrate a 
constituency willing to support him.  To do that he'll need to provide a 
great deal more justification for change than he has thus far.

My own belief is that everybody is persuaded that this document has been 
discussed to death and that sufficient compromise has been made on all 
sides of the various issues.  The document is fine like it is.

Let's get to last call and move on.

Arvel

---

From: Eric Allman <[email-masked]>
Date: Wed, 09 Apr 2008 10:46:16 -0700

Dave, I'm not understanding how the algorithm can work if you omit 
step 2 from section 4.2.2.

Suppose that example.com wants to assert to the world that it signs 
all messages.  It will create an ADSP record for example.com with the 
appropriate assertion.  Without step 2, all an attacker has to do is 
to craft a message purported to be from 
"[email-masked]" (where "thing" is not a valid label 
in the example.com domain).  Step 1 fails, because of course there is 
no _adsp._domainkey.some.thing.example.com (i.e., it returns 
NXDOMAIN), so the algorithm falls through to the next step, which is 
now step 3.  Step 3 searches for _adsp._domainkey.thing.example.com, 
which also returns NXDOMAIN, so "the algorithm terminates with a 
result indicating that no ASP record was present" --- and the absence 
of an ADSP record means that unsigned mail must be deemed legitimate. 
Without step 2 there is nothing example.com can do to protect its 
name space.

If that's what you mean when you say "that presumes the goal of 
protecting an entire sub-tree" then I'm all for protecting the entire 
sub-tree.  Anything less looks to me like it severely weakens the 
entire point of ADSP.

eric

--On April 7, 2008 2:32:25 PM -0700 Dave Crocker <[email-masked]> 
wrote:

>> been expected to create a policy for it so error seems like the
>> right answer to me.
>
> Absent that goal, the goal is to cover domains that have ADSP
> records.  Very  different scope of effort.
>
>
>> Otherwise to create policies for all of my domains I would have to
>> create policies not just for all existing sub-domains of that
>> domain (which I personally would support) but all conceivable
>> sub-domains of a domain (which I don't think I would).
>
> Again, creating records for every conceivable name -- and no, I
> can't imagine  any reasonable administrator attempting that -- is
> only an issue if there is a  belief that ADSP can 'protect' all
> names in a sub-tree.
>
> d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 09 Apr 2008 11:27:27 -0700

Eric Allman wrote:
> Dave, I'm not understanding how the algorithm can work if you omit step 
> 2 from section 4.2.2.
> 
> Suppose that example.com wants to assert to the world that it signs all 
> messages.  It will create an ADSP record for example.com with the 
> appropriate assertion.  Without step 2, all an attacker has to do is to 
> craft a message purported to be from "[email-masked]" 

Eric,

Actually from your note, it looks to me that you understand just fine.

It looks as if the question is covering a single-name vs. a sub-tree.  Your note 
mostly takes sub-tree as an implicit given, but then states it explicitly at the 
end.

The attack that you describe requires using some name other than the one that is 
listed.  The single, specific name that is listed is, indeed, "protected".

> sub-tree.  Anything less looks to me like it severely weakens the entire 
> point of ADSP.

(Aside:  Folks keep correcting my own use of the word "protect" for DKIM or ADSP 
and given the delicate balancing act that ADSP must walk, I think their concern 
is quite reasonable.  So I'm trying to switch over to say "cover"...)

You echo the word "goal".  That certainly seems like the right starting point.

Does the working group assert the goal of covering entire sub-trees?

Note that this isn't in the working group charter, the requirements statement, 
or even explicitly stated in the specification.

That does not make the goal inappropriate, but it does mean that it needs to be 
stated and confirmed explicitly.  (And certainly the specification needs to 
state this explicitly and clearly.)

But frankly that's the easy part.  Because we then we have the small question of 
what are the technical requirements and details, for covering a sub-tree 
adequately, within the DNS, when using an underscore sub-naming scheme?

Given that the DNS is not designed to permit this conveniently and, in fact, 
does not seem to me to be able to do it at all, we certainly need a complete and 
coherent technical description of how ADSP accomplishes complete coverage of a 
sub-tree.

This would describe the approach being taken for covering a sub-tree, and the 
component mechanisms being used to achieve it -- Step 2 is but one of those 
components. It would also demonstrate what kind of attacks it protects against.

I am not aware of any previous technology providing such sub-tree functionality, 
and so this ought to be subject to careful review by the DNS and Security folks. 
  At that, I fear it will nonetheless warrant a status of "experimental".

So in terms of a "goal" I'm probably in agreement that it would be dandy to do. 
   But I think that my desiring that goal is pretty much irrelevant.

The problem is that I believe there is no technical means of covering a subtree 
completely, except by case-analysis, which isn't covering a tree at all.

I believe the Step 2 query only makes sense for ADSP in the context of covering 
an entire sub-tree, but that ADSP does not describe the larger framework into 
which Step 2 fits, for accomplishing that goal.

d/

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 9 Apr 2008 14:43:50 -0400

> [email-masked]] On Behalf Of Dave Crocker
> Sent: Wednesday, April 09, 2008 2:27 PM
> To: Eric Allman
> mostly takes sub-tree as an implicit given, but then states it
explicitly
> at the
> end.
> 
> The attack that you describe requires using some name other than the
one
> that is
entire
> > point of ADSP.
> 
> (Aside:  Folks keep correcting my own use of the word "protect" for
DKIM
> or ADSP
> and given the delicate balancing act that ADSP must walk, I think
their
> concern
> You echo the word "goal".  That certainly seems like the right
starting
> point.
> That does not make the goal inappropriate, but it does mean that it
needs
> to be
> stated and confirmed explicitly.  (And certainly the specification
needs
> to
> coherent technical description of how ADSP accomplishes complete
coverage
> of a
> sub-tree.
> 
> This would describe the approach being taken for covering a sub-tree,
and
> and so this ought to be subject to careful review by the DNS and
Security
> folks.
> So in terms of a "goal" I'm probably in agreement that it would be
dandy
> to do.
> The problem is that I believe there is no technical means of covering
a
> subtree
> an entire sub-tree, but that ADSP does not describe the larger
framework
> into

OK, you all tricked me into looking at section 4.2 again. My first
question is whether we are working from
http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-03.txt or is
there something later floating around?

The reason I ask is that if ssp-03 is it then I think there is a minor
cleanup for step 2. It says " This query MAY be done in parallel with
the query made in step 2." I think it really means to say " This query
MAY be done in parallel with the query made in step 1." 

In response to the question Dave asks, I like the idea of providing the
option of protecting an entire (sub)tree within in a domain. My question
to the gurus is whether there is a clean way to identify "main" domains
below a TLD. For the generics this would appear to be straight forward.
For country TLDs I'm not so sure. Some country TLDs might always require
a .co.TLD or .edu.tld (or something similar). Not only is there
inconsistency across such TLDs, there may be inconsistency over time as
far as requirements within a TLD.

What started me thinking along this line was allowing a base domain (if
you will) to make an assertion that ALL subdomains only send signed mail
(or never sign mail or ?)

Just a thought.....

Mike

---

From: <[email-masked]>
Date: Wed, 9 Apr 2008 21:24:27 +0000

Date: Wed, 9 Apr 2008 11:27:27 -0700
> From: [email-masked]
> To: [email-masked]

Dave,

I think this misstates what that query actually accomplishes. What step 2 tells you is whether the thing you are looking at even is a domain and thus a candidate to have a domain policy. In the example Eric gave the record he mentioned would still only cover example.com. If a.b.example.com existed and you wanted to cover an entire sub-tree a.b.example.com would still need to have its own policy. Since some.thing.example.com doesn't exist I am not sure it makes sense to say it is part of that sub-tree. Even as written there is no indication that anything about the policy of example.com covers some.thing.example.com nor even any indication that there is such a policy. What the spec says is to return an error.

I think a cleaner way to express what I think you get out of step 2 (though a less efficient algorithm I suspect) would be to make step 2 step 1 and add some text around the error saying that searching for domain policies for anything that is not a domain is not within the scope of this document.

Robert

---

From: Roland Turner <[email-masked]>
Date: Thu, 10 Apr 2008 16:40:46 +0800

> or even explicitly stated in the specification.

(Getting myself up to speed...)

I'm pretty certain that I've correctly identified the working group
charter ( http://www.ietf.org/html.charters/dkim-charter.html ) and the
draft specification ( draft-ietf-dkim-ssp-03 ), but your comment leads
me to wonder whether I've misidentified the requirements statement; I
had assumed RFC5016, however this document both implicitly in several
places and explicitly in at least one place (4.2.  Deployment
Consideration 2: Subdomain Coverage "it would be advantageous for SSP to
not only cover a given domain, but all subdomains of that domain as
well") actually _does_ state this goal.

Did I miss a step?

(I can still see the difficulty/impossibility in realising this goal.)

- Roland

-- 
Roland Turner | Product Manager, RealMail | BoxSentry Pte Ltd
3 Phillip Street, #13-03 Commerce Point, Singapore 048693
Mob: +65 96700022 | Skype: roland.turner | Fax. +65 65365463
[email-masked] | www.boxsentry.com

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 10 Apr 2008 11:40:59 -0500

> step 2 from section 4.2.2.

It can't.

 > Without step 2 there is nothing example.com can do to protect its

Right again.

It would be a large mistake to remove step 2.

Arvel

---

From: Eric Allman <[email-masked]>
Date: Thu, 10 Apr 2008 12:35:22 -0700

Dave,

So I guess what we're talking about is to what "coverage" ADSP gives 
you.  There are three options, not two:

  1.  The name itself, and nothing more.
  2.  The name itself plus one level down in the subtree.
  3.  The name itself plus all levels below it in the subtree.

The current draft gives you option 2.  As a side effect, it acts like 
option 3 for names that do not exist, e.g., given the name 
"a.b.example.com", and assuming that "b.example.com" does not exist, 
then "a.b.example.com" gets covered as a side effect of the fact that 
"b.example.com" does not exist.

I disagree with your assertion that this hasn't been explicit.  As 
others have pointed out, 5016 section 4.2 already states this.  It 
would make sense to make this explicit in the ADSP draft itself, but 
that's a matter of wordsmithing, not a question of the desirability 
and appropriateness of the function in the first place.

For the record, I'm in favor of leaving step 2 in.  I think it is 
appropriate, in scope, and desirable for both senders and receivers 
alike.

eric

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Apr 2008 12:54:44 -0700

On Apr 9, 2008, at 11:43 AM, MH Michael Hammer (5304) wrote:
> In response to the question Dave asks, I like the idea of providing  
> the option of protecting an entire (sub)tree within in a domain. My  
> question to the gurus is whether there is a clean way to identify  
> "main" domains below a TLD. For the generics this would appear to be  
> straight forward. For country TLDs I'm not so sure. Some country  
> TLDs might always require a .co.TLD or .edu.tld (or something  
> similar). Not only is there inconsistency across such TLDs, there  
> may be inconsistency over time as far as requirements within a TLD.
>
> What started me thinking along this line was allowing a base domain  
> (if you will) to make an assertion that ALL subdomains only send  
> signed mail (or never sign mail or ?)

Technically, Dave Crocker is right.  The issue he raises is valid  
since message content is independent of SMTP.  When taken to heart,  
one can not expect _any_ DNS records relate to what might be email- 
addresses contained within the messages.

One simple assertion can overcome this issue.  Declare protections  
afforded by ADSP _only_ relate to email-addresses exchanged using  
SMTP.   With this statement, there would be MX or A DNS resource  
records required by the domain.  Presence of these records therefore  
offers a means to validate the domains.

To put an upper limit on the number of policy related DNS transactions  
that could increase over time, require publishing MX records with any  
SMTP policy record.  This would place an upper limit on the number of  
transactions needed to determine presence of SMTP policy.   The first  
step in evaluating SMTP policy would be requesting an MX record.  To  
determine whether the domain might be valid for SMTP, a subsequent  
transaction could check for A records.  Until A record discovery  
becomes deprecated, and to avoid tree walking, domains seeking  
protection should be required to publish ADSP records at every node  
there is also A records.  The existence of policy records in the  
absence of MX records would also refute any message comes from the  
domain.  As policy records would need to be published in conjunction  
with A records, the requirement that policy be qualified by MX records  
eliminates any need to also publish bogus MX records as have been  
suggested as an alternative strategy.

Acceptance of messages independent of SMTP delivery is separate matter  
not covered by ADSP.  This could be handled through a scope statement  
in the ADSP record, but this field is currently missing.  The way  
forward would be to declare that ADSP pertains to SMTP exchanged  
messages.  When handling a mixture of messages exchanged using SMTP  
and other protocols, there will be potential conflicts.  When the  
exchange protocol is not apparent to recipients, these messages may be  
seen as not complaint with ADSP assertions when a default assumption  
of SMTP is used.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 11 Apr 2008 17:09:56 +0100

> listed.  The single, specific name that is listed is, indeed,  

Sure, if a phisher includes
      From: [email-masked]
then SSP/DKIM will catch him.

If the phisher includes
     From: [email-masked]
then we know that SSP/DKIM cannot catch him, and there is not much we can
do about that other than to advise phishees to read From headers _very_
carefully.

But if the phsher includes
      From: [email-masked]
where the domain mailout.ebay.com does not exist, then it needs to be
caught somehow, since the phishee will look at it _very_ carefully and
will find it perfectly reasonable (as indeed it is).

So if we cannot arrange that mailout.ebay.com is not caught by some
sub-domain mechanism within SSP, then we at leaast need to say, perhaps
non-normatively:

"Although it is impossible to obtain an SSP record for a non-existant
sub-domain of a protected domain, verifiers might well choose to to
reject/discard/whatever messages with non-existent domains in From headers
as a matter of policy quite separate from their policies arising from
SSP/DKIM."

-- 
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: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 11 Apr 2008 12:59:09 -0400

> [email-masked]] On Behalf Of Charles Lindsey
> Sent: Friday, April 11, 2008 12:10 PM
> To: DKIM
> Subject: [ietf-dkim] Fwd: Re: New Issue: protecting a domain name
> vs.protecting a domain tree
> 
step
one
> as a matter of policy quite separate from their policies arising from

This is one of the reasons that I raised the question of whether it is
possible to find the "base" domain (not TLD) that the organization
controls. If this is possible then we may have the ability for ADSP to
assert that all sub-domains in a tree only send mail that is DKIM
signed. If this is not possible to do then I don't know that
non-existent sub-domains can be protected by DKIM/ADSP.

Mike

---

From: John Levine <[email-masked]>
Date: 11 Apr 2008 17:09:29 -0000

>This is one of the reasons that I raised the question of whether it
>is possible to find the "base" domain (not TLD) that the organization
>controls.

You can't.  There's nothing in the DNS that lets you determine what
organization is responsible for what entries.  Some people claim you
can do it from zone boundaries but for a variety of reasons they are
mistaken.

> If this is not possible to do then I don't know that non-existent
> sub-domains can be protected by DKIM/ADSP.

Right.  Hence my suggestion that we not try, and just remind people
that non-existent domains are an issue they can already deal with if
they want to.

R's,
John

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 11 Apr 2008 14:20:22 -0500

> that non-existent domains are an issue they can already deal with if

Remind them where?  How?  If it's not mentioned in nor is part of the 
specification how do you propose that ADSP do that?

Arvel

---

From: John Levine <[email-masked]>
Date: 11 Apr 2008 20:41:49 -0000

>specification how do you propose that ADSP do that?

In a non-normative sentence or two in the RFC.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Fri, 11 Apr 2008 14:34:14 -0700

John Levine wrote:

Let's not be too gentle here; failure to do this results in a very
misleading result from ADSP.  I would make it at least a SHOULD.

-Jim

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 11 Apr 2008 23:22:58 -0500

> misleading result from ADSP.  I would make it at least a SHOULD.

So, I want to understand.

You are proposing that we NOT eradicate all mention of an NXDOMAIN check 
but that we move it from a required algorithmic step and into language 
which is non-compulsory.  Is this correct?

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 11 Apr 2008 23:27:48 -0500

Sorry, I'm asking John Levine this question (not Jim).

---

From: John Levine <[email-masked]>
Date: Sat, 12 Apr 2008 01:48:37 -0400 (EDT)

> You are proposing that we NOT eradicate all mention of an NXDOMAIN check but 
> that we move it from a required algorithmic step and into language which is 
> non-compulsory.  Is this correct?

Yeah.  It's a good idea, but it's not part of DKIM.

R's,
John

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 14 Apr 2008 10:41:57 +0100

> can do it from zone boundaries but for a variety of reasons they are

Can you remind us why again?

What is wrong with saying "IF you publish an SOA record for a domain, then  
you MUST publish an ADSP at that level if you want ADSP to apply". I.e.,  
if verifiers find an SOA, they need look no higher.

Then, as a separate issue, you can prescribe how many levels verifiers  
need to climb looking for ADSP and SOA. The current draft effectively says  
"climb at most one" which, as many people have pointed out, gives 95% of  
the benefit of an unrestricted climb.

Clearly, TLDs will have an SOA but no ADSP, so the climb will certainly  
stop there.

---

From: John Levine <[email-masked]>
Date: 14 Apr 2008 17:24:58 -0000

>Can you remind us why again?

I could, but it would be kinder to the rest of the members of the list
for you to read the extensive debate on this point in the DKIM list
archives.

R's,
John