The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
RFC 7671

Note: This ballot was opened for revision 13 and is now closed.

(Ben Campbell) Yes

Comment (2015-08-04 for -14)
No email
send info
Thanks for this. I only have some editorial comments, and others have beaten me to the punch on all save the following:

-- Section 8, first paragraph:

   This section updates [RFC6698] by specifying a requirement on the
   TLSA Publisher to ensure that each combination of Certificate Usage,
   selector and matching type in the server's TLSA RRset MUST include at
   least one record that matches the server's current certificate chain.

"Requirement on the ... publisher to ensure...that each combination... MUST include..." is sort of an odd construction for a 2119 MUST.  Does the following capture the intent?

NEW:
   This section updates [RFC6698] by specifying that the
   TLSA Publisher MUST ensure that each combination of Certificate Usage,
   selector and matching type in the server's TLSA RRset includes at
   least one record that matches the server's current certificate chain.
END

(Stephen Farrell) Yes

(Kathleen Moriarty) Yes

Comment (2015-08-03 for -14)
No email
send info
Thanks for the discussion and updates from the SecDir review.
https://www.ietf.org/mail-archive/web/secdir/current/msg05871.html

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Comment (2015-08-05 for -14)
No email
send info
Last sentence of p.6: "In other words, when all four usages are supported, PKIX-TA(2) and"  should be PKIX-TA(0)

Deborah Brungard No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2015-08-04 for -14)
No email
send info
Thanks for working on this.

I agree generally with the editorial comments others have already made and I have a few more.

Section 4: 
s/generally RECOMMENDED./RECOMMENDED./
s/a mixture of clients; some supporting/a mixture of clients, some supporting/

Section 4.2:
I note that this section is silent about the interaction between CT and the PKIX-TA(0) and PKIX-EE(1) usages. I'm assuming the implication is "go ahead and use CT if you want to in those cases," but whatever it is, might it be worth making it explicit here?

Section 10.3:
"A service with DNSSEC-validated TLSA records implicitly promises TLS
   support.  When all the TLSA records for a service are found
   "unusable", due to unsupported parameter combinations or malformed
   associated data, DANE clients cannot authenticate the service
   certificate chain.  When authenticated TLS is mandatory, the client
   SHOULD NOT connect to the associated server."

Seems like that last requirement should be a MUST NOT.

Section 14:
"When TLS is opportunistic, the client MAY proceed to use
   the server with mandatory unauthenticated TLS."

I find the use of the word "mandatory" here confusing -- what is mandatory in the opportunistic case? Seems like this would make more sense without the word "mandatory."

(Spencer Dawkins) No Objection

Comment (2015-08-03 for -14)
No email
send info
Thanks for producing this document. I wish the IETF could produce more like it.

I had a bunch of editorial comments and questions. I see how nuanced the recommendations are, so I might just lack the background to understand some of the material, but I wanted to pass them along.

I was sort of surprised that the first two paragraphs of the introduction were about TLS and DTLS, and DANE wasn't mentioned until the third paragraph. Maybe move the third paragraph to the top of the section?

In section 1.1, in this text:

   TLSA parameters:  In [RFC6698] the TLSA record is defined to consist
      of four fields.  The first three of these are numeric parameters
      that specify the meaning of the data in the fourth and final
      field.  This document refers to the first three fields as "TLSA
      parameters", or sometimes just "parameters" when obvious from
      context.

I was pretty lost until I got to section 2, where at least the first three fields were named - the fourth wasn't named until the last line of Section 2.1. Any chance all four fields could be named here? 

In section 4, in this text:

   Protocol designers need to carefully consider which set of DANE
   certificate usages to support.  Simultaneous support for all four
   usages is NOT RECOMMENDED for DANE clients.  Protocol designers are
   encouraged to specify use of either the PKIX-TA(0) and PKIX-EE(1)
                                ^^^^^^                ^^^
   certificate usages, or the use of the DANE-TA(2) and DANE-EE(3)
                       ^^                           ^^^
   usages.  When all four usages are supported, an attacker capable of
   compromising the integrity of DNSSEC needs only to replace server's
   TLSA RRset with one that lists suitable DANE-EE(3) or DANE-TA(2)
   records, effectively bypassing an added verification via public CAs.
   In other words, when all four usages are supported, PKIX-TA(2) and
   PKIX-EE(1) offer only illusory incremental security over DANE-TA(2)
   and DANE-EE(3).
   
I'm sure the third sentence is accurate, but it took me a while to parse the logical operators and figure out that the point was XOR ((A and B), (C and D)) (I think). I think the paragraph would actually be clearer with that sentence completely removed.

