Ballot for draft-ietf-dane-ops
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
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
Thanks for the discussion and updates from the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg05871.html
Last sentence of p.6: "In other words, when all four usages are supported, PKIX-TA(2) and" should be PKIX-TA(0)
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."
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.
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.
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.