Subject: [ietf-dkim] draft-iab-dns-choices-05 and tree climbing (fwd)

From: John Levine <[email-masked]>
Date: Sat, 1 Mar 2008 13:33:24 -0500 (EST)

[ resent with reasonable MIME headers ]

This note seems relevant to DKIM.  This draft says, predictably, that
the way you add new data types to the DNS is with a new RR type, and
all other approaches are ill-advised.

It also says that DNS tree climbing is always bad.  We might want to
reconsider whether the small amount of tree climbing specified in -03
is worth the hassle it will doubtless cause on the route from final
draft to RFC.

R's,
John

-----------
From: Olaf Kolkman <[email-masked]>
Subject: Correction: Impending publication: draft-iab-dns-choices-05
Date: Sat, 1 Mar 2008 15:23:00 +0000 (UTC)
Message-ID: <[email-masked]>

I managed to sneak in two errors:
1. a February 23 deadline, that should have been March 28
2. a link to version 03 of the document, that should have
    been 05.

For completeness:

The IAB is ready to ask the RFC-Editor to publish

     Design Choices When Expanding DNS
           draft-iab-dns-choices-05

as an Informational RFC.  This document provides a number of
considerations to assist application and protocol designers in
choosing a mechanism to store and retrieve data in the DNS. It treats,
among other things the pros and cons of using TXT records, and of
adding prefixes or suffixes to owner names. It argues that adding a
new Resource Record is the best solution to add new data to the DNS
and that the use of TXT Resource Records is the worst.

The IAB solicits comments by March 28, 2008. Please send
comments to the IAB ([email-masked]), or to [email-masked].

The document can be found at

http://www.ietf.org/internet-drafts/draft-iab-dns-choices-05.txt

>From the Abstract:

   This note discusses how to extend the DNS with new data for a new
   application.  DNS extension discussions too often focus on reuse of
   the TXT Resource Record Type.  This document lists different
   mechanisms to extend the DNS, and concludes that the use of a new DNS
   Resource Record Type is the best solution.

Olaf Kolkman,
      For the IAB.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Sun, 02 Mar 2008 06:50:55 -0800

> is worth the hassle it will doubtless cause on the route from final

After implementing this, I can say that it seems to be mostly working 
and that
what's mostly interfering is wildcarded SPF records. I'm guessing that
the deployers of SPF are likely to reasonably overlap with the deployers
of DKIM. On the other hand, I haven't ground the numbers to get any
statistics as to how much we should care.

       Mike

---

From: John Levine <[email-masked]>
Date: Sun, 2 Mar 2008 09:57:29 -0500 (EST)

> After implementing this, I can say that it seems to be mostly working

I believe that it works to the extent that it covers immediate subdomains 
of the domain for which you're publishing an SSP/ASP record.

The question is whether that small amount of coverage is worth the 
pushback we will certainly get from the IAB when they see the tree 
crawling in our draft.  If bad guys know that foo.cisco.com is covered, 
why won't they just use foo.bar.cisco.com instead?

Also, keep in mind that if you really truly want to cover every possible 
subdomain, it's not out of the question to use a DNS server that 
synthesizes the necessary records on the fly using a different wildcard 
expansion process from BIND.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Sun, 02 Mar 2008 20:55:53 -0800

> why won't they just use foo.bar.cisco.com instead?

Great example.  Let's see what ASP does with that.

foo.cisco.com is, as it happens, a CNAME for some random internal web 
server.  So it's unlikely to have an explicit ASP record.  The first 
query, for _asp._domainkey.foo.cisco.com TXT will return a NXDOMAIN 
response.  So we next query for foo.cisco.com MX which 
returns...er...the CNAME (maybe we need to tighten up the spec to handle 
CNAMEs better).  Querying the thing it points to, ptlm-www.cisco.com, 
returns noerror/nodata to an MX query.  So then we query for 
_asp._domainkey.cisco.com TXT, and get its ASP record.  So far so good.

