Oops. Datatracker butchered the formatting. Let's try that again: ~~~ Reviewer: Christopher Wood Review result: Has Issues Comments: - Section 1.1, fourth bullet: I assume certificate revocation is also out of scope. If so, listing this explicitly might be useful. If not, why not? Relatedly, is pre-shared key authentication supported? If so, perhaps we should mention that this too is out of scope? - If TLS sits below TCPCL and if resumption is used, what is the definition of a session's lifetime? Is it still bound to the underlying TCP connection lifetime? I would suggest that the definition be generalized to accommodate TLS, e.g., perhaps the lifetime is bound to the underlying transport state lifetime. Relatedly, is TLS session resumption supported (or encouraged)? When discussing TLS session establishment in Section 4, this seems to be omitted. - Section 3.2, first paragraph: What does "initiate TLS security" mean, exactly? Does this mean the initiator sends a TLS ClientHello upon TCP connection establishment, or only after some other TCPCL headers are exchanged? Similarly, is the Node ID transferred used in authenticating such a TLS connection? If so, how? Is the Node ID sent as the TLS SNI, as hinted at in Section 4.4.1 and 4.4.2, is it included in the responder's certificate SAN list, etc? I think specific details are needed here, perhaps with forward pointers to Section 4 as needed. - Section 3.2: It's not clear to me how SESS_TERM translates to graceful TLS termination (to avoid truncation attacks). The state machine diagram outlined in Section 3.3 suggests that SESS_TERM, once negotiated, does imply the end of the data transfer. It therefore seems possible for an attacker to truncate data sent between receipt of SESS_TERM and TCP FIN by simply closing the TCP connection. It would be good to require use of a TLS closure alert when finished to avoid this type of truncation. (Maybe BP prevents this by marking data transfer lengths. However, even if that's the case, proper use of TLS seems prudent.) - Section 4, first paragraph: If entities are encouraged to keep sessions alive for as long as possible, guidance on how to update TLS keying material (via key updates or explicitly tearing down the connection and starting anew) seems prudent. TLS has a bound on how much data can be encrypted under one key. - Section 4: This text: Once a TCP connection is established, each entity MUST immediately transmit a contact header over the TCP connection. suggests that TLS does *not* proceed as normal upon TCP connection establishment. This is quite problematic, since any active attacker can simply muck with the ContactHeader CAN_TLS bit to disable TLS, right? Is this threat not considered in scope? Relatedly, what is the threat model? (SSL stripping is mentioned in Section 8, but without mention of a threat model.) "Secure" sessions subject to active downgrade do not offer much in the way of security, and the document should acknowledge that in the Security Considerations. Concretely, how about the following text to replace the second paragraph in Section 8? TCPCL does not protect against active network attackers. In particular, an active man-in-the-middle attackers to set the CAN_TLS flag to 0 on either side of a TCPCL ContactHeader exchange. This leads to the "SSL Stripping" attack described in [RFC7457]. If TLS is desired for use on any TCPCL network, it is strongly encouraged that the security policy disallow use of TCPCL when "Enable TLS" is negotiated to false. This requires that the TLS handshake occurs, regardless of the policy-driven parameters of the handshake and policy-driven handling of the handshake outcome. - Section 4.4.2: Why is the recommendation that entities "SHOULD terminate the session" if the peer's certificate is untrusted, rather than "MUST terminate the session"? In what circumstances would an entity not want to terminate the connection? (Later text mentions that this may be allowed by "security policy," in which case we should mention that here.) - Section 4.4.2, fourth paragraph: Why is host name validation done *after* TLS completes, rather than during the connection? This seems wrong, though I suspect I'm misunderstanding the details. - 4.7, Enable TLS: If security policy allows the absence of TLS, why not just always use TLS and have that policy tune TLS peer authentication? (See https://tools.ietf.org/html/rfc7858#section-4.1 for an example of this.) It seems strange that opportunistic security is supported (and desired as a feature?) yet not always used. - Section 8: I see no reason why one would want to use TLS for authentication without any form of confidentiality. I would remove text referencing this use case. - Section 8: In describing volumetric DoS attacks, it might help to consider the "opposite" sort of attack, e.g., similar to what the HTTPT/2 data dribble attack exploited? (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9511) Nits: - Section 2.1, TCP Connection: typo in "and other states association" (should be associated?) - Section 2.1, Transmission Intermediate Progress: typo "transferr" (and elsewhere) - Inconsistent notation of SESS_TERM (it's referred to as SESSTERM in lots of places) - Section 3.4, last paragraph: typo "from from" - Section: typo "negotating" -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
