Skip to main content

Telechat Review of draft-ietf-uta-rfc7525bis-09

Request Review of draft-ietf-uta-rfc7525bis
Requested revision No specific revision (document currently at 11)
Type Telechat Review
Team Transport Area Review Team (tsvart)
Deadline 2022-07-14
Requested 2022-07-13
Requested by Zaheduzzaman Sarker
Authors Yaron Sheffer , Peter Saint-Andre , Thomas Fossati
I-D last updated 2022-07-13
Completed reviews Secdir Last Call review of -07 by Benjamin Kaduk (diff)
Artart Last Call review of -09 by Cullen Fluffy Jennings (diff)
Genart Last Call review of -07 by Tim Evens (diff)
Secdir Telechat review of -09 by Benjamin Kaduk (diff)
Tsvart Telechat review of -09 by Magnus Westerlund (diff)
Assignment Reviewer Magnus Westerlund
State Completed
Request Telechat review on draft-ietf-uta-rfc7525bis by Transport Area Review Team Assigned
Posted at
Reviewed revision 09 (document currently at 11)
Result Ready w/issues
Completed 2022-07-13
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 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

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


Magnus Westerlund