Now suppose the bad guy uses foo.bar.cisco.com.  The first query for 
_asp._domainkey.foo.bar.cisco.com TXT returns NXDOMAIN, so we next query 
for foo.bar.cisco.com MX and also get NXDOMAIN.  The algorithm 
terminates with an error indicating that the domain doesn't exist.  It's 
up to the implementation what happens next, but I would expect that 
would bias the evaluation of the message negatively.  That's why the bad 
guy wouldn't want to use foo.bar.cisco.com.
> expansion process from BIND.

Let's explore that.  This means that every domain publishing an ASP 
record that wants this coverage would have to change *all* of its 
authoritative DNS servers to implementations that synthesize these 
responses.  I'm not aware of any DNS servers that do this right now.  
Even if they do exist, given the requirement to have multiple 
authoritative servers on different networks and resulting cooperative 
DNS service arrangements, the requirement that they all do this is a 
huge barrier to effective deployment.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sun, 02 Mar 2008 22:31:06 -0700

> why won't they just use foo.bar.cisco.com instead?

Put forward as an efficiency hack, to avoid having to make a number of 
one-level-down DNS records, the mechanism has no claim towards affecting 
security.  Taken on its own, therefore, the question is whether the mechanism as 
a) worth the effort on a normal implementation cost vs. operational benefit 
basis, and b) worth the effort to run contrary to established DNS practice and, 
now, IAB preferences.

Put forward as having any security characteristics, such as enforcing the ASP 
security model, this DNS hack is likely to have quite a bit of pushback, as you 
note.

d/
-- 

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

---

From: Jim Fenton <[email-masked]>
Date: Sun, 02 Mar 2008 21:22:56 -0800

> is worth the hassle it will doubtless cause on the route from final

The relevant section (4) of this document points out that by querying 
the parent domain, it "may lead to incorrect results and may also put 
security at risk," because the parent domain maybe under different 
administrative control.  What we need to consider is whether the risk of 
undesired inheritance of an ASP from a parent domain is greater or less 
than the risk presented by other labels (hostnames, etc.) being used in 
 From addresses without regard for the ASP of the domain they're in. 

Since the default ASP is "unknown", the risk presented by a 
separately-managed parent domain is that they will publish an ASP that 
is stronger than that desired by the child.  This can be countered 
either by the parent publishing its record with the t=s flag that 
prevents its application to subdomains, or by the child domain 
publishing an explicit ASP of its own.

Without the parent query, any label in the domain is potentially able to 
be used to circumvent the ASP record.  Labels in the domain not having 
an explicit ASP record would be interpreted as "unknown", which might be 
looser than the ASP for the domain.

I have spent considerable time with the DNS folks, including two of the 
editors of this draft, socializing what we are doing here.  I believe 
that security is better served by doing the parent query.  I would hate 
to compromise the effectiveness of ASP just to make it more expedient to 
get it to RFC.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Mon, 03 Mar 2008 06:26:19 -0700

G'day,

While reviewing the posts in response to the iab draft, I am finding myself 
unclear about the reasons for Step 2, of the query procedure in ASP's Section 
4.2.2.  I'm pretty sure this is not merely a caffeine-deficiency-based question...

      What is the functional or security reason for verifying that the domain 
exists, in terms of ASP.

I can imagine obvious reasons, outside of ASP, but those would not need to be 
documented in the ASP.

At the least, it would help to have the document include text that explains the 
benefit of this step.

Thanks.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 3 Mar 2008 20:38:03 -0000

>      What is the functional or security reason for verifying that
> the domain exists, in terms of ASP.

The short answer is in 3.2, where there's a different answer for "I
dunno" and "doesn't exist".

As I recall, it's always been that way, but that's a good question.

There's certainly plenty of reasons to be wary of mail with a return
address that doesn't exist, but baking that into ASP does feel like
mission creep, doesn't it?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Mon, 03 Mar 2008 13:51:09 -0800

> At the least, it would help to have the document include text that explains the 

Where this came from, as I remember, is the translation from a new RR 
type to a prefixed TXT query.  If ASP is published using its own RR 
type, one can do a query that gets the ASP record, and find out whether 
the domain exists at all.  If you substitute a prefixed TXT query, you 
need to do a query for the domain itself, without the prefix, if you 
want to find this out.

Checking for the existence of the domain is clearly a useful thing to 
do, but it could be considered out of scope for ASP to check for the 
existence of the domain, since a non-existent domain naturally does not 
have a signing practices record (and we already know that).  Another 
justification might be caching, but I'd need to find out more about how 
negative caching works:  would a negative response to 
_asp._domainkey.nonexistent.example.com result in a negative cache entry 
for nonexistent.example.com?  If so, step 2 might occur very quickly 
(and locally), potentially eliminating the step 3 query for the parent, 
which would probably not be cached.

-Jim

---

From: Steve Atkins <[email-masked]>
Date: Mon, 3 Mar 2008 13:59:23 -0800

> mission creep, doesn't it?

If I recall the discussion correctly, it's that without that check  
then the
absence of an ASP record was perceived to mean that the domain
owner permitted mail to be sent with that hostname.

Adding the check for existence of some record for the hostname means
that in order to deploy ASP the sender needs only provide a TXT record
corresponding to every hostname in use, not every conceivable hostname
(which is impossible to do in any useful manner with standard DNS  
servers).

As a concrete example, there is no ASP record for  
creditcard.billing.ebay.com,
and without the domain existence check it would be difficult for ebay  
to assert
ASP-style policy over all their domains.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Mon, 3 Mar 2008 14:58:48 -0800

On Mar 3, 2008, at 1:51 PM, Jim Fenton wrote:

> Dave Crocker wrote:
>> G'day,
>>
>> While reviewing the posts in response to the iab draft, I am  
>> finding myself unclear about the reasons for Step 2, of the query  
>> procedure in ASP's Section 4.2.2.  I'm pretty sure this is not  
>> merely a caffeine-deficiency-based question...
>>
>> I can imagine obvious reasons, outside of ASP, but those would not  
>> need to be documented in the ASP.
>>
>> At the least, it would help to have the document include text that  
>> explains the benefit of this step.
>
> Where this came from, as I remember, is the translation from a new  
> RR type to a prefixed TXT query.  If ASP is published using its own  
> RR type, one can do a query that gets the ASP record, and find out  
> whether the domain exists at all.  If you substitute a prefixed TXT  
> query, you need to do a query for the domain itself, without the  
> prefix, if you want to find this out.

A test should be made querying an MX record at the domain in  
question.  If the domain does not exist, there is no reason to check  
the parent domain for policy records.  By mandating use of MX records  
when publishing the policy records, this climb up the domain tree can  
be completely avoided. : )

> Checking for the existence of the domain is clearly a useful thing  
> to do, but it could be considered out of scope for ASP to check for  
> the existence of the domain, since a non-existent domain naturally  
> does not have a signing practices record (and we already know that).

But avoiding a policy check at the parent would be in scope, would it  
not?

> Another justification might be caching, but I'd need to find out  
> more about how negative caching works:  would a negative response to  
> _asp._domainkey.nonexistent.example.com result in a negative cache  
> entry for nonexistent.example.com?  If so, step 2 might occur very  
> quickly (and locally), potentially eliminating the step 3 query for  
> the parent, which would probably not be cached.

See RFC 2308.  Negative caching is not as certain as positive  
caching.  This is why the MX record should be checked prior to walking  
up the domain tree.  Negative caching should be retrained as long as  
the MINIMUM field of the SOA record or the TTL of the SOA itself,  
whichever is less.  Not all resolvers are RFC 2308 compliant.  Some  
truncate the duration of negative caching to limit the effects of  
transient network failures.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 03 Mar 2008 16:54:59 -0800

