Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Carrick Bartle]

Good point, we'll add that to the intro and title.

On Sat, Dec 17, 2022 at 9:03 AM Yaron Sheffer  wrote:

> 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  on behalf of Carrick Bartle <
> cbartle...@gmail.com>
> *Date: *Thursday, 15 December 2022 at 20:15
> *To: *David Benjamin 
> *Cc: *TLS List 
> *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 
> 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  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 

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Carrick Bartle]

> You might need to clarify that TLS 1.1 and earlier are wholly deprecated
though, just to be sure.

We do mention that in the body of the document. Are you suggesting that we
also add that to the abstract and intro?

On Sun, Dec 18, 2022 at 2:55 AM Martin Thomson  wrote:

> On Sun, Dec 18, 2022, at 04:33, Yaron Sheffer wrote:
> > Yes, this is clear to people on this thread. My comment was just about
> > the document, which IMO should define its scope more clearly and early
> > on.
>
> The title and abstract and introduction could say "TLS 1.2" and the
> document would be fine.  You might need to clarify that TLS 1.1 and earlier
> are wholly deprecated though, just to be sure.
>
> ___
> 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

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Martin Thomson]

On Tue, Dec 20, 2022, at 09:34, Carrick Bartle wrote:
>> You might need to clarify that TLS 1.1 and earlier are wholly deprecated 
>> though, just to be sure.
>
> We do mention that in the body of the document. Are you suggesting that 
> we also add that to the abstract and intro?

Oh yeah, three times even.  I was looking for it in the introduction.  Though 
that intro is getting a little lengthy.  I'll leave it to your judgment.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Rob Sayre]

On Mon, Dec 19, 2022 at 2:52 PM Martin Thomson  wrote:

> On Tue, Dec 20, 2022, at 09:34, Carrick Bartle wrote:
> >> You might need to clarify that TLS 1.1 and earlier are wholly
> deprecated though, just to be sure.
> >
> > We do mention that in the body of the document. Are you suggesting that
> > we also add that to the abstract and intro?
>
> Oh yeah, three times even.  I was looking for it in the introduction.
> Though that intro is getting a little lengthy.  I'll leave it to your
> judgment.
>

Yes, I'd say do something excruciatingly clear like that. The people on
this list know what's trying to be communicated, but they don't really need
to read the introduction.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls