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
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.
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