Douglas Otis wrote:
>>> While reviewing the posts in response to the iab draft, I am finding 
>>> myself unclear about the reasons for Step 2, of the query procedure 
>>> in ASP's Section 4.2.2.  I'm pretty sure this is not merely a 
>>> caffeine-deficiency-based question...
>>>
>> type, one can do a query that gets the ASP record, and find out 

You have proposed that domains publishing ASP records be required to 
publish MX records.  But in this case, we have a domain (or perhaps a 
host) that has not published an ASP record, so there could be no 
requirement for an MX.
>> existence of the domain, since a non-existent domain naturally does 
>> not have a signing practices record (and we already know that).
>

Perhaps, if there were a clear advantage to checking for the existence 
of the domain vs. querying the parent, which I explore in the following 
paragraph.
>
>> Another justification might be caching, but I'd need to find out more 
>> about how negative caching works:  would a negative response to 

In this case, the query that would benefit from negative caching occurs 
immediately (within milliseconds) of the first query, so there shouldn't 
be significant TTL issues.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 3 Mar 2008 18:35:30 -0800

On Mar 3, 2008, at 4:54 PM, Jim Fenton wrote:
>>> RR type to a prefixed TXT query.  If ASP is published using its  
>>> own RR type, one can do a query that gets the ASP record, and find  
>>> out whether the domain exists at all.  If you substitute a  
>>> prefixed TXT query, you need to do a query for the domain itself,  
>>> without the prefix, if you want to find this out.
>>
>> question.  If the domain does not exist, there is no reason to  
>> check the parent domain for policy records.  By mandating use of MX  
>> records when publishing the policy records, this climb up the  
>> domain tree can be completely avoided. : )
>
> publish MX records.  But in this case, we have a domain (or perhaps  
> a host) that has not published an ASP record, so there could be no  
> requirement for an MX.

Requiring MX records be coupled with DKIM/SMTP policy records means  
"existing" domains without MX and policy records thereby indicate they  
do not have policy asserted for the domain.  Importantly, this result  
can be reached without climbing the domain tree.  Conversely, when a  
policy record is discovered without an MX record, checks against  
parent domains are also prevented.  Both of these important safety  
features are missing from the present DKIM policy discovery algorithm.

>>> to do, but it could be considered out of scope for ASP to check  
>>> for the existence of the domain, since a non-existent domain  
>>> naturally does not have a signing practices record (and we already  
>>> know that).
>>
>> But avoiding a policy check at the parent would be in scope, would  
>> it not?
>
> Perhaps, if there were a clear advantage to checking for the  
> existence of the domain vs. querying the parent, which I explore in  
> the following paragraph.

Second or third level domains might be above millions of email-address  
domains which could cause DKIM policy discovery processes to be  
invoked.  An algorithm that makes requests for non-existent records  
within parent domains will generate a fair amount of new and highly  
distributed overhead of non-beneficial traffic that will cause  
unnecessary processing delays.

>>> more about how negative caching works:  would a negative response  
>>> to _asp._domainkey.nonexistent.example.com result in a negative  
>>> cache entry for nonexistent.example.com?  If so, step 2 might  
>>> occur very quickly (and locally), potentially eliminating the step  
>>> 3 query for the parent, which would probably not be cached.
>>
>> caching.  This is why the MX record should be checked prior to  
>> walking up the domain tree.  Negative caching should be retrained  
>> as long as the MINIMUM field of the SOA record or the TTL of the  
>> SOA itself, whichever is less.  Not all resolvers are RFC 2308  
>> compliant.  Some truncate the duration of negative caching to limit  
>> the effects of transient network failures.
>
> In this case, the query that would benefit from negative caching  
> occurs immediately (within milliseconds) of the first query, so  
> there shouldn't be significant TTL issues.

Agreed, the SOA record TTL should not represent a significant  
concern.  However, a fairly significant percentage of DNS resolvers do  
not fully adhere to RFC 2308 and as such, reliance upon negative  
caching should be minimized.  In other words, negative caching should  
not be expected to terminate walks up the domain tree when searching  
for seldom published records.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Mar 2008 10:10:33 -0800

