The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
draft-ietf-dane-ops-16

[Ballot comment]
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

[Ballot comment]
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."

[Ballot comment]
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.

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

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dane-ops-12, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Updates to and Operational Guidance for the DANE Protocol) to Proposed Standard


The IESG has received a request from the DNS-based Authentication of
Named Entities WG (dane) to consider the following document:
- 'Updates to and Operational Guidance for the DANE Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document clarifies and updates the DNS-Based Authentication of
  Named Entities (DANE) TLSA specification (RFC6698) based on
  subsequent implementation experience.  It also contains guidance for
  implementers, operators and protocol developers who want to make use
  of DANE records.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dane-ops/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested: Standards Track.  This document
updates RFC 6698, which is a Standards Track document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Technical Summary:

This document clarifies and updates the DNS-Based Authentication of Named
Entities (DANE) TLSA specification based on subsequent implementation
experience.  It also contains guidance for implementers, operators and
protocol developers who want to make use of DANE records.

Working Group Summary:

This document receieved significant discussion, and reflects new
understanding of how DANE is being used and deployed. It provides advice to
operators and implementors.

Document Quality:

This document describes how to actually use and interpret RFC 6698 now that
we have some experience with it. It is very clearly written, easily
understood, and makes a good introductory document as well.


Personnel:

Warren Kumari is the Document Shepherd, Stephen Farrell is Responsible...

(3) Briefly describe the review of this document that was performed by the
Document Shepherd.  The DS has followed the progression of the document as
it progressed through its many versions. The document has had a long life,
and the authors have done a great job of keeping it alive, and updated as we
have gained new experience.

(4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?  Nope.

(5) Do portions of the document need review from a particular or from
broader perspective?  Nope.

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should
be aware of?  None.

(7) Has each author confirmed that any and all appropriate IPR disclosures?
Yes.

(8) Has an IPR disclosure been filed that references this document?
No


(9) How solid is the WG consensus behind this document?
Strong. The final
WGLC only get a few responses, but they were positive, and the document has
received significant discussion and updates over the years.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
Nope.

(11) Identify any ID nits the Document Shepherd has found in this document.
None.


(12) Describe how the document meets any required formal review criteria.
It doesn't --- largely because there are none.


(13) Have all references within this document been identified as either
normative or informative?
Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?
No. There are two
*informative* references to drafts, one of which is with the IESG, the other
with the RFC Editor.

(15) Are there downward normative references references (see RFC 3967)?
Nope.

(16) Will publication of this document change the status of any existing
RFCs?
This updates RFC 6698.  This is on the title
page, listed in the abstract, and there is a section (12) explaining the
changes. The introduction discusses why updates / clarifications were made,
and points to the section describing the changes.

(17) Describe the Document Shepherd's review of the IANA considerations
section.
"This specification requires no support from IANA." -- I'll spare
you the standard joke about having read that multiple times, the font,
etc... at least, this time....

(18) List any new IANA registries that require Expert Review for future
allocations.
None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal language,
such as XML code, BNF rules, MIB definitions, etc.
No formal language in
the document.