Subject: Re: [ietf-dkim] New Thread: Use of CNAME in place of NS subdomain delegation

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Aug 2006 16:53:49 -0400

On Monday 28 August 2006 16:51, Jim Fenton wrote:

> And, of course, it assumes that the delegator can create CNAME records.

Thanks,

Unlike NS delegation, I'm not aware of any DNS providers that do not support 
CNAMES (not that I've made an extensive survey, but all three that I use 
support it).  

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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Aug 2006 16:26:05 -0400

One of the major reasons I've been promoting the idea of the third party 
authorized list/DSD is to allow smaller domains that do not have the ability 
to do subdomain NS delegation to get the effective benefit of first party 
signing.  So, when I saw this:

On Saturday 26 August 2006 23:16, Wietse Venema wrote:

> (*) This is possible even when the signer is in a different domain.
>     All they need is the private key that matches the public key
>     in the d= DNS record. That record can, but does not have to,
>     be CNAME delegated to the signer's DNS.

I was interested.  Is a CNAME a reasonable alternative to the subdomain NS 
delegation approach that's been described previously?  I don't recall this 
being mentioned before.  It makes sense to me, but I certainly hadn't thought 
of it.  If this is viable, it changes, somewhat, my perspective on the 
significance of the requirement that we've stopped discussing for now.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Aug 2006 17:05:42 -0400

On Monday 28 August 2006 16:58, Michael Thomas wrote:

> This has been discussed before, and the answer is that it doesn't work very
> well. You can't, for instance, CNAME an interior node -- just leaf
> nodes. For
> DKIM, the ability to roll selector names pretty much means you'd want to
> manage
> the subtree not just a leaf. I expect for any sort of scale and/or key
> management on
> the target of the CNAME, you'd end up with a lot of broken links.

Thanks,

But wouldn't Jim's suggestion of pre-creating extra CNAMES allow for key 
management by the operator?

Keeping in mind that we are focused on small domains that don't have the 
ability to do subdomain NS delegation, do you think that for small scale the 
approach would be reasonably useful?  

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Aug 2006 13:58:57 -0700

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Aug 2006 14:22:54 -0700

>approach would be reasonably useful?  
That assumes you know what the operator will name the new selectors -- that
seems a bit problematic in the large, but for some situations might be 
ok. I didn't
even realize the Jim was using CNAME's for his selectors...

       Mike

---

From: Eric Allman <[email-masked]>
Date: Mon, 28 Aug 2006 14:27:53 -0700

>> ... [discussion of CNAME]
>>
> Yes, it works; I was signing my home domain's messages with a CNAMEd
> selector for a while for testing.  It relieves some, but not all,
> of the issues with key delegation by TXT record.
>
> The major concern I have heard with publication of a TXT record
> (selector) containing a public key controlled by a delegatee is
> that key rotation is awkward, since it requires coordination by the
> delegator and delegatee.  While a CNAME would allow the delegatee
> to change the key on a selector directly, recommended practice is
> that a new selector name be used (see dkim-base-05, section 3.1,
> last paragraph).  The delegator could pre-create a number of CNAME
> records for the delegatee to use, but that still requires more
> coordination (albeit less frequently) than NS delegation.

The delegator could also hand over a subset of the namespace, e.g., 
using

   delegatee._domainkey.delegator.com.  IN  CNAME
                        delegatee._domainkey.delegatee.com.

(wrapping for readability only).

eric

---

From: Eric Allman <[email-masked]>
Date: Mon, 28 Aug 2006 14:31:52 -0700

--On August 28, 2006 2:27:53 PM -0700 Eric Allman 
<[email-masked]> wrote:
> The delegator could also hand over a subset of the namespace...

Erk.  "Never mind" --- I had forgotten that CNAMEs only work for leaf 
nodes.

eric

---

From: Jim Fenton <[email-masked]>
Date: Mon, 28 Aug 2006 13:51:00 -0700

Yes, it works; I was signing my home domain's messages with a CNAMEd
selector for a while for testing.  It relieves some, but not all, of the
issues with key delegation by TXT record.

The major concern I have heard with publication of a TXT record
(selector) containing a public key controlled by a delegatee is that key
rotation is awkward, since it requires coordination by the delegator and
delegatee.  While a CNAME would allow the delegatee to change the key on
a selector directly, recommended practice is that a new selector name be
used (see dkim-base-05, section 3.1, last paragraph).  The delegator
could pre-create a number of CNAME records for the delegatee to use, but
that still requires more coordination (albeit less frequently) than NS
delegation.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Aug 2006 15:16:28 -0700

On Aug 28, 2006, at 2:48 PM, Wietse Venema wrote:

>
> Michael Thomas:
>> That assumes you know what the operator will name the new  
>> selectors -- that seems a bit problematic in the large, but for  
>> some situations might be ok. I didn't even realize the Jim was  
>> using CNAME's for his selectors...
>
> For long-term applications, the need to pre-create  
> selector2006/2007/etc. is an inconvenience. For short-term  
> applications, however, a CNAME may have more benefits. It allows a  
> site maintain control over what names are delegated. With  
> delegation of an entire DNS subtree there is less control over the  
> delegated name space.

A CNAME outside DNS also comes at the expense of adding a DNS  
transaction and a point of failure.  A CNAME transcription error used  
at some point in the future may take a while to resolve when it does  
become problem.  This may be difficult to resolve when the CNAME  
appears to point to a valid key.  Scaling may create namespace  
densities where such errors are not always apparent and could be  
induced by either the provider or the domain owner.  It is not as  
simple as put these CNAMES "here" pointing "there", the g=, s=, t=  
and TTL are also details a domain owner may wish to be able to alter.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Mon, 28 Aug 2006 17:48:07 -0400 (EDT)

Michael Thomas:
> ok. I didn't even realize the Jim was using CNAME's for his selectors...

For long-term applications, the need to pre-create selector2006/2007/etc.
is an inconvenience. For short-term applications, however, a CNAME
may have more benefits. It allows a site maintain control over what
names are delegated. With delegation of an entire DNS subtree there
is less control over the delegated name space.

	Wietse

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 28 Aug 2006 23:35:04 -0400

----- Original Message -----
From: "Eric Allman" <[email-masked]>
To: "Jim Fenton" <[email-masked]>
> (wrapping for readability only).

Eric,

I am wondering if we are getting into areas that are unknown or can change
or not supported across the board, when in fact, the only thing we do know
is that a QUERY is done with a TXT record (or eventually an specific RR
record if that happens).

In order words, that is all the ADMIN needs to know in regards to the
outside world.  The outside world will be a doing a TXT query so any DNS
administration ideas on how that information is best extract in only a
server side thing.

In short, CNAME, NS, or whatever, should this level of details be part of
the spec or some separate doc?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Aug 2006 22:57:28 -0700

> the spec or some separate doc?

This doc should have a chapter dedicated to vendor specific issues.  The
CNAME technique might play a useful role when done within the DNS.  When
done outside the DNS, extra transactions are needed and additional
problems may appear.  There are often issues discovered with the way
Microsoft implements DNS strategies. There are various failure modes
resulting from a non-monolithic implementation.  When a CNAME is not
within their DNS, Active Directory captures address glue.  For some
versions, when this information changes, update issues might result.

-Doug

---

From: Eric Allman <[email-masked]>
Date: Tue, 29 Aug 2006 07:35:33 -0700

--On August 28, 2006 11:35:04 PM -0400 Hector Santos 
<[email-masked]> wrote:

> In short, CNAME, NS, or whatever, should this level of details be
> part of the spec or some separate doc?

Definitely not a normative part of the spec, lest we head down the 
slippery slope of describing how basic underlying technology works. 
I think a small amount of informative text can be useful, although if 
it gets to be too much (which in this case is not unlikely) it might 
be moved to a separate doc.

eric

---

From: [email-masked] (Wietse Venema)
Date: Wed, 30 Aug 2006 09:57:34 -0400 (EDT)

> and TTL are also details a domain owner may wish to be able to alter.

Thanks for bringing up an argument that can be applied against any
form of delegation.

Regardless of whether one uses DNS built-in methods (CNAME=leaf
node delegation, NS=interior node delegation), or application-defined
methods such as indirection via TXT records, there will be extra
network I/O, there will be opportunity for bad TTL information,
delegation to a non-existent target, and there will be loss of
control over the information that a delegatee hands out.

These issues are inherent with delegation, and since everything
rides on top of DNS anyway, it seems to me that application-defined
delegation methods that attempt to side-step DNS "problems" just
add their own problems to it.

	Wietse

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 30 Aug 2006 11:13:22 -0400

From: "Wietse Venema"

> These issues are inherent with delegation, and since
> everything rides on top of DNS anyway, it seems to me
> that application-defined delegation methods that attempt
> to side-step DNS "problems" just add their own problems to it.

This also applies to DKIM DNS PUBLIC KEY lookup as well. Do you have a
appliction defined plan for this?

In any case, this is an exception to the rule.  Not the rule.

It is equivalent to MX lookup failures. We have application defined methods
to deal with it.

In general, there is no reason why we can't deal with general DNS related
issues.  We already do for our current service needs.

Keep in mind that DKIM is a payload solution so there is ample solutions for
a system to put a message on hold due to some DKIM DNS lookup failure if
that is what the local policy wants.  We may even want to allow it the first
time, but if it is constant, then it moves it into another category.  It may
even use a GreyList concept! Who knows?

All this is just part of the implementation details.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Aug 2006 10:25:22 -0700

On Aug 30, 2006, at 6:57 AM, Wietse Venema wrote:

>> transaction and a point of failure.  A CNAME transcription error  
>> used at some point in the future may take a while to resolve when  
>> it does become problem.  This may be difficult to resolve when the  
>> CNAME appears to point to a valid key.  Scaling may create  
>> namespace densities where such errors are not always apparent and  
>> could be induced by either the provider or the domain owner.  It  
>> is not as simple as put these CNAMES "here" pointing "there", the  
>> g=, s=, t= and TTL are also details a domain owner may wish to be  
>> able to alter.
>

This and other comments were specific to your suggestion.  CNAME had  
been raised on the list, with the conclusion the less said the  
better.  Discovering the cause of an expected problem is usually  
preceded with an anxious phone call, often late at night.  Uncovering  
lame configurations subsequent to an automated rollover, or CNAME  
related failure requiring prodding are implementation specific.   
Unexpected problems are a serious pitfall however.  It may not be  
long before support staff ban the "defective" service.  These issues  
relate to postponed employment and fragile CNAME implementations  
outside the DNS.

> node delegation, NS=interior node delegation), or application- 
> defined methods such as indirection via TXT records, there will be  
> extra network I/O, there will be opportunity for bad TTL  
> information, delegation to a non-existent target, and there will be  
> loss of control over the information that a delegatee hands out.

CNAME can hide latent issues when used for "future" exchanges.  The  
automated CNAME redirections outside the DNS are unfortunately less  
than elegant in some cases.

> add their own problems to it.

The number of entities involved in making a change represents a  
greater concern, not DNS itself.  Scaling will be a sizable effort  
just for DKIM policy to enable millions of email-addresses to  
designate their "prolocutor of address validity".  This does not  
involve restructuring DNS zones or cooperative efforts of 3 or 4  
entities.  A "prolocutor designate" must indicate when the email- 
address is valid.  While validating an email-address is not a  
function of DKIM, "asserting" when an email-address is valid should  
be a function of DKIM that extends beyond the signing domain.   
Without this ability, the value of DKIM drops to its lowest  
denominator.  The efforts to administer such designations can be done  
autonomously, and should not alter the "reputation" dynamics.

An email-address signed by a designated domain may be annotated  
differently than an email-address within the signing domain.  This  
annotation still provides significant protections for millions of  
users.  There is little to justify that allowing users to list a  
"prolocutor designate" is too complicated and a horrendous security  
concern.  This sounds too much like "People still can't tell when  
their email is valid.  Well, let them delegate their zones with NS  
records."

It is balderdash to describe designating a domain as representing a  
security concern in comparison to allocating one's namespace or  
allowing access to private keys.  A designation does not affect the  
integrity of a signature one iota.  It does allow market forces to  
elect "prolocutor designates" that have demonstrated the greatest  
integrity in a very democratic fashion.  Three cheers for the  
"prolocutor designates". : )

-Doug