Spencer Dawkins 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: ---------------------------------------------------------------------- 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. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
