Last Call Review of draft-ietf-dane-ops-12
review-ietf-dane-ops-12-opsdir-lc-baker-2015-06-30-00

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational
aspects of the IETF drafts. Comments that are not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

Document reviewed:  draft-ietf-dane-ops-12

Summary: Ready to go, two comments that might be considered last call or IESG
comments if the AD agrees.

I think the opening paragraph of the introduction needs some tweaking.

   The DANE TLSA specification ([RFC6698]) introduces the DNS "TLSA"
   resource record type.  TLSA records associate a certificate or a
   public key of an end-entity or a trusted issuing authority with the
   corresponding TLS transport endpoint.  DNSSEC validated DANE TLSA
   records can be used to augment or replace the use of trusted public
   Certification Authorities (CAs).

I'm not an expert on this, but I think it would be more accurate to say that it
replaces a PKI, not a CA. A CA probably deploys and operates a PKI. However, it
does so in the context of a business - it vets entities that it will sell
certificates to, and then sells them certificates, which it stores somewhere
such as a PKI. I would expect that the CA, in this model, would have the same
business (and hence is not replaced), but store its certificates in TLSA
records instead of or in addition to in a PKI.

In section 1.1, a number of terms are defined, including "public key". If
"public key" needs definition (which it does, as the term is used to
specifically refer to a field within a certificate, as opposed to a more
general cryptographic usage), I think "Certificate Authority (CA)" and "Public
Key Infrastructure (PKI)", which are also used throughout the document, require
definition.

You note that neither of these comments is substantive with respect to the
protocol, the record, or the operational recommendations that the draft makes.

Operationally, the document poses no requirements on operators as a general
class. It does require that a DNS operator implement DNSSEC (else I'm not sure
how one trusts a TLSA), and it has a number specific directions to the CA about
the TLSA records it asks the DNS operator to store. However, an operator that
simply offers transit service, for example, is not affected.

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail