IETF conflict review for draft-dukhovni-tls-dnssec-chain
conflict-review-dukhovni-tls-dnssec-chain-02
Yes
No Objection
(Alvaro Retana)
(Martin Duke)
(Robert Wilton)
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Erik Kline
No Objection
Comment
(2021-05-29 for -00)
Not sent
I support requesting the authors to consider Ben's comments.
Murray Kucherawy
No Objection
Comment
(2021-06-02 for -00)
Sent
I support requesting the authors to consider Ben's comments.
Roman Danyliw
No Objection
Comment
(2021-06-02 for -00)
Not sent
I support requesting the authors to consider Ben's comments.
Warren Kumari
No Objection
Comment
(2021-06-02 for -00)
Sent
I am balloting No Objection. What I actually *want* to ballot is "this is work which *should* have been done in the IETF, but I understand why it wasn't", but, strangely, that button doesn't exist.... It's good work, and I wish it could have been easier to get through the process; thanks authors!
Zaheduzzaman Sarker
No Objection
Comment
(2021-06-02 for -00)
Not sent
coping what Erik wrote - "I support requesting the authors to consider Ben's comments."
Éric Vyncke
No Objection
Comment
(2021-06-01 for -00)
Sent
I suggest to add DPRIVE to the list of related WG as it is vaguely related. -éric
Benjamin Kaduk Former IESG member
Yes
Yes
(2021-05-27 for -00)
Sent
IESG There's a couple points that I want to raise for the IESG's attention as they evaluate whether the current "no conflict" response is correct. (1) There is a note in Section 4 that: If a record in the chain has a very short TTL (eg 0 up to a few seconds), the server MAY decide to serve the authentication chain a few seconds past the minimum TTL in the chain. [...] This seems like what's going to happen regardless of what we say, but I just wanted to raise its visibility in case anyone felt otherwise. (2) Section 7 says: For a non-zero saved value of the ExtSupportLifetime element of the extension, TLS clients MUST mandate ("pin") the use of this extension by the corresponding TLS servers for the time period specified by the pinning value. [...] The wording here is perhaps more sensitive than it first appears. As written it seems to say that the client must require the server to use the extension, but the server is only allowed to use the extension if the client requests it first. I note that for a recent similar case on the IETF stream, I entered a DISCUSS ballot (https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ballot/#benjamin-kaduk). I expect that the authors will be willing to change the wording (per the COMMENT, a simple s/use of/support for/ would work), but even with the current formulation, it's not clear that a "violates IETF procedures" conflict-review response is appropriate. In particular, this says that the client has to require the server to send the extension, but not that the server actually does have to send the extension. So the combination of this requirement on the client with the TLS requirement on the server would result only in a broken exchange, but not (AFAICT) behavior that violates the TLS specification. COMMENT Since I was reading the document anyway, I took the opportunity to record some comments (as well as some nit-level remarks that are unlikely to merit a response, in a separate section). Hopefully the authors and ISE find them useful and treat them as they would any other review of the document. First off, thanks for continuing with this work even after the TLS WG was unable to come to consensus. It's good to have this technology written up and published, and I think you did a good job writing up the portions that are "new" with respect to the WG draft (as well as the security considerations thereof!). Section 1 In the absence of TLSA records, this extension conveys the required authenticated denial of existence. Such proofs are needed to securely signal that specified TLSA records are not available so that TLS clients can safely fall back to WebPKI based authentication if allowed by local policy. [...] (While there was a lot of discussion in the TLS WG about WebPKI vs DANE, TLS itself, even with X.509 PKI or PKIX, is not limited to just the WebPKI as trust anchors.) This extension also mitigates against an unknown key share (UKS) attack [I-D.barnes-dane-uks] when using raw public keys, since the server commits to its DNS name (normally found in its certificate) via the content of the returned TLSA RRset. I think the situation here may be slightly more subtle, as there is (AFAIR) not anything that prevents the server from stuffing in random unrelated TLSA RRs in what it sends back to the client. That is, there may not be a single "the returned TLSA RRset". However, the server does commit to its DNS name, since we assert that the semantics of using this extension is that the server accepts the SNI name sent by the client. (Presumably this holds regardless of whether the server also sends the SNI extension back in SH(1.2)/EE(1.3).) The content of the TLSA RRset (for that name) is used in validating that the server is in fact authenticated as that name, but committing to the DNS name is done via a different mechanism. Section 2.1 The set of supported combinations of port number and SNI name may be configured explicitly by server administrators, or could be inferred from the available certificates combined with a list of supported ports. It is important to note that the client's notional port number may be different from the actual port on which the server is receiving connections. I might further make the connection that the "client's notional port number" is the one that's in the configured list of supported ports, not the actual port on which the server is listening. Section 2.2 I strongly suggest reiterating that the server does not send anything if the extension is not present in the ClientHello. In TLS 1.3 [RFC8446], the server adds its "dnssec_chain" extension to the extension block of the Certificate message containing the end entity certificate being validated, rather than to the extended ServerHello message. This is clear and unambiguously specified, and in that sense unobjectionable. It's a little weird to put something that's mostly about a CA cert in the extension block for the EE cert (for the PKIX-TA()0) and DANE-TA(2) certificate usage values), but probably not worth introducing more complications for. (The pinning lifetime is not about the CA cert, though, of course.) TLS servers supporting this extension that do not have a signed TLSA record MUST instead return a DNSSEC chain that provides authenticated denial of existence. [...] I suggest to reiterate that this is a denial of existence for the SNI name in the ClientHello, as opposed to some arbitrary name by which the server identifies itself. Section 6 Clients MAY cache the server's validated TLSA RRset to amortize the cost of receiving and validating the chain over multiple connections. The period of such caching MUST NOT exceed the TTL associated with those records. [...] How does the caching interact with the extension pin time? (I would expect "SHOULD NOT exceed the pin time", but don't see anything to justify a strict requirement to do so.) Note that when a client and server perform TLS session resumption the server sends no "dnssec_chain". This is particularly clear with TLS 1.3, where the certificate message to which the chain might be attached is also not sent on resumption. I'd suggest a reminder that "if the client is attempting resumption, it still sends the "dnssec_chain" extension for use if resumption fails and a full handshake is needed" (or similar; it's not required, but the mechanism won't be available if not sent). Section 7 For a non-zero saved value of the ExtSupportLifetime element of the extension, TLS clients MUST mandate ("pin") the use of this extension by the corresponding TLS servers for the time period specified by the pinning value. [...] The wording here is perhaps more sensitive than it first appears. As written it seems to say that the client must require the server to use the extension, but that cannot be universally true, since the TLS specification requires the server to *not* use the extension if the client doesn't offer it in the ClientHello. If we talk about "support for" rather than "use of", this concern goes away (and there are surely other ways to finesse the language as well). If this document was on the IETF stream I would put a DISCUSS on it until this point is clarified (see, e.g., https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ballot/#benjamin-kaduk), though I am hopeful that it can be fixed without incurring the overhead of a "violates IETF procedures for TLS" conflict-review response. If during this time, the TLS client does not have a valid TLSA record and connects to a TLS server using this extension for the associated name and port, and it does not obtain a valid authentication chain in this extension, it MUST either abort the (Similarly, it's not entirely clear that "does not have a valid TLSA record" is really relevant for the criterion here, it seems to be enough that the client asks, regardless of what the client may also have on hand already.) connection or delay communication with the server via the TLS session until it is able to obtain valid TLSA records (or non-existence proof) out of band, such as via direct DNS lookups. If attempts to obtain the TLSA RRset out of band fail, the client MUST abort the TLS session. We switch from "connection" to "session" here. Both are used as terms of art in TLS (with different meaning); is the change intentional? (I would, perhaps naively, have assumed that "connection" is intended throughout.) Section 9 Delivery of application services is often provided by a third party on behalf of the domain owner (hosting customer). Since the domain owner may want to be able to move the service between providers, non- zero support lifetimes for this extension should only be enabled by mutual agreement between the provider and domain owner. Is it true that the upper bound on the time that clients are expected to continue to use a pin is actually the nominal (advertised) pin time plus the relevant DNS TTL in effect at the time (since the server could continue to serve the extension with those DNS records for that duration)? This might be an operational consideration worth mentioning (that the DNS TTL as well as the advertised pin time are to be considered in assessing the impact of switching providers without coordinating the pin expiry). To avoid confusion, it is RECOMMENDED that server operators not publish TLSA RRs (_port._tcp. + base domain) based on the expanded CNAMEs used to locate their network addresses. Instead, the server operator SHOULD publish TLSA RRs at an alternative DNS node (as in the example above), to which the hosting customer will publish a CNAME alias. This results in all clients (whether they obtain TLSA records from DNS directly, or employ this extension) seeing the same TLSA records and sending the same SNI name. I suspect I'm confused, but I'm failing to see how a client that follows the RFC 7671 CNAME expansion would end up at the provider-published TLSA record in this scenario (that is, at _dane443.node1.provider.example in the example above). Wouldn't they look for _443._tcp.node1.provider.example and get nothing back? Section 11 Since the extension contents sent by the server contains an unonrdered bag of DNS records, we may want to discuss the possibility that the server sends records unrelated to DANE authentication of itself, and what steps the client can/should take in such scenarios in order to remain in a safe state. This could be achieved by running a time synchronization protocol like NTP [RFC5905] or SNTP [RFC5905], which are already widely used I note that RFC 8915 (network time security for NTP) has been published since tls-dnssec-chain was started. It seems like it would be a useful reference here as well (albeit perhaps not as "already widely used"). Section 14 I don't see much reason for RFCs 7858 and 8310 to be classified as normative. (draft-ietf-dnsop-svcb-https is also perhaps borderline, but we do place some requirements on servers when they are the target of such records, so it seems okay to leave as normative.) Appendix A I'm happy to see that a lot of thought and care went into producing the examples. Sadly, I'm not in a position to actually verify them in a useful way. (I guess I did seem to get a different certificate from example.net than the one listed here, but that doesn't seem worth worrying about.) NITS Abstract This document describes an experimental TLS extension for in-band transport of the complete set of DNSSEC validated records needed to perform DANE authentication of a TLS server without the need to perform separate out-of-band DNS lookups. [...] The word "validate" here causes me to stumble. While we do expect the TLS server to have validated the records before sending, that's not a key part of the protocol -- the TLS client independently performs DNSSEC validation in order to get the value out of having the records. It would read better to me if we dropped the word entirely, or maybe switched it to "validatable". (Essentially the same text is in the Introduction as well.) Section 1.1 The mechanism described in this document, is intended to be done with applications on the wider internet. One application of TLS well No comma needed. s/done with/used by/ In fact, one of the authentication methods for DNS over TLS _is_ the mechanism described in this document, as specified in Section 8.2.2 of [RFC8310]. If I was feeling pedantic I'd say "a precursor to" or similar, since the mechanism is only essentially the same. The need for the mechanism when DANE authenticating DNS over TLS resolver is obvious, since DNS may not be available to perform the s/the mechanism/this mechanism/ or s/the mechanism/such a mechanism/ Also, s/authenticating/authenticating a/ In the TLS working group, concerns have been raised that the pinning technique, as described in Section 7 would complicate deployability Either two commas around "as described in Section 7" or zero. Section 2.1 Otherwise, the server's extended ServerHello message MUST contain a serialized authentication chain using the format described below. If the server does not have access to the requested DNS chain - for example due to a misconfiguration or expired chain - the server MUST omit the extension rather than send an incomplete chain. [...] Pedantically, the two MUSTS seem to be in conflict. (The first one is maybe not needed, for "ServerHello message contains".) HTTPS or SVCB records MUST be provisioned to process client extensions based on the client's logical service endpoint's SNI and port as it is prior to HTTPS or SVCB indirection. Other than here, we're pretty consistent about saying "SNI name" or "SNI hostname" when we're not talking about the extension itself. (I suppose we could pick one of "name" and "hostname", too, though that does not seem to bother me as much.) Section 2.3 The returned RRsets MUST contain either the requested TLSA RRset, or else the associated denial of existence proof. In either case, the chain of RRs MUST be accompanied with the full set of DNS records needed to authenticate the TLSA record set or its denial of existence s/the TLSA record set/the requested TLSA record set/ When some subtree in the chain is subject to redirection via DNAME records, the associated inferred CNAME records need not be included, they can be inferred by the DNS validation code in the client. [...] The second comma is a comma splice. In the case of a denial of existence response, the authentication chain MUST include all DNSSEC signed records from the trust-anchor zone to a proof of non-existence of either the (possibly redirected via aliases) TLSA records or else of an insecure delegation above or at the (possibly redirected) owner name of the requested TLSA RRset. As written, this says that there is a "proof of non-existence of an insecure delegation" in the case where an insecure delegation is involved and a denial of existence is needed. This does not match my understanding (though my understanding could be flawed) -- I thought that affirmative evidence of an insecure delegation (that is, proof of non-existence of a *secure* delegation) was used in a denial of existence response. The following is an example of (hypothetical) insecure delegation of "example.com" from the ".com" zone. This example shows NSEC3 records with opt-out. An (informative) referece to RFC 5155 for NSEC3 might be in order. onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 - onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG) I find it rather implausible that a "real" example would produce hashed owner name and next hashed owner name that differ only in the last character :) I'm also having a bit of a hard time reproducing the hashed owner name as onib9mgub9h0rml3cdf5bgrj59dkjhvj. If I'm reading it right, the hash is 1 (SHA-1), iteration count 0, and salt empty ('-'), so I should be looking at something like: $ printf "\x07example\x03com\x0"|sha1sum|unhex |base32|tr [A-Z] [a-z] yxsljwq6ljra3wvdmnpflq3tfjnutr7u But I assume I'm just making a dumb error somewhere and the examples are actually correct. Section 8 The trust anchor may change periodically, e.g. when the operator of comma after "e.g." (as well as before). Section 15 It's a bit surprising to use [HAMPERING] as the slug for what seems to be a research paper that collected data on the availability of DNSSEC aware and validationg resolvers to stub resolvers.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -00)
Not sent
Lars Eggert Former IESG member
No Objection
No Objection
(2021-05-31 for -00)
Sent
Using lowercase "not" together with an uppercase RFC2119 keyword is not acceptable usage. Found: "SHALL not", "MUST not" ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2, paragraph 4, nit: - In the absense of TLSA records, this extension conveys the required - ^ + In the absence of TLSA records, this extension conveys the required + ^ Section 2, paragraph 6, nit: - This extension also mitigates againts an unknown key share (UKS) - - + This extension also mitigates against an unknown key share (UKS) + + Section 3.3, paragraph 20, nit: - equal to or is the closest ancestore of the requested TLSA RRset, and - - + equal to or is the closest ancestor of the requested TLSA RRset, and Section 3.3, paragraph 24, nit: - intermediate betwen the requested name the owner of the DNAME + intermediate between the requested name the owner of the DNAME + + Section 6, paragraph 5, nit: - Clients MAY cache the server's validated TLSA RRset to ammortize the - - + Clients MAY cache the server's validated TLSA RRset to amortize the Section 7, paragraph 4, nit: - extension. A non-zero extenion pin value received MUST ONLY be used - if the extention also contains a valid TLSA authentication chain that - ^ + extension. A non-zero extension pin value received MUST ONLY be used + + + if the extension also contains a valid TLSA authentication chain that + ^ Section 7, paragraph 7, nit: - Upon completion of a full validated hanshake with a server that + Upon completion of a full validated handshake with a server that + + Section 10, paragraph 3, nit: - it must properly decommission its use. If a non-zero pin lifetim is + it must properly decommission its use. If a non-zero pin lifetime is + + Section 3.3, paragraph 13, nit: > , the chain of RRsets MUST be accompanied with the full set of DNS records n > ^^^^^^^^^^^^^^^^ The usual collocation for "accompany" is "by", not "with". Section 3.3, paragraph 15, nit: > et at the requested domain name. 2. An signed SOA record and signed NSEC or > ^^ Use "A" instead of 'An' if the following word doesn't start with a vowel sound, e.g. 'a sentence', 'a university'. Section 3.3, paragraph 22, nit: > hain that disproves the existence of a a secure delegation to - or of - the T > ^^^ Maybe you need to remove one determiner so that only "a" or "a" is left. Section 3.3, paragraph 25, nit: > ot). This trust anchor is also preconfigured in the TLS client, but includin > ^^^^^^^^^^^^^ Do not mix variants of the same word ('preconfigure' and 'pre-configure') within a single text. Section 6, paragraph 4, nit: > ure against such downgrade attacks. It's value represents the number of hours > ^^^^ It seems that the possessive pronoun "its" fits better in this context. Section 14.1, paragraph 12, nit: > te is valid, which is in between November 28 2018 and December 2 2020, with t > ^^^^^^^^^^^ Commas set off the year in a month-day-year date: "November 28,". Section 14.1, paragraph 12, nit: > in between November 28 2018 and December 2 2020, with the following root tr > ^^^^^^^^^^ Commas set off the year in a month-day-year date: "December 2,". Obsolete reference to RFC5246, obsoleted by RFC8446 (this may be on purpose). These URLs in the document can probably be converted to HTTPS: * http://www.nlnetlabs.nl/downloads/publications/os3-2015-rp2-xavier-torrent-gorjon.pdf
Martin Duke Former IESG member
No Objection
No Objection
(for -00)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(for -00)
Not sent