Reviewer: Magnus Westerlund Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. So this review is not really a IETF last call review. It was initiated on the request of the transport AD in preparation for the IESG review. Looking on the below I would note that this was likely an error on my part in the triaging of this document in TSV-ART. So please do what you find appropriate to do with this information. 1) Section 3.1.1: "Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS." Considering that no earlier version MUST be negotiated, the second part of above sentence appears redundant. 2) Section 3.1.1: "Rationale: Several stronger cipher suites are available only with TLS 1.2 (published in 2008). In fact, the cipher suites recommended by this document for TLS 1.2 (Section 4.2 below) are not available in older versions of the protocol." Are they not available in newer versions either? If they are not then please be explicit, if not, then the rationale would be to consider to go to never versions. I think the main reason for staying on 1.2 is if you need other features not available in TLS 1.3 like mutual re-authentication. So maybe this rational should be updated to indicate more like why 1.2 may be preferred over 1.3 than why it is preferred over the earlier version which shall not be used. Based on our work on DTLS/SCTP https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/ really the issue we found with using (D)TLS 1.3 have been related to long lived sessions and how TLS 1.3 keyUpdate works. I think three aspects we found in the DTLS/SCTP work is relevant here for consideration and do affect applications in their choice. • Periodic re-authentication and transfer of revocation information of both endpoints (not only the DTLS client). • Periodic rerunning of Diffie-Hellman key-exchange to provide forward secrecy and mitigate static key exfiltration attacks. • When using keyUpdate the master secret isn't impacted, which results in applications using TLS exporter to derive key material are not getting new keys if re-envoking the exporter after a keyUpdate. Thus, application protocols using the TLS exporter needs to take this into account to include epoch counters or similar in the key-derivation process and it will not result in forward secrecy. I would note that QUIC v1 uses its own key update mechanism as defined in Section 6 of RFC 9001 that I think illustrates this. For DTLS/SCTP we did go with a more complex method based on creating new DTLS connections and dealing with handling of two connections in parallel due to SCTPs capability for parallel transmission of data. That also avoided use to have to rely solely on DTLS 1.2 to handle these issues and we can use DTLS 1.3 and likely any future DTLS version too. Section 4.4: When a sender is approaching CL, the implementation SHOULD initiate a new handshake (or in TLS 1.3, a Key Update) to rotate the session key. When a receiver has reached IL, the implementation SHOULD close the connection. These are clearly the right advice. However, depending on your protocol this might be far from easy to accomplish without tearing down the whole protocol session or context. I would actually add some wording here about the need to consider how that can be accomplished in the protocol protected by (D)TLS. If you want an example I would recommend to point to DTLS/SCTP as the protocols multi-stream non head of line blocking nature makes a clean cut over difficult and instead results in a fairly complex mechanism to handle parallel DTLS connections while one ensure that all data protected by the old connection is drained out of the lower layers. Also as noted above RFC 9001 section 6 indicates yet another way of doing it. However, I think it is a method that has the downside of creating key derivation and signalling in an application protocol. There are some potential gremlins here that might be worth at least warning application protocol writers about. Cheers Magnus Westerlund -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
