On 7/14/22 3:55 AM, Magnus Westerlund wrote:
Hi,
Solution for 1) looks good.
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.
[MW] Yes I do see the preference for newer versions. My goal was to
point out that in the update of (D)TLS to 1.3 there is no longer feature
parity and that can cause issue for some applications using (D)TLS.
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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-eb83fa0c83a1354e&q=1&e=e369f3c9-8e8b-4673-8fdb-6a4812d69b6e&u=https%3A%2F%2Fgithub.com%2Fyaronf%2FI-D%2Fissues%2F446
<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-eb83fa0c83a1354e&q=1&e=e369f3c9-8e8b-4673-8fdb-6a4812d69b6e&u=https%3A%2F%2Fgithub.com%2Fyaronf%2FI-D%2Fissues%2F446>>
about changing that SHOULD to MUST.)
[MW] And I would think the below feature discrepancy are relevant
reasons why changing this from SHOULD to MUST may be problematic.
However, these applications will have to start thinking about how to
deal with this issue anyway as 1.2 clearly have weakness.
Based on our work on DTLS/SCTP
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/
<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?
[MW] First of all I should have noted that there IPR claimed by Ericsson
on the Parallel DTLS solution https://datatracker.ietf.org/ipr/5218/
<https://datatracker.ietf.org/ipr/5218/> sorry for missing calling that
out originally.
So I could contribute a proposed text for the issues and I would think
that would be the most relevant part anyway to bring up. The solution
space is so dependent on application protocol itself and due to the IPR
I think it would be inappropriate for me to actually suggest text.
Agreed. I will discuss with my co-authors (one of whom is offline this
week) and we'll be back in touch.
Peter
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
