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

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

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