Subject: [dane] Joel Jaeggli's No Objection on draft-ietf-dane-ops-14: (with COMMENT)

From: "Joel Jaeggli" <[email-masked]>
Date: Sat, 01 Aug 2015 20:14:57 -0700

Joel Jaeggli has entered the following ballot position for
draft-ietf-dane-ops-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dane-ops/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

from fred baker's opsdir review, I would like to see a commnet on these
from the authors.

thanks
joel

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Aug 2015 02:27:27 +0000

On Sat, Aug 01, 2015 at 08:14:57PM -0700, Joel Jaeggli wrote:

> COMMENT:
> 
> From fred baker's opsdir review, I would like to see a commnet on these
> from the authors.

Sure.

On Tue, Jun 23, 2015 at 07:32:56PM +0000, Fred Baker (fred) wrote:

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

The latest version is:

   The DNS-Based Authentication of Named Entities (DANE) specification
   ([RFC6698]) introduces the DNS "TLSA" resource record type ("TLSA" is
   not an acronym).  TLSA records associate a certificate or a public
   key of an end-entity or a trusted issuing authority with the
   corresponding TLS transport endpoint.  DANE relies on the DNS
   Security Extensions (DNSSEC, [RFC4033]).  DNSSEC validated DANE TLSA
   records can be used to augment or replace the use of trusted public
   Certification Authorities (CAs).

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

To me the paragraph looks fine as-is, it refers to augmenting or
replacing "the use of trusted public CAs", not the CAs themselves.
If we speak instead of replacing or augmenting the Web PKI, we'd
need to explain what the Web PKI is (a bunch of trusted public
CAs).  So it is I think simpler to just say what is meant.

If the text does not look sufficiently clear to others, I'm open
to suggestions.

> document, require definition.

A definition of "public key" has already been added to the terminology
section.  The term PKI is listed as "well-known" at:

    https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

The remaining proposed addition to the terminology section is "CA",
which is expanded on first use, but not specifically defined in
the terminology section.  I might note that the terminology section
of RFC 6698 consists entirely of a reference to other RFCs: 

   This document also makes use of standard PKIX, DNSSEC, TLS, and
   DNS terminology.  See [RFC5280], [RFC4033], [RFC5246], and STD
   13 [RFC1034] [RFC1035], respectively, for these terms.  In
   addition, terms related to TLS-protected application services
   and DNS names are taken from [RFC6125].

Would anything like that be appropriate for this draft (which now
that I think of it still needs to add 6698 to the "updates" list)?

-- 
	Viktor.