Subject: Re: [dane] CNAME thread feedback

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 20 Apr 2013 04:14:37 +0000

On Fri, Apr 19, 2013 at 02:45:32PM -0700, SM wrote:

> At 16:11 17-04-2013, Viktor Dukhovni wrote:
> >Understood, but at least everyone stopped ignoring me. :-)
> 
> I am not ignoring you.  I read the messages discussing about CNAMEs. :-)

Thanks, any feedback on the CNAME thread then?

   6698 Section 3:

   3.  The base domain name is appended to the result of step 2 to
       complete the prepared domain name.  The base domain name is the
       fully qualified DNS domain name [RFC1035] of the TLS server, with
       the additional restriction that every label MUST meet the rules
       of [RFC0952].  The latter restriction means that, if the query is
       for an internationalized domain name, it MUST use the A-label
       form as defined in [RFC5890].

There is no normative text telling applications what the phrase:
"the base domain name" means, it could well be the domain name
obtained after the application securely chases CNAME RRs, especially
with SRV and MX RRs where we're not supposed to have CNAME targets,
so resolving targets to underlying hosts avoids working with CNAMEs.

Similarly A.2 merely highlights the DNS semantics of CNAMEs with
respect to child nodes, it also does not contain any normative text
about what "base domain name" is to be chosen by the verifier.

My argument is that both the verifier and the server operator
benefit from cleaner/simpler key management if "base domain name"
means the target host after resolving any DNSSEC validated CNAME
RRs.  This is an opportunity for DANE to reduce the key-management
burden of TLS virtual hosting, don't miss the opportunity.

If this view has no positive support here, at the very least expect
some implementation variability.  Mine will perhaps not be the only
implementation that looks for TLSA RRs post CNAME expansion.

-- 
	Viktor.

---

From: SM <[email-masked]>
Date: Sat, 20 Apr 2013 09:29:33 -0700

Hi Victor,
>so resolving targets to underlying hosts avoids working with CNAMEs.

I'll say that I do not see a definition of "base domain name".

>about what "base domain name" is to be chosen by the verifier.

Yes.

>implementation that looks for TLSA RRs post CNAME expansion.

There is significant CNAME usage for virtual hosting to avoid or 
reduce operational issues.  Sometimes the usage can be in 
contradiction with what is specified in a RFC.

I read a message where Section 5.1 of some RFC was mentioned [1].  As 
my quick reaction was "ok" I didn't comment about that. If it is 
possible to reduce the key-management burden I am all for it.  I 
prefer to discuss about a specific application protocol instead of 
taking a wider approach as it may not be clear what the 
all-encompassing solution should be.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/dane/current/msg05586.html