Re: [Tsv-art] Tsvart telechat review of draft-ietf-uta-rfc7525bis-09

[Peter Saint-Andre <[e-mail]>]

Hi Magnus, thanks for completing this review on short notice. Comments 
inline.

On 7/13/22 5:44 AM, Magnus Westerlund via Datatracker wrote:
> 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
> [e-mail] 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.

I think we have a fix for this:

https://github.com/yaronf/I-D/pull/447

> 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. 

 From a security perspective, TLS 1.3 is preferable of course. The 
authors and UTA WG are not ready to deprecate TLS 1.2 yet (IMHO that 
should be done in an RFC along the lines of RFC 8996) and we believe 
that the best *current* practice at this time is to continue supporting 
TLS 1.2. That will likely change in 7525ter whenever it is published.

> 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.

We do say:

    *  Implementations SHOULD support TLS 1.3 [RFC8446] and, if
       implemented, MUST prefer to negotiate TLS 1.3 over earlier
       versions of TLS.

(There is also discussion <https://github.com/yaronf/I-D/issues/446> 
about changing that SHOULD to MUST.)

> 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.

This is interesting and helpful. Can you suggest any text for rfc7525bis 
along these lines? Or should we simply point to 
draft-ietf-tsvwg-dtls-over-sctp-bis for the relevant considerations?

> 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. 

Good point.

> 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.

Indeed. We (the authors) will discuss potential text and reply again in 
this thread when we have a proposal.

Peter