>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