On Mar 3, 2008, at 6:35 PM, Douglas Otis wrote:
>> You have proposed that domains publishing ASP records be required  
>> to publish MX records.  But in this case, we have a domain (or  
>> perhaps a host) that has not published an ASP record, so there  
>> could be no requirement for an MX.
>
> "existing" domains without MX and policy records thereby indicate  
> they do not have policy asserted for the domain.  Importantly, this  
> result can be reached without climbing the domain tree.  Conversely,  
> when a policy record is discovered without an MX record, checks  
> against parent domains are also prevented.  Both of these important  
> safety features are missing from the present DKIM policy discovery  
> algorithm.

> Second or third level domains might be above millions of email- 
> address domains which could cause DKIM policy discovery processes to  
> be invoked.  An algorithm that makes requests for non-existent  
> records within parent domains will generate a fair amount of new and  
> highly distributed overhead of non-beneficial traffic that will  
> cause unnecessary processing delays.
>
>>>> occur very quickly (and locally), potentially eliminating the  
>>>> step 3 query for the parent, which would probably not be cached.
>>>
>>> compliant.  Some truncate the duration of negative caching to  
>>> limit the effects of transient network failures.
>>
> concern.  However, a fairly significant percentage of DNS resolvers  
> do not fully adhere to RFC 2308 and as such, reliance upon negative  
> caching should be minimized.  In other words, negative caching  
> should not be expected to terminate walks up the domain tree when  
> searching for seldom published records.

To expand upon this concept a bit.  A requirement to publish MX  
records in conjunction with DKIM/SMTP policy records benefits:

1- Slightly increased percentage of MX records positively answering  
existence probes.

2- Within existing domains, a DKIM/SMTP Policy Record absent MX  
records signifies disavowal of DKIM/SMTP.

3- DKIM/SMTP policy records signifying disavowal of DKIM/SMTP can be  
empty and not require content interpretation.

4- Asserting policy does not depend upon walking up the domain, but  
instead requires publishing empty policy records at existing nodes.

5- This Discovery/Policy assertion strategy safely extends to other  
protocols.

6- Does not depend upon wildcards.

7- Expects domains establishing policy to use a strategy that protects  
parent domains.

8- Does not modify what is permitted by the parent domain.

Item 1 moves SMTP closer to a general mandate of requiring MX records  
for message acceptance.  At that time, a need to publish an empty  
policy record at every existing domain node would be precluded.

Item 2 affords actionable responses to abuse or forgery, as this  
offers stronger evidence than invalid or missing signatures provide.

Item 3 can terminate even one level domain searches for policy, which  
would be highly recommended of any domain utilizing DKIM when such  
searching is adopted.

Item 4 minimizes memory required, and eliminates impact of changes to  
the policy record structure used in conjunction with MX records.

-Doug

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 5 Mar 2008 12:27:15 -0800

One of the authors of the draft has assured me that this is not an
attempt to override working group consensus through the back door.

While the announcement indicated that publication is imminent, it is far
from clear that this is the case. The announcement also indicates that
comments are invited till March 28th. Objections have been lodged.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jim Fenton
Sent: Monday, March 03, 2008 12:23 AM
To: John Levine
Cc: DKIM List
Subject: Re: [ietf-dkim] draft-iab-dns-choices-05 and tree climbing
(fwd)

-Jim

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 6 Mar 2008 06:05:07 -0800

The IAB chair confirmed to me that this document is in last call,
comments are solicited.

The existing list of comments makes it clear that publication is not
imminent and might not occur at all.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hallam-Baker,
Phillip
Sent: Wednesday, March 05, 2008 3:27 PM
To: Jim Fenton; John Levine
Cc: DKIM List
Subject: Re: [ietf-dkim] draft-iab-dns-choices-05 and tree climbing
(fwd)

-----Original Message-----

-Jim