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 <j...@salowey.net> 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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
