[dane] WGLC: DANE-SRV (Terminology and "SRV Query" feedback)

[Viktor Dukhovni <[e-mail]>]

On Sun, Nov 30, 2014 at 06:48:41PM -0700, Peter Saint-Andre - &yet wrote:

[ 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):

    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".

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.