[dane] WGLC: DANE-SRV ("Address Queries" and "TLSA queries" 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 3.2 ("Address Queries") and 3.3 ("TLSA Queries").

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

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.