Last Call Review of draft-ietf-dane-ops-12

Request Review of draft-ietf-dane-ops
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-06-24
Requested 2015-06-11
Authors Viktor Dukhovni, Wes Hardaker
Draft last updated 2015-06-30
Completed reviews Genart Last Call review of -12 by Elwyn Davies (diff)
Genart Telechat review of -14 by Elwyn Davies (diff)
Secdir Last Call review of -12 by Tina Tsou (diff)
Opsdir Last Call review of -12 by Fred Baker (diff)
Assignment Reviewer Fred Baker
State Completed
Review review-ietf-dane-ops-12-opsdir-lc-baker-2015-06-30
Reviewed rev. 12 (document currently at 16)
Review result Has Nits
Review completed: 2015-06-30


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

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.




 Message signed with OpenPGP using GPGMail