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>
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/ 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/ 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.
Cheers
Magnus
> 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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
