Re: [TLS] IANA Recommendations for Obsolete Key Exchange

[Martin Thomson <[e-mail]>]

With David's clarifications, this is good.

On Tue, Apr 16, 2024, at 04:46, David Benjamin wrote:
> From the meeting, I remember there being some confusion around a table 
> that split things up between TLS 1.2 and TLS 1.3, and differences in 
> how they negotiate things, which makes this listing a bit ambiguous. In 
> particular, there aren't any *cipher suites* with FFDH or FFDHE in 
> their name in TLS 1.2. Also some of these constructions have analogs in 
> TLS 1.3 and some don't, but none as cipher suites.
>
> Agreed with the proposal, but specifically, this is what I understand 
> the proposal to mean:
>
> TLS 1.2 RSA cipher suites (TLS_RSA_WITH_*) should be marked with a "D"
> -- These lack forward secrecy and use a broken encryption scheme.
> -- There is no analog to RSA key exchange in TLS 1.3, so leave it alone.
>
> TLS 1.2 static DH cipher suites (TLS_DH_*_WITH_*) should be marked with 
> a "D"
> -- These lack forward secrecy and the DH(E) construction in TLS 1.2 is 
> broken. It lacks parameter negotiation, and uses a variable-length 
> secret that is vulnerable to the Raccoon attack, particularly in this 
> context with a static DH key.
> -- There is no analog to static DH in TLS 1.3, so leave it alone.
>
> TLS 1.2 DHE cipher suites (TLS_DHE_*_WITH_*) should be marked with a "D"
> -- While these do provide forward secrecy, the DH(E) construction in 
> TLS 1.2 is broken. It lacks parameter negotiation, and uses a 
> variable-length secret that is vulnerable to the Raccoon attack. In 
> this context, the Racoon attack is less fatal, but it is still a side 
> channel leakage that the protocol should have avoided.
> -- In theory RFC 7919 addressed the lack of parameter negotiation, but 
> by reusing the old construction's cipher suites, it is undeployable. It 
> also does not fix the side channel.
> -- There *is* an analog in TLS 1.3 (the ffdhe* named groups). However, 
> they do not share the TLS 1.2 construction's problems, so we can leave 
> them alone. They're just slow and kinda pointless given ECC exists.
>
> TLS 1.2 static ECDH cipher suites (TLS_ECDH_*_WITH_*) should be marked 
> with a "D"
> -- These lack forward secrecy
> -- There is no analog to static ECDH in TLS 1.3, so leave it alone.
>
>
>
> On Mon, Apr 15, 2024 at 1:30 PM Joseph Salowey <[e-mail]> wrote:
>> At IETF 119 we had discussion on how to mark the ciphersuites deprecated by draft-ietf-tls-deprecate-obsolete-kex in the IANA Registry. At the meeting there was support for ('D' means discouraged):
>> 
>> RSA ciphersuites should be marked with a "D"
>> FFDH ciphersuites should be marked with a "D"
>> FFDHE ciphersuites should be marked with a "D"
>> ECDH ciphersuites should be marked with a "D"
>> 
>> This aligns with the deprecation intent of the draft. The draft states ECDH are a SHOULD NOT instead of a MUST NOT, but the sentiment was they should be generally discouraged.
>> 
>> Please respond with any comments on this proposal by April 30,2024.
>> 
>> Thanks,
>> 
>> Sean, Deirdre and Joe
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls