Subject: Re: [dane] WGLC: DANE-SRV

From: Stephen Farrell <[email-masked]>
Date: Mon, 01 Dec 2014 09:30:44 +0000

Hi Peter,

On 01/12/14 01:48, Peter Saint-Andre - &yet wrote:
> 
>> A git repo
>> with many commits?
> 
> That is not covered by IETF IPR rules.

Just to note that some other WGs (e.g. HTTPbis, tls) are
successfully using git repos for drafts and issue tracking.
That can work and not be a problem with IETF IPR processes,
but it does need to be managed and is some new work for the
chairs, so it's not quite "free."

Cheers,
S.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 01 Dec 2014 09:19:50 -0700

> chairs, so it's not quite "free."

Well, I'll leave that up to the chairs, then. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Michael J. Sheldon" <[email-masked]>
Date: Tue, 2 Dec 2014 22:33:00 +0000

>On Sun, Nov 30, 2014 at 06:48:41PM -0700, Peter Saint-Andre - &yet wrote:
>General comment:
>
>    The draft frequently talks about "hostnames", where what is
>    really meant is a transport endpoint (port, transport protocol,
>    host).  With PKIX-EE or DANE-EE certificate usages, TLSA records
>    are more precise than the Web PKI and can associate different,
>    non-interchangeable key material with distinct services on a
>    single host.  So in many places I will be suggesting replacing
>    statements about "hostnames" with statements about "transport
>    endpoints".

>From a DNS point of view, this may be more confusing. DNS does not distinguish between different types of record owners. If you put it in there, it just became a domain name, which most people will refer to as a host name if it is not at the apex.

I will agree that from a DANE point of view, it is a transport endpoint. But from a pure DNS point of view, it is domain/host name, regardless of intent.

Not saying it's not a good distinction, it is, but I would tread lightly where you are talking about the actual TLSA record owner name.

Michael Sheldon
Dev-DNS Services
GoDaddy.com

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Dec 2014 05:19:49 +0000

On Tue, Dec 02, 2014 at 10:33:00PM +0000, Michael J. Sheldon wrote:

> From a DNS point of view, this may be more confusing. DNS does
> not distinguish between different types of record owners. If you
> put it in there, it just became a domain name, which most people
> will refer to as a host name if it is not at the apex.

You misunderstood my point.  The issue is not about DNS owner names.
The issue is that SRV records designate a (port, hostname) pair,
not just a hostname, and the input to TLSA lookup is a (port,
protocol, hostname) triple not just a hostname.

> Not saying it's not a good distinction, it is, but I would tread
> lightly where you are talking about the actual TLSA record owner
> name.

I am not talking about DNS owner names at all.  The association in
DANE TLSA is between a transport endpoint and its key material.
The fact that we construct some DNS name to find this is secondary,
(and in fact that owner name is NOT a hostname due to the various
underscores, but that's not important).

Since SRV also produces lists of transport endpoints, and unlike
the Web PKI, the certificates in DANE TLSA can (and often should)
be different for different services on the same machine, the
discussion is much clearer if we don't gloss over the fact that
the TLSA binding is NOT a hostname->key binding.

I hope to post further feedback on Thursday evening.  It would be
useful if possible to get additional initial reaction to the proposed
changes in the abstract and introduction.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 6 Dec 2014 23:20:54 +0000

[ I'm splitting it into a few messages to keep it manageable, and
  in any case some of my comments are still pencil marks on a
  print-out, not yet transcribed. ]

This message covers sections 2 ("Terminology") and 3.1 ("SRV Query").

General comment (copied verbatim from abstract and introduction
feedback):

2. Terminology:

    General comment, this section is a bit too short I think.  More
    terms should perhaps be defined.  I will propose a not necessarily
    comprehensive list.

    Add a suitable definition of "transport endpoint" (or some
    other name if the imprecision noted below is objectionable):

	Transport Endpoint:  In this document, a triple which combines

	   * A DNS hostname which abstracts a set of IPv4 and/or
	     IPv6 addresses.
	   * A transport protocol (TCP or UDP)
	   * A port number which specifies a TCP or UDP service
	     deployed at the addresses associated with the hostname.

	DANE TLSA records associate key material with transport
	endpoints.  Because this definition of a transport endpoint
	uses a hostname and not a network address, strictly speaking
	what we have is an indirect reference to a set of related TCP
	or UDP endpoints.

    Likely a good idea to paste in some relevant definitions from the SRV
    RFCs (e.g. "service domain").

Section 3.1 "SRV Query" first paragraph, bottom of page 3/top of
page 4 (refine the words "helpful summary"):

  OLD:

    <t>When the client makes an SRV query, a successful result will
     typically be a list of one or more SRV records (or possibly a chain of
     CNAME / DNAME aliases leading to such a list).  Implementers need to
     be aware that unsuccessful results can occur because of various
     DNS-related errors; a helpful summary can be found in section 2.1 of
     <xref target="I-D.ietf-dane-smtp-with-dane"/>.</t>

  New:

    <t>When the client makes an SRV query, a successful result will
     typically be a list of one or more SRV records (or possibly a chain of
     CNAME / DNAME aliases leading to such a list).  Implementers need to
     be aware that unsuccessful results can occur because of various
     DNS-related errors; guidance on avoiding downgrade attacks can be found
     in section 2.1 of <xref target="I-D.ietf-dane-smtp-with-dane"/>.</t>

Next paragraph (since the terminology section claims definitions
of "secure", ...  from 4035, quote from 4035, not 4033).  Be more
precise about aliases.  I think the text about the AD bit is should
either be deleted or expanded (a lot), the application may be doing
its own validation, and the AD is the irrelevant, or some discussion
is needed about when AD-bits might be trustworthy.

  OLD:

    <t>For this specification to apply, the entire DNS RRset that is
     returned MUST be "secure" according to DNSSSEC validation
     (<xref target="RFC4033"/> section 5).  In the case of aliases, the
     whole chain of CNAME and DNAME RRsets MUST be secure as well.
     This corresponds to the AD bit being set in the response(s); see
     <xref target="RFC4035"/> section 3.2.3.</t>

  NEW:

    <t>For this specification to apply, the entire DNS RRset that is
     returned MUST be "secure" according to DNSSSEC validation
     (<xref target="RFC4035"/> section 4.3).  In case the answer is
     obtained via a chain of CNAME and/or DNAME aliases, the
     whole chain of CNAME and DNAME RRsets MUST also be secure.

Next paragraph (number 3 of section 3.1)
 
  Again drop AD-bit discussion and improve wording.

  OLD:

    <t>If the the entire RRset is "insecure", this protocol has
     not been correctly deployed.  The client SHOULD fall back to
     its non-DNSSEC, non-DANE behavior (this corresponds to the AD
     bit being unset).  If the entire RRset is "bogus", the client
     MUST abort the attempt.</t>

  NEW:

    <t>If the lookup result is "insecure", this protocol does
     not apply.  The client SHOULD fall back to its non-DNSSEC,
     non-DANE behavior.  If the SRV lookup fails (including the
     case that the RRset is "bogus"), the client MUST abort its
     to contact the desired service.  </t>

Next (number 4 of section 3.1)

  SRV lookup returns candidate "Transport endpoints", not hostnames,
  mention requirement for secure CNAME/DNAME indirection once more.

  OLD:

    <t>In the successful case, the client now has an authentic list of
     target server host names with weight and priority values. It performs
     server ordering and selection using the weight and priority
     values without regard to the presence or absence of DNSSEC or
     TLSA records. It also takes note of the DNSSEC validation status of
     the SRV response for use when checking certificate names (see
     <xref target="tls"/>). The client can now proceed to making address
     queries on the target server host names as described in the next
     section.</t>

  NEW:

    <t>When the lookup returns a "secure" RRset, perhaps via a
     chain of "secure" CNAME/DNAME records, the client now has an
     authentic list of target transport enpdoints with weight and
     priority values. It performs server ordering and selection
     using the weight and priority values without regard to the
     presence or absence of DNSSEC or TLSA records. It also takes
     note of the DNSSEC validation status of the SRV response for
     use when checking certificate names (see <xref target="tls"/>).
     The client can now proceed to making address queries on the
     target server host names as described in the next section.</t>

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 14 Dec 2014 22:45:01 +0000

This message covers sections 3.2 ("Address Queries") and 3.3 ("TLSA Queries").

3.2. Address Queries

  Clients that support only v4 or only v6 need not make queries for 
  an address type they can't use.

  OLD:

    <t>For each SRV target server host name, the client makes A and AAAA
     queries, performs DNSSEC validation on the address (A or AAAA) response,
     and continues as follows based on the results:

  NEW:

    <t>For each SRV target server host name, the client makes A and/or AAAA
     queries, performs DNSSEC validation on the address (A or AAAA) response,
     and continues as follows based on the results:

  The term "usable" is not applicable in the context of address
  queries.  TLSA queries should be made if either the A or AAAA
  response is secure (e.g., sometimes the absence of "AAAA" is
  "insecure" due to opt-out, while the "A" records are "secure").

  When the zone containing the host's A/AAAA records is unsigned,
  queries for TLSA are more likely to fail than to unexpectedly
  produce "secure" results.  This is not to say that they are in
  fact likely to "fail".

  OLD:

     <list style="symbols">
      <t>If the response is "secure" and usable, the client MUST perform a TLSA
       query for that target server host name as described in the
       next section.</t>
      <t>If the response is "insecure", the client MUST NOT perform a
       TLSA query for that target server host name; the TLSA query will
       most likely fail.</t>
      <t>If the response is "bogus" or "indeterminate", the client
       MUST NOT connect to this target server; instead it uses the next
       most appropriate SRV target.</t>
    </list></t>

  NEW:

     <list style="symbols">
      <t>If either of the A or AAAA RRsets is "secure", the client MUST
       perform a TLSA query for that target service endpoint as described
       in the next section.</t>
      <t>If both RRsets are "insecure", the client MUST NOT perform a
       TLSA query for that target; such TLSA queries are very
       unlikely to produce "secure" results and have been observed
       to spuriously fail even though no TLSA records are present.</t>
      <t>To defend against downgrade attacks, if address record
       lookup fails (this includes both the "bogus" and RFC 4035
       "indeterminate" validation status) the client MUST NOT
       connect to this target service endpoint; instead it uses the next
       most appropriate SRV target.</t>
    </list></t>

3.3. TLSA Queries

  Perhaps a better split:

  OLD:

    <t>For example, the following SRV record for IMAP (see <xref target='RFC6186'/>)
    leads to the TLSA query shown below:</t>

    <t><figure><artwork><![CDATA[
_imap._tcp.example.com. 86400 IN SRV 10 0 9143 imap.example.net.

_9143._tcp.imap.example.net. IN TLSA ?
     ]]></artwork></figure></t>

  NEW:

    <t>For example, the following SRV record for IMAP (see <xref target='RFC6186'/>)</t>

    <t><figure><artwork><![CDATA[
_imap._tcp.example.com. 86400 IN SRV 10 0 9143 imap.example.net.
     ]]></artwork></figure></t>

    <t>leads to the TLSA query shown below:</t>

    <t><figure><artwork><![CDATA[
_9143._tcp.imap.example.net. IN TLSA ?
     ]]></artwork></figure></t>

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 14 Dec 2014 23:44:48 +0000

This message covers 3.4 through the end of the document.

3.4. Impact on TLS Usage

   First bullet:

	s/under 4/in 4/

   Third bullet:

	s/If the TLSA response is "bogus" or "indeterminate"/If the TLSA lookup fails/

   perhaps noting that a "secure" or "insecure" NXDOMAIN is not a failure (as in DNS
   error section of SMTP draft).

4.1. SRV records only

  Second paragraph:

    Also mention here that 6125 and reference identifiers don't apply
    with DANE-EE(3) (some folks may not read as far as 4.2)

4.2 TLSA Records:

  The SMTP and OPS drafts have "toned down" the degree to which the
  content of DANE-EE(3) certs is ignored, specifically only the
  hostname and expiration are superseded by DNSSEC.  Other features
  of the certificate (key usage, ...) may still be taken into account.

Material after section 4 is largely fine.

  * Please update smtp-with-dane reference from -05 to -13.

  * Should he XMPP example SRV record really be "_xmpp-client",
    or instead "_xmpp-server"?  Not familiar with XMPP, so please
    pardon my confusion if that's what it is.

-- 
	Viktor.