Hi Carrick,
While this is clear to the authors, it is not very clear in the document. Even
though the document only applies to TLS 1.2, TLS 1.2 (the version number) is
not mentioned in the doc title, in the abstract or in the introduction.
Thanks,
Yaron
From: TLS <tls-boun...@ietf.org> on behalf of Carrick Bartle
<cbartle...@gmail.com>
Date: Thursday, 15 December 2022 at 20:15
To: David Benjamin <david...@chromium.org>
Cc: TLS List <tls@ietf.org>
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites
Hi David,
My understanding is that we're only discussing deprecating DHE for 1.2. 1.3 is
out of scope for this document.
Carrick
On Tue, Dec 13, 2022 at 10:06 AM David Benjamin <david...@chromium.org> wrote:
Small clarification question: is this about just FFDHE in TLS 1.2, i.e. the
TLS_DHE_* cipher suites, or also the ffdhe* NamedGroup values as used in TLS
1.3?
I support deprecating the TLS_DHE_* ciphers in TLS 1.2. Indeed, we removed them
from Chrome back in 2016 and from BoringSSL not too long afterwards.
The DHE construction in TLS 1.2 was flawed in failing to negotiate groups. The
Logjam attack should not have mattered and instead was very difficult to
mitigate without just dropping DHE entirely. The lack of negotiation also
exacerbates the DoS risks with DHE in much the same way. It is also why the
client text in the current draft ("The group size is at least 2048 bits"), and
the previous one ("The group is one of the following well-known groups
described in [RFC7919]: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192")
are not easily implementable. By the time we've gotten an unsatisfying group
from the server, it's too late to change parameters. Trying with a new
connection and different parameters is also problematic because of downgrade
attacks. A correct scheme would have been defined to only use NamedGroup
values, and so the server could pick another option if no groups were in common.
RFC 7919 should have fixed this, but it too was flawed: it reused the cipher
suites before, making it impossible to filter out old servers. See these
discussions:
https://mailarchive.ietf.org/arch/msg/tls/I3hATzFWwkc2GZqt3hB8QX4c-CA/
https://mailarchive.ietf.org/arch/msg/tls/DzazUXCUZDUpVgBPVHOwatb65dA/
https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo/
Additionally, the shared secret drops leading zeros, which leaks a timing side
channel as a result. Secrets should be fixed-width. See
https://raccoon-attack.com/ and https://github.com/tlswg/tls13-spec/pull/462
At this point, fixing all this with a protocol change no longer makes sense.
Any change we make now won't affect existing deployments. Any update that picks
up the protocol change may as well pick up TLS 1.3 with the ECDH groups. Thus
the best option is to just deprecate them, so deployments can know this is not
the direction to go.
Of course, some deployments may have different needs. I'm sure there are still
corners of the world that still need to carry SSL 3.0 with RC4 despite RFC 7465
and RFC 7568. For instance, during the meeting, we discussed how opportunistic
encryption needs are sometimes different, which is already generically covered
by RFC 7435 ("OSS protocols may employ more liberal settings than would be best
practice [...]"). All that is fine and does not conflict with deprecating.
These modes do not meet the overall standard expected for TLS modes, so this WG
should communicate that.
I'm somewhere between supportive and ambivalent on the ffdhe* NamedGroup values
in TLS 1.3. We do not expect to ever implement them in BoringSSL, and their
performance would be quite a DoS concern if we ever did. But that construction
is not as deeply flawed as the TLS 1.2 construction.
On Tue, Dec 13, 2022 at 9:46 AM Sean Turner <s...@sn3rd.com> wrote:
During the tls@IETF 115 session topic covering
draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there was
support to deprecate all FFDHE cipher suites including well-known groups. This
message starts the process to judge whether there is consensus to deprecate all
FFDHE cipher suites including those well-known groups. Please indicate whether
you do or do not support deprecation of FFDHE cipher suites by 2359UTC on 6
January 2023. If do not support deprecation, please indicate why.
NOTE: We had an earlier consensus call on this topic when adopting
draft-ietd-tls-deprecate-obsolete-kex, but the results were inconclusive. If
necessary, we will start consensus calls on other issues in separate threads.
Cheers,
Chris, Joe, and Sean
_______________________________________________
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
