[dane] WGLC: DANE-SRV (Abstract and introduction feedback)

[Viktor Dukhovni <[e-mail]>]

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

> >>http://tools.ietf.org/wg/dane/draft-ietf-dane-srv
> >
> >I have extensive comments throughout the document, but I don't know
> >how to best process them. One comment-bomb message?
> 
> Unfortunately, yes.

[ 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 that abstract and introduction.

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

1. Abstract:

    General comment, not just certificates, but also public keys, or
    more simply "key material".  The new version is also more compact.

  OLD:

    <t>The DANE specification (RFC 6698) describes how to use TLSA
     resource records in the DNS to associate a server's host name with
     its TLS certificate, where the association is secured with DNSSEC.
     However, application protocols that use SRV records (RFC 2782) to indirectly
     name the target server host names for a service domain cannot apply
     the rules from RFC 6698. Therefore this document provides guidelines
     that enable such protocols to locate and use TLSA records.</t>

  NEW:

    <t>
     The DANE specification (RFC 6698) describes how to use DNSSEC
     secured TLSA resource records to associate a transport endpoint
     with corresponding TLS key material.  This document builds on
     RFC 6698 to specify DANE for application protocols that use SRV
     records (RFC 2782) to indirectly locate the transport endpoints
     associated with a given service at a service domain.
    </t>

2.  Introduction first two paragraphs:

    Align with similar language in the abstract, deal with hostname
    versus transport endpoint.  More concise.

  OLD:

    <t>The base DANE specification <xref target="RFC6698"/> describes
     how to use TLSA resource records in the DNS to associate a
     server's host name with its TLS certificate, where the association is
     secured using DNSSEC. That document "only relates to securely
     associating certificates for TLS and DTLS with host names" (see
     the last paragraph of section 1.2 of
     <xref target="RFC6698"/>).</t>
 
    <t>Some application protocols do not use host names directly; instead,
     they use a service domain, and the relevant target server host names are located
     indirectly via SRV records <xref target="RFC2782"/>.
     Because of this intermediate resolution step, the normal DANE rules
     specified in <xref target="RFC6698"/> cannot be applied to
     protocols that use SRV records. (Rules for SMTP
     <xref target='RFC5321'/>, which uses MX records instead of SRV records,
     are described in <xref target="I-D.ietf-dane-smtp-with-dane"/>.)</t>

  New:

    <t>
     The base DANE specification <xref target="RFC6698"/> describes
     how to use DNSSEC <xref target="RFC4033"/> secured TLSA resource
     records to associate a transport endpoint with corresponding
     TLS key material.  Some application protocols locate transport
     endpoints indirectly via SRV records <xref target="RFC2782"/>.
     As a result of this indirection, the rules specified in <xref
     target="RFC6698"/> cannot be applied verbatim to protocols that
     use SRV records. (Rules for SMTP <xref target='RFC5321'/>, which
     uses MX records instead of SRV records, are described in <xref
     target="I-D.ietf-dane-smtp-with-dane"/>.)
    </t>

2.  Introduction summary:

    The most notable clarification below is that TLS is only
    mandatory, for a given transport endpoint, when DNSSEC validated
    TLSA records are present, whether usable or not.  If at least
    one record is usable, the peer must be authenticated.

    If referencing OPS creates timing difficulties, because (for
    some reason not clear to me) OPS is being held back relative
    to SMTP and SRV, detailed CNAME language can be found in
    the SMTP draft (modulo MX<->SRV substitution).

Add to references:

    <!ENTITY I-D.ietf-dane-ops PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dane-ops.xml">

  OLD:
 
      <t>We rely on DNSSEC to secure the association between the
       service domain and the target server host names (i.e., the
       host names that are discovered by the SRV query).</t>
 
      <t>The TLSA records are located using the port, protocol, and
       target server host name fields (not the service domain).</t>
 
      <t>Clients always use TLS when connecting to servers with TLSA
       records.</t>
 
      <t>Assuming that the association is secure, the server's
       certificate is expected to authenticate the target server host
       name, rather than the service domain.</t>

  NEW:

      <t>
       We rely on DNSSEC to secure SRV records that map the desired
       service, transport protocol and service domain to corresponding
       target transport endpoints (i.e., the host names and ports
       that are returned in the SRV records).
      </t>
 
      <t>
       TLSA records for each transport endpoint are located using
       the target port, tranport protocol, and target host name.  In
       particular, TLSA records are not located directly via the
       service domain.
      </t>
 
      <t>
       When DNSSEC validated TLSA records are published for a
       particular transport endpoint, and the endpoint supports both
       cleartext and TLS communication, clients SHOULD use TLS when
       connecting to that endpoint.
      </t>

      <t>
       When at least one TLSA record is usable, the server's
       certificate or public key MUST match at least one of the
       usable TLSA records.  The primary reference identity for
       peername checks is the TLSA base domain (generally the target
       host name) with the service domain also supported for
       compatibility with legacy deployments.  Additional acceptable
       peer names may arise as a result of CNAME expansion of either
       the service domain or (if supported) the target hostname.
       See <xref target="I-D.ietf-dane-ops"/> for details.
      </t>

-- 
	Viktor.