About six paragraphs down into section 5.1, I see

   TLSA records published for DANE servers should, as a best practice,
   be "DANE-EE(3) SPKI(1) SHA2-256(1)" records.
   
Is this an unqualified "do this in all cases"? If so, it's buried really deeply. If not, it wasn't obvious to me what the qualifications might be.

Just as a nit, in section 5.2.2, I see

   With DANE-TA(2), a complication arises when the TA certificate is
   omitted from the server's certificate chain, perhaps on the basis of
   Section 7.4.2 of [RFC5246]:

   The sender's certificate MUST come first in the list.  Each
   following certificate MUST directly certify the one preceding
   it.  Because certificate validation requires that root keys be
   distributed independently, the self-signed certificate that
   specifies the root certification authority MAY be omitted from
   the chain, under the assumption that the remote end must
   already possess it in order to validate it in any case.
   
Is that where the quote stops? I didn't check, but indenting the quote would help.

Thanks for including section 10.1.1, UDP and TCP Considerations.

In section 10.1.2,

   While TLSA records using a TLSA Selector of SPKI(1) and a TLSA
   Matching Type of Full(0) (which publish the bare public keys without
   the overhead of a containing X.509 certificate) are generally more
   compact, these are also best avoided as when significantly larger
                                        ^^^^^^^
   than their digests.
   
The ^^^^ text wasn't parsing for me. "because they are/can be significantly larger"? But I'm guessing.

In section 10.3,

   If, on the other hand, the use of TLS is "opportunistic", then the
   client SHOULD generally use the server via an unauthenticated TLS
   connection, but if TLS encryption cannot be established, the client
   MUST NOT use the server.  Standards for DANE specific to the
   particular application protocol may modify the above requirements, as
   appropriate.
   
I found myself wondering how you'd know modifying those requirements is appropriate. Is there any guidance you could give, or an example?

In section 11,

   When the registrar is also the DNS operator for the domain, one needs
   to consider whether the registrar will allow orderly migration of the
   domain to another registrar or DNS operator in a way that will
   maintain DNSSEC integrity.  TLSA Publishers SHOULD ensure their
   registrar publishes a suitable domain transfer policy.
   
I'm thinking that's not an RFC 2119 SHOULD, but if it is, I wonder why it's not a MUST ...

I have the same thoughts about this text in section 11,
   
   DNS Operators SHOULD use a registrar lock of their domains
   to offer some protection against this possibility.

and this text, in the following paragraph.

   TLSA Publishers SHOULD ensure their
   registrar publishes a suitable domain transfer policy.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2015-08-01 for -14)
No email
send info
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.

Barry Leiba No Objection

Comment (2015-07-29 for -14)
No email
send info
Editorial comments only -- most very minor, but one for Section 4 and its subsections is more substantive.

-- Section 1 --

   DNSSEC validated DANE TLSA
   records can be used to augment or replace the use of trusted public

Too many cascading modifiers can make a sentence confusing (even if you were to hyphenate "DNSSEC-validated", as it should be).  I suggest untangling that slightly, this way:

NEW
   DANE TLSA records validated by
   DNSSEC can be used to augment or replace the use of trusted public
END

   [RFC6698] defines three TLSA record fields with respectively 4, 2 and
   3 currently specified values.

There's nothing to correspond with "respectively" here (compare that with the correct use in the first paragrah of the Introduction).  Try this:

NEW
   [RFC6698] defines three TLSA record fields, the first with 4 possible
   values, the second with 2, and the third with 3.
END

-- Section 3 --
A bit of awkward wording here, and an overly long sentence, both easily fixed:

OLD
   When a servers does
   support SNI, but is not configured with a certificate chain that
   exactly matches the client's SNI extension, SHOULD respond with some
   other (default or closest match) certificate chain, since clients may
   support more than one server name, but can only put a single name in
   the SNI extension.
NEW
   When a server supports SNI but is not configured with a certificate
   chain that exactly matches the client's SNI extension, the server
   SHOULD respond with another certificate chain (a default or closest
   match).  This is because clients might support more than one server
   name, but can only put a single name in the SNI extension.
END

-- Section 4 --

   Protocol designers need to carefully consider which set of DANE
   certificate usages to support.

I'm not sure why this (and the next sentence) is referring to "protocol designers".  Is this not aimed at implementation/deployment choices?  If that's not correct, who are the targets for this advice?

I also find this section to be rather hard to follow -- I can't clearly figure out what the advice really is.  Can you do a little reorganization here, separating the advice out from the explanation of why?  I don't care whether you put the explanation first or the advice first, but it would help to have one paragraph that says, clearly and without fuss, what the recommendation is.  This applies to the subsections as well.

(Terry Manderson) No Objection

Alvaro Retana No Objection