Subject: Re: [apps-discuss] [dane] AppsDir review of

From: Martin Rex <[email-masked]>
Date: Sat, 5 May 2012 00:24:50 +0200 (MEST)

Andrew Sullivan wrote:
> 
> On Fri, May 04, 2012 at 02:58:53PM -0600, Peter Saint-Andre wrote:
> >    3.  The domain name is appended to the result of step 2 to complete
> >        the prepared domain name.  (The domain name is the fully
> >        qualified DNS domain name [RFC1035] of the TLS server and is
> >        represented as a byte string using ASCII encoding without a
> >        trailing dot; this enables support for internationalized
> >        domain names through the use of A-labels as defined in
> >        [RFC5890].)
> 
> I don't understand that definition of "the domain name".  What we
> appear to be discussing here is how you prepare the presentation
> format for the domain name; "represented as a byte string using ASCII
> encoding" doesn't make a lot of sense to me in this context.  
> 
> In particular, you don't need any of the text starting with
> "represented" and ending with the semicolon, because what you're
> describing there isn't properly speaking a domain name at all.  It's a
> relative domain name, which happens to be relative to the root.  It's
> also in presentation format, which is irrelevant for DNS query
> purposes, because we don't send queries in presentation format.
> 
> It sounds like the key point you want to make is that IDNA2008 labels
> MUST be in A-label format before transformation.  Is that it?

We added similar text like the above to rfc6066 (TLS extensions)
for the description of the extension "Server name indication" here:

  http://tools.ietf.org/html/rfc6066#page-7

3rd paragraph on page 7

Could you point to an existing document that contains a suitable
1-paragraph desciption that you believe fits better here?
I don't think that we should be inventing a new description
for ever new document, but preferably re-use what is already there.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 May 2012 00:37:45 +0200 (MEST)

> for ever new document, but preferably re-use what is already there.

That "we added to rfc6066" refers to this disussion in the TLS WG:

  https://www.ietf.org/mail-archive/web/tls/current/msg07233.html

Re-reading that paragraph, I realize that the description
"fully qualified DNS hostname of the server" is factually incorrect
for rfc6066 (I don't know about DANE, though).

When used by HTTP-over-TLS, it ought to be the name as used by the
client for performing server endpoint identification (rfc2818 or rf6125),
and that _can_ be a hostname without domain from a URL!!

-Martin

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 18:38:20 -0400

> for the description of the extension "Server name indication" here:

The problem in this case, however, is that what the TLSA document is
doing is building a QNAME for use in the DNS.  None of the description
from RFC 6066 is a domain name.

Remember, the dot-separated labels are the presentation form, but
_not_ what you send on the wire.  Dots aren't part of the DNS on the
wire.  

What we want to do for this case is get the QNAME for the DNS.  So we
take the two labels that come out of steps 1 and 2 in the draft, and
put them on the front of the DNS name that we're trying to look up,
creating an absolute, fully qualified name that gets sent in the QNAME
of the DNS operation.  

At least I think that's what the section is trying to do.

I'm also uncomfortable with the "ASCII" stuff, because DNS labels
aren't in ASCII.  They're octets.  However, ASCII is treated specially
in the DNS.  (This is one of the sharp edges about the DNS that we'd
all like to go back and fix if we could.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: SM <[email-masked]>
Date: Fri, 04 May 2012 15:50:49 -0700

Hi Martin,
>1-paragraph desciption that you believe fits better here?

I'll skip the tricky question. :-)

>for ever new document, but preferably re-use what is already there.

The text from that section of RFC 6066 is about FQDNs.

RFC 6394 mentions that 'the process of obtaining this "source" domain 
is application specific [RFC6125]'.   It seems like the better choice 
to keep things easy.  It also matches what's in Section 4 of the draft.

Regards,
-sm

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 May 2012 06:38:12 +0200 (MEST)

> all like to go back and fix if we could.)

Thanks for pointing out the details.  I have been an occasional caller of
gethostbyname(), and not used libresolv function() like res_query().

Do we expect the target audience (folks implementing DANE protocol)
to use an API like that of libresolv's res_query(), where the representation
appears to be still a single string rather than individual DNS labels,
or that they're caller of even lower APIs?

The name that gets prefixed by protocol and port should probably
represent an absolute, fully qualified name as is, and be used with
res_query?  The default behaviour of gethostbyname(), trying completion
of a name that doesn't end with a dot/period with (default) domain or
entries from a (domain) searchlist (res_search?) would likely
risk unpleasant consequences.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 5 May 2012 07:21:51 -0700

> At least I think that's what the section is trying to do.

It is indeed what the section is trying to do.

> all like to go back and fix if we could.)

Note that the document explicitly states in the last paragraph of section 1.2 that "This document only relates to securely associating certificates for TLS and DTLS with host names". We are not talking just "domain names" (which are made up of labels of octets) but "host names" which are made up of labels of ASCII. We were told (wisely) not to try to reopen this can of worms, so we didn't.

As you pointed out, Peter's proposed wording had an issue by mentioning the "dots". That can easily be fixed. I now propose:

OLD
  3.  The domain name is appended to the result of step 2 to complete
      the prepared domain name.

NEW

  3.  The domain name is appended to the result of step 2 to complete
      the prepared domain name.  (The domain name is the fully
      qualified DNS domain name [RFC1035] of the TLS server and is
      represented as a byte string where each label is encoded
      using ASCII; this enables support for internationalized
      domain names through the use of A-labels as defined in
      [RFC5890].)

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 06 May 2012 19:07:31 -0600

>       domain names through the use of A-labels as defined in

Works for me.

Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 May 2012 11:13:01 -0400

On Sat, May 05, 2012 at 07:21:51AM -0700, Paul Hoffman wrote:
> 
> Note that the document explicitly states in the last paragraph of
> section 1.2 that "This document only relates to securely associating
> certificates for TLS and DTLS with host names".  We are not talking
> just "domain names" (which are made up of labels of octets) but
> "host names" which are made up of labels of ASCII. We were told
> (wisely) not to try to reopen this can of worms, so we didn't.

Aha, good point.  I guess this needs a normative reference to RFC 952,
then?  That's actually the most recent RFC that establishes the host
rules.

>       domain names through the use of A-labels as defined in

I'm still uncomfortable with this, because it's not technically
accurate.  When you send the QNAME, it's not a "byte string" and the
labels aren't encoded.  They're octets, not strings.

How about 

    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 [RFC952].  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].

?  I added the modifier "base" to this to make it clear that we're not
defining what domain names are, although I don't myself feel too
strongly about that addition.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 May 2012 11:14:37 -0400

> or that they're caller of even lower APIs?

They'll certainly need to call something other than getaddrinfo(),
because they need to know whether validation succeeded and you can't
find it out that way.

> risk unpleasant consequences.

Indeed.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 May 2012 12:51:13 +0100

>         A-label form as defined in [RFC5890].

I like this.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole: Variable 4 in east at first, otherwise northeasterly 5 to 7. Moderate or
rough. Occasional rain. Moderate or good.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 May 2012 06:38:58 -0600

>>         A-label form as defined in [RFC5890].

WFM.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 May 2012 13:52:27 +0200

>        A-label form as defined in [RFC5890].

This also works for me.  Unless I hear any objections from WG, I think we
can use this text and close the issue.

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------