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

[Nimrod Aviram]

> Authors, can you please update the document (and fix the clarification
that Ekr recently raised) at your convenience?
Sure, I'll start working on it.

best,
Nimrod


On Fri, 10 Mar 2023 at 03:35, Christopher Wood  wrote:

> First, let us apologize for taking so long to conclude this consensus
> call. We should have closed this much sooner.
>
> After reviewing the responses on the mailing list, and taking into
> consideration discussions that took place during meetings, it is our
> assessment that there is rough consensus to deprecate FFDHE in TLS 1.2,
> i.e., all TLS_DHE_* ciphersuites.
>
> Authors, can you please update the document (and fix the clarification
> that Ekr recently raised) at your convenience?
>
> Best,
> Chris, Joe, Sean
>
> > On 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 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

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

[Christopher Wood]

First, let us apologize for taking so long to conclude this consensus call. We 
should have closed this much sooner.

After reviewing the responses on the mailing list, and taking into 
consideration discussions that took place during meetings, it is our assessment 
that there is rough consensus to deprecate FFDHE in TLS 1.2, i.e., all 
TLS_DHE_* ciphersuites.

Authors, can you please update the document (and fix the clarification that Ekr 
recently raised) at your convenience?

Best,
Chris, Joe, Sean

> On 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 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

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

[Peter Gutmann]

Hubert Kario  writes:

>Because there are software stacks that allow configuration of arbitrary
>parameters for FFDH (see GnuTLS, OpenSSL), and there are software stacks that
>generate one public key share and reuse it for a long time, or allow
>configuration of this kind of behaviour (see old OpenSSL, NSS for ECDHE).

If we had to throw out every security mechanism that it's possible to
configure badly then there wouldn't be any crypto left.  For example every SSH
server in existence can be configured to use username = root, password =
password, but that doesn't mean we need to mandate ZKP authentication as the
only allowed way to log into an SSH server.  It's also quite likely you can
configure a lot of TLS servers to use RC4/40 (at least with OpenSSL-based ones
it's 'enable-weak-ssl-ciphers') but that doesn't mean we need to deprecate all
use of symmetric crypto.  If people want to go out of their way to make their
server insecure then there's not much we can do to stop them.

This is a bit of a philosophical question here, and probably not worth
debating, but is it really necessary to put "Do not hold the wrong end of a
chainsaw" - that's actually used on chainsaws - in a technical RFC?  That's
something for the software vendor to take care of if they're going to allow
settings for users to shoot themselves in the foot.  Even for the proposed BCP
it seems a bit redundant, why single out this particular, probably almost
nonexistent, misconfiguration when there are hundreds or even thousands of
others that are more likely to occur?

Peter.

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

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

[Hubert Kario]

On Tuesday, 3 January 2023 11:33:39 CET, Peter Gutmann wrote:

Hubert Kario  writes:


It's also easy and quick to verify that the server *is* behaving correctly
and thus is not exploitable.


It's also a somewhat silly issue to raise, if we're worried about a server
using deliberately broken FFDHE parameters then why aren't we worried about
the server leaking its private key through the server random, 
or posting it to

Pastebin, or sending a copy of the session plaintext to virusbucket.ru?  If
the server's broken it's broken and there's not much a client 
can do about it.


Because there are software stacks that allow configuration of arbitrary
parameters for FFDH (see GnuTLS, OpenSSL), and there are software stacks 
that

generate one public key share and reuse it for a long time, or allow
configuration of this kind of behaviour (see old OpenSSL, NSS for ECDHE).

So this kind of server behaviour may be a reason of misconfiguration, not
malicious behaviour. Misconfiguration that might have been caused by bad
advice or desire to optimise performance and then just cargo-culted to this
day.

In short: because this kind of behaviour may be a result of an error rather 
than

malice.

So it's worth checking for when auditing server configuration.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

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

[Peter Gutmann]

Hubert Kario  writes:

>It's also easy and quick to verify that the server *is* behaving correctly
>and thus is not exploitable.

It's also a somewhat silly issue to raise, if we're worried about a server
using deliberately broken FFDHE parameters then why aren't we worried about
the server leaking its private key through the server random, or posting it to
Pastebin, or sending a copy of the session plaintext to virusbucket.ru?  If
the server's broken it's broken and there's not much a client can do about it.

(As an aside, -LTS fixes this by requiring FIPS-186-style FFDHE values rather
than PKCS #3-style ones, although a determined server can still bypass even
this level of verification, just as they can spike ECDHE in a dozen ways if
they want).

Peter.

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

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

[tom.ripe]

On 14/12/2022 04:08, Peter Gutmann wrote:

Blumenthal, Uri - 0553 - MITLL  writes:


I do not support deprecation, because there will be deployed devices (IoT,
SCADA) that aren’t upgradable – and the new stuff will have to access them.


It's actually much worse than just SCADA, there are deployments in things like
wholesale banking where the semi-deprecation of DH suites has led to them
falling back to RSA instead.  This pointless removal of FFDHE, while it'll be
written as MUST NOT FFDHE, will actually be MUST RSA in some environments.

In other words not only will it not make things any more secure, it'll make
some things much, much less secure.


Yes.  As a later post suggests, there is no point in also prohibiting, 
or pointing to the prohibition of RSA as well (sensible as that is) 
because it leaves most people, those not involved with large websites, 
with nowhere to go.  A more nuanced approach is required by most of the 
world; this is perfection, this is useless while this has some merit but 
leaves you exposed to  .


With these discussions, I always think of an operational system of which 
I am a registered user for which I was given an eight-character 
password, albeit one that does not appear in any dictionary, and which I 
cannot change; if I want to alter it, then I must e-mail the 
administrator who will e-mail me a new one.  That is the real world 
which discussions like these cannot reach.


Tom Petch



Peter.

___
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

[tom.ripe]

On 02/01/2023 13:55, Hubert Kario wrote:

On Saturday, 24 December 2022 02:10:08 CET, Rob Sayre wrote:

Maybe it would help if the chairs could clarify the difference between
"deprecated" and "prohibited" / "forbidden".

I think these words have straightforward definitions, and I find many
responses to be disrespectful in insisting that "deprecated" means
something it does not. But maybe this is an honest misunderstanding,
and just down to translations and different first languages.


The problem is not the language, but how the word "deprecated" is used
by different regulatory bodies.

We have RFC2119, so I think we should stick to it.


We also have RFC1902 from 1996 which defines 'deprecated', a definition 
which has been carried forward with newer technology, such as RFC6020, 
from 2020, and which is in widespread use in the IETF (although perhaps 
not in the TLS WG).


Tom Petch

___
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, Jan 2, 2023 at 5:55 AM Hubert Kario  wrote:

>
> The problem is not the language, but how the word "deprecated" is used by
> different regulatory bodies.
>

I'm not sure what you're referring to, or why they wouldn't understand
the definition of the word, but maybe a longer explanation would be helpful.


>
> We have RFC2119, so I think we should stick to it.
>

That's actually not what we do. See for example:
RFC 8996: Deprecating TLS 1.0 and TLS 1.1

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

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

[Hubert Kario]

On Monday, 2 January 2023 17:32:26 CET, Nimrod Aviram wrote:
It's also easy and quick to verify that the server *is* 
behaving correctly and thus is not exploitable.

Could you please help me understand how you propose to verify this?
For example, assuming an SMTP server that presents a 
(presumably) custom-generated safe prime.
My understanding is that this would require two primality 
tests, for the modulus p and for (p-1)/2.
Several folks here have argued that these primality tests would 
be prohibitively expensive for TLS clients to perform 
per-handshake (and this is also my general understanding of the 
cost of primality tests).


For every connection? Yes, it would probably be prohibitively expensive.
As part of an audit of networking infrastructure, at the same time as you
test which ciphersuites the server has actually enabled, if the 
certificates

don't expire soon, etc.? No, it would be a simple test and just another
checkbox or two on the report ("uses safe primes",
"doesn't reuse public key shares").

That being said, NIST has required for FIPS mode that only well known 
groups

have to be supported, and the USA didn't stop. So having deployments where
the clients actually do verify that the group used by the server is 
actually

secure aren't just possible, but actual day to day reality.

Could you please elaborate what client behavior you propose, 
and how you envision clients to bear the cost?


(To concede a point in advance: It is obviously possible to 
_assume_ that if the server presents a modulus, then it "must" 
be a safe prime, or it meets some desired security notion that 
the server operator has deemed sufficient for the connection. 
However, experience shows that this is not necessarily the case 
in practice; see e.g. the "Small Subgroups" paper referenced in 
the draft. Since you used the word "verify", I'm assuming that's 
not what you meant?)


At the end of the day the client has to trust the server to some degree.
There's nothing in the protocol that will stop the server from sending
the master secret straight to KGB^W GRU in Moscow. Irrespective of the
TLS version and key exchange parameters used.


On Mon, 2 Jan 2023 at 15:52, Hubert Kario  wrote:
On Thursday, 22 December 2022 23:26:26 CET, Carrick Bartle wrote:
the latter is basically unexploitable with properly behaving 
hosts in TLSv1.2


Well, right, that's the trick. The issue that people have 
pointed out with FFDHE is that it's very easy to have a host 
that is not properly behaving (see RFC 7919, which is referenced 
in our draft).


It's also easy and quick to verify that the server *is* behaving correctly
and thus is not exploitable.


On Wed, Dec 21, 2022 at 5:14 AM Hubert Kario  wrote:
On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote:

On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario  wrote:
Thus the deprecation of it is a matter of taste, not 
cryptographic

necessity.

I'm sorry if I'm being dense here, but isn't all of this a 
SHOULD NOT in RFC 9325?


https://www.rfc-editor.org/rfc/rfc9325.html#name-recommendations-cipher-suit

Maybe I'm misreading that RFC, but given that it's a BCP, it 
seems like deprecation is a natural step that reflects IETF 
consensus.


that RFC marks both TLS_RSA_* and TLS_DHE_* as "SHOULD NOT".
Given that the former is still being exploited close to 25 years after the
Bleichenbacher attack was discovered, while the latter is basically
unexploitable with properly behaving hosts in TLSv1.2, I don't think it's
correct to consider them at the same level.

Yes, if you have ECDHE available, you SHOULD NOT use DHE in 
TLSv1.2. But if
everything you have is either TLS_RSA_* and TLS_DHE_*, then you're far 
better

of with TLS_DHE_*.




--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

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

[Viktor Dukhovni]

On Mon, Jan 02, 2023 at 06:32:26PM +0200, Nimrod Aviram wrote:

> (To concede a point in advance: It is obviously possible to _assume_ that
> if the server presents a modulus, then it "must" be a safe prime, or it
> meets some desired security notion that the server operator has deemed
> sufficient for the connection.

The server's choice of FFDHE groups is signed with the server's private
key (matching the public key in its certificate).  If that server is so
poorly operated as to sign a weak FFDHE group, why would one expect its
ECDHE private key to be strong (https://dilbert.com/strip/2001-10-25)?

What's the actual threat model here?  Sure server operators SHOULD NOT
configure weak FFDHE groups (export-grade, small subgroups, ...), but
if they do (despite all advice to the contrary, and much effort in
various tools and libraries to ensure safe defaults), then that's the
best security you can expect if you want to connect to *that* server.

My take remains that progress would be to make ECDHE MTI for TLS 1.2 (if
not already) and mandatory to choose over FFDHE when supported at both
ends.  This entirely achieves all the benefits of the proposed
deprecation, without causing needless auditor grief for FFDHE-only
deployments, knee-jerk switches to RSA key exchange, ...

It would also be helpful if at least one widely-available browser left
FFDHE support available (if not by default, then with a runtime config
setting) so that legacy servers with perfectly good safe DH parameters
remain reachable.

-- 
Viktor.

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

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

[Nimrod Aviram]

> It's also easy and quick to verify that the server *is* behaving
correctly and thus is not exploitable.
Could you please help me understand how you propose to verify this?
For example, assuming an SMTP server that presents a (presumably)
custom-generated safe prime.
My understanding is that this would require two primality tests, for the
modulus p and for (p-1)/2.
Several folks here have argued that these primality tests would be
prohibitively expensive for TLS clients to perform per-handshake (and this
is also my general understanding of the cost of primality tests).

Could you please elaborate what client behavior you propose, and how you
envision clients to bear the cost?

(To concede a point in advance: It is obviously possible to _assume_ that
if the server presents a modulus, then it "must" be a safe prime, or it
meets some desired security notion that the server operator has deemed
sufficient for the connection. However, experience shows that this is not
necessarily the case in practice; see e.g. the "Small Subgroups" paper
referenced in the draft. Since you used the word "verify", I'm assuming
that's not what you meant?)

best,
Nimrod




On Mon, 2 Jan 2023 at 15:52, Hubert Kario  wrote:

> On Thursday, 22 December 2022 23:26:26 CET, Carrick Bartle wrote:
> >> the latter is basically unexploitable with properly behaving
> >> hosts in TLSv1.2
> >
> > Well, right, that's the trick. The issue that people have
> > pointed out with FFDHE is that it's very easy to have a host
> > that is not properly behaving (see RFC 7919, which is referenced
> > in our draft).
>
> It's also easy and quick to verify that the server *is* behaving correctly
> and thus is not exploitable.
>
> > On Wed, Dec 21, 2022 at 5:14 AM Hubert Kario  wrote:
> > On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote:
> >> On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario  wrote:
> >> Thus the deprecation of it is a matter of taste, not
> >> cryptographic
> >> necessity.
> >>
> >> I'm sorry if I'm being dense here, but isn't all of this a
> >> SHOULD NOT in RFC 9325?
> >>
> >>
> https://www.rfc-editor.org/rfc/rfc9325.html#name-recommendations-cipher-suit
> >>
> >> Maybe I'm misreading that RFC, but given that it's a BCP, it
> >> seems like deprecation is a natural step that reflects IETF
> >> consensus.
> >
> > that RFC marks both TLS_RSA_* and TLS_DHE_* as "SHOULD NOT".
> > Given that the former is still being exploited close to 25 years after
> the
> > Bleichenbacher attack was discovered, while the latter is basically
> > unexploitable with properly behaving hosts in TLSv1.2, I don't think it's
> > correct to consider them at the same level.
> >
> > Yes, if you have ECDHE available, you SHOULD NOT use DHE in TLSv1.2. But
> if
> > everything you have is either TLS_RSA_* and TLS_DHE_*, then you're far
> > better
> > of with TLS_DHE_*.
>
> --
> Regards,
> Hubert Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
> ___
> 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

[Hubert Kario]

On Saturday, 24 December 2022 02:10:08 CET, Rob Sayre wrote:
Maybe it would help if the chairs could clarify the difference 
between "deprecated" and "prohibited" / "forbidden".


I think these words have straightforward definitions, and I 
find many responses to be disrespectful in insisting that 
"deprecated" means something it does not. But maybe this is an 
honest misunderstanding, and just down to translations and 
different first languages.


The problem is not the language, but how the word "deprecated" is used by 
different regulatory bodies.


We have RFC2119, so I think we should stick to it.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

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

[Hubert Kario]

On Thursday, 22 December 2022 23:26:26 CET, Carrick Bartle wrote:
the latter is basically unexploitable with properly behaving 
hosts in TLSv1.2


Well, right, that's the trick. The issue that people have 
pointed out with FFDHE is that it's very easy to have a host 
that is not properly behaving (see RFC 7919, which is referenced 
in our draft).


It's also easy and quick to verify that the server *is* behaving correctly
and thus is not exploitable.


On Wed, Dec 21, 2022 at 5:14 AM Hubert Kario  wrote:
On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote:

On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario  wrote:
Thus the deprecation of it is a matter of taste, not 
cryptographic

necessity.

I'm sorry if I'm being dense here, but isn't all of this a 
SHOULD NOT in RFC 9325?


https://www.rfc-editor.org/rfc/rfc9325.html#name-recommendations-cipher-suit

Maybe I'm misreading that RFC, but given that it's a BCP, it 
seems like deprecation is a natural step that reflects IETF 
consensus.


that RFC marks both TLS_RSA_* and TLS_DHE_* as "SHOULD NOT".
Given that the former is still being exploited close to 25 years after the
Bleichenbacher attack was discovered, while the latter is basically
unexploitable with properly behaving hosts in TLSv1.2, I don't think it's
correct to consider them at the same level.

Yes, if you have ECDHE available, you SHOULD NOT use DHE in TLSv1.2. But if
everything you have is either TLS_RSA_* and TLS_DHE_*, then you're far 
better

of with TLS_DHE_*.


--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

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

[Rob Sayre]

Maybe it would help if the chairs could clarify the difference between
"deprecated" and "prohibited" / "forbidden".

I think these words have straightforward definitions, and I find many
responses to be disrespectful in insisting that "deprecated" means
something it does not. But maybe this is an honest misunderstanding, and
just down to translations and different first languages.

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

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

[Carrick Bartle]

> Telling people that they shouldn't use the only things they can use means
that the advice is unactionable, thus will be ignored.

Yep, that's precisely what people are suggesting. If someone has a legacy
system that cannot be upgraded, or they need to interface with such
systems, they can ignore the deprecation and continue to use FFDHE.


On Wed, Dec 21, 2022 at 5:59 AM Hubert Kario  wrote:

> On Tuesday, 20 December 2022 23:56:22 CET, Martin Thomson wrote:
> > On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:
> >> use of FFDHE with large key sizes is the best protection against
> >> store-and-decrypt-later attacks
> >
> > This doesn't deprecate use of FFDHE in TLS 1.3, for which we
> > have some ludicrously large named groups.  Is that not enough?
>
> Not everybody has migrated to TLS 1.3 yet. Not everybody has migrated to
> ECC.
>
> For the people that still have the only options of RSA key exchange or
> FFDHE
> key exchange, both in TLS 1.2, we need to be crystal clear that they
> should
> pick
> FFDHE.
>
> Telling people that they shouldn't use the only things they can use means
> that
> the advice is unactionable, thus will be ignored.
>
> >> If anything, RSA key exchange should be deprecated first.
> >> RFC 8446 deprecated only the DSA ciphersuites, not RSA.
> >
> > This is an odd statement.  TLS 1.3 ciphersuites no longer
> > include the concept of key exchange or signing.
>
> Ciphersuites, yes. Protocol itself, no. It still performs a key exchange.
> And TLS 1.3 explicitly deprecates DSA, see below.
>
> > If you are talking about the signing part, both were sort of
> > deprecated.  RSASSA-PKCS1_v1.5 (ugh, I hate typing that) is only
> > usable within the certificate chain, not in the protocol.  PSS
> > was added back.
>
> There's a difference between saying that a TLS 1.3 client MUST NOT
> advertise
> client hello with TLS_RSA_* ciphersuites listed, and just having TLS 1.3
> not supporting RSA key exchange.
>
> Both of them can be called "deprecated", but one is a clearer and stronger
> condemnation than the other.
>
> DSA is effectively treated with the former "deprecation":
> RFC8446 Section 4.2.3:
>
> >  They MUST NOT be offered or negotiated by any
> >  implementation.  In particular, MD5 [SLOTH], SHA-224, and DSA
> >  MUST NOT be used.
>
> RSA key exchange has nothing like it.
>
> For me "deprecated" means "You really shouldn't use it", not "You should
> stop
> using it at the earliest convenience". I.e. MUST NOT vs SHOULD NOT.
>
> > However, for key exchange, which is more relevant to this
> > conversation, RSA was indeed removed.  And the draft we're
> > discussing does indeed say that RSA key exchange in TLS 1.2 is
> > deprecated.
> >
> > Can you help me better understand the scope of your objection?
>
> I guess my primary objection is with the subject of this thread:
> "deprecate all FFDHE cipher suites". That I don't agree with.
>
> As far as the "draft-ietf-tls-deprecate-obsolete-kex-01" text goes, I would
> tweak some things, but the general description of FFDHE state I do agree
> with:
> "that you shouldn't use it in TLSv1.2, but if you have to, there are simple
> things to do to make sure you're relatively secure".
> --
> Regards,
> Hubert Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
> ___
> 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

[Carrick Bartle]

> the latter is basically unexploitable with properly behaving hosts in
TLSv1.2

Well, right, that's the trick. The issue that people have pointed out with
FFDHE is that it's very easy to have a host that is not properly behaving
(see RFC 7919, which is referenced in our draft).




On Wed, Dec 21, 2022 at 5:14 AM Hubert Kario  wrote:

> On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote:
> > On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario  wrote:
> > Thus the deprecation of it is a matter of taste, not
> > cryptographic
> > necessity.
> >
> > I'm sorry if I'm being dense here, but isn't all of this a
> > SHOULD NOT in RFC 9325?
> >
> >
> https://www.rfc-editor.org/rfc/rfc9325.html#name-recommendations-cipher-suit
> >
> > Maybe I'm misreading that RFC, but given that it's a BCP, it
> > seems like deprecation is a natural step that reflects IETF
> > consensus.
>
> that RFC marks both TLS_RSA_* and TLS_DHE_* as "SHOULD NOT".
> Given that the former is still being exploited close to 25 years after the
> Bleichenbacher attack was discovered, while the latter is basically
> unexploitable with properly behaving hosts in TLSv1.2, I don't think it's
> correct to consider them at the same level.
>
> Yes, if you have ECDHE available, you SHOULD NOT use DHE in TLSv1.2. But if
> everything you have is either TLS_RSA_* and TLS_DHE_*, then you're far
> better
> of with TLS_DHE_*.
> --
> Regards,
> Hubert Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
> ___
> 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

[Rob Sayre]

On Thu, Dec 22, 2022 at 6:10 AM Hubert Kario  wrote:

> On Wednesday, 21 December 2022 19:13:36 CET, Rob Sayre wrote:
> > On Wed, Dec 21, 2022 at 5:59 AM Hubert Kario  wrote:
> >
> > Telling people that they shouldn't use the only things they can use
> means...
> >
> > Well, I'd be curious to know what the use cases are.
>
> The stuff Uri Blumenthal already mentioned: software and hardware that has
> lifetimes measured in decades.


Sorry to be a pain, but like what? Everything older than 2008 is
deprecated. That's 14 years, and the TLS 1.2 RFC has been updated by
several RFCs in the meantime.

https://datatracker.ietf.org/doc/html/rfc5246


> What I'm against is blanket forbidding of FFDHE in TLSv1.2.
>

That's not what deprecation means—the choice of words matters in this case.
Here is a definition:

https://en.wikipedia.org/wiki/Deprecation

"In several fields, especially computing, deprecation is the discouragement
of use of some terminology, feature, design, or practice, typically because
it has been superseded or is no longer considered efficient or safe,
without completely removing it or prohibiting its use."

One might quibble about whether all parts of this definition apply here,
but "discouragement" (RFC 9325) and "superseded" (TLS 1.3) definitely do.

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

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

[Blumenthal, Uri - 0553 - MITLL]

100% support the BCP route.

-- 
V/R,
Uri
 

On 12/22/22, 10:16, "TLS on behalf of Peter Gutmann"  wrote:

Hal Murray  writes:

>Would a BCP be a better approach?  That might provide a good setting to
>discuss the issues.  There is no reason to limit a BCP to TLSv1.2 or FFDHE.

That seems like a much better idea.  A deprecate RFC can only say "no" 
while a
BCP can cover alternatives, in this situation do this, in that situation do
that.

Peter.

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


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

Hal Murray  writes:

>Would a BCP be a better approach?  That might provide a good setting to
>discuss the issues.  There is no reason to limit a BCP to TLSv1.2 or FFDHE.

That seems like a much better idea.  A deprecate RFC can only say "no" while a
BCP can cover alternatives, in this situation do this, in that situation do
that.

Peter.

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

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

[Hal Murray]

> What I'm against is blanket forbidding of FFDHE in TLSv1.2.

The subject says "deprecate".  That seems to have caused much of the 
discussion.

Would a BCP be a better approach?  That might provide a good setting to 
discuss the issues.  There is no reason to limit a BCP to TLSv1.2 or FFDHE.

Is there a Moore's Law of crypto?  What's the time scale?  How often should a 
BCP be updated?



-- 
These are my opinions.  I hate spam.



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

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

[Hubert Kario]

On Wednesday, 21 December 2022 19:13:36 CET, Rob Sayre wrote:

On Wed, Dec 21, 2022 at 5:59 AM Hubert Kario  wrote:

Telling people that they shouldn't use the only things they can use means...

Well, I'd be curious to know what the use cases are.


The stuff Uri Blumenthal already mentioned: software and hardware that has
lifetimes measured in decades.

But I 
would also say this might be enough:


https://www.rfc-editor.org/rfc/rfc9325#name-cipher-suites-for-tls-12

The IETF already says using this is not best current practice, 
so that's enough for me. A deprecation draft (which I do favor) 
would just be another document that makes the point. Rough 
consensus, as they say.


I'm fine with "SHOULD NOT", I'm opposed to "MUST NOT".
I also have no problems with saying that "servers MUST NOT reuse key 
shares"

and with "servers MUST NOT use parameters smaller than 2048 bit".
I even don't have a problem with "servers SHOULD use well known parameters 
or

safe primes as FFDHE parameters".

What I'm against is blanket forbidding of FFDHE in TLSv1.2.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

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

[Viktor Dukhovni]

On Thu, Dec 22, 2022 at 05:56:50AM +, Peter Gutmann wrote:

> John Mattsson  writes:
> 
> >A more reasonable approach would be to deprecate all cipher suites without
> >_ECDHE_.
> >
> >While the WG is in deprecation mode, please deprecate all non-AEAD cipher
> >suites as well. RFC 7540 did this 7.5 years ago...
> 
> An even more reasonable approach would be to mandate EMS, EtM, and (and I
> realise I'm biased here) LTS, which solve all of the above problems without
> having to throw away a bunch of long-standing cipher suites with massive
> existing deployed base.  That's a simple, backwards-compatible tweak to the
> deployed base to fix existing problems rather than scrap-it-and-order-a-new-
> one to replace existing problems with a new set.

Indeed, and, more generally we get much better security outcomes by
making it clear whith new things are MTI and must be preferred by
updated implementations so that they're negotiated whenever supported by
both ends.

The products that already don't want to use the old ciphers don't need
deprecations to convince them to drop support for FFDHE.  Products that
need to remain long-term interoperable, can still continue to offer
FFDHE when the peer does not support ECDHE.

Is there a compelling reason to intervene?

-- 
Viktor.

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

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

[Peter Gutmann]

John Mattsson  writes:

>A more reasonable approach would be to deprecate all cipher suites without
>_ECDHE_.
>
>While the WG is in deprecation mode, please deprecate all non-AEAD cipher
>suites as well. RFC 7540 did this 7.5 years ago...

An even more reasonable approach would be to mandate EMS, EtM, and (and I
realise I'm biased here) LTS, which solve all of the above problems without
having to throw away a bunch of long-standing cipher suites with massive
existing deployed base.  That's a simple, backwards-compatible tweak to the
deployed base to fix existing problems rather than scrap-it-and-order-a-new-
one to replace existing problems with a new set.

Peter.

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

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

[Carrick Bartle]

Sounds good, thanks!

On Mon, Dec 19, 2022 at 3:46 PM Rob Sayre  wrote:

> 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

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

[Rob Sayre]

On Wed, Dec 21, 2022 at 5:59 AM Hubert Kario  wrote:

>
> Telling people that they shouldn't use the only things they can use
> means...
>

Well, I'd be curious to know what the use cases are. But I would also say
this might be enough:

https://www.rfc-editor.org/rfc/rfc9325#name-cipher-suites-for-tls-12

The IETF already says using this is not best current practice, so that's
enough for me. A deprecation draft (which I do favor) would just be another
document that makes the point. Rough consensus, as they say.

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

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

[John Mattsson]

Decrecating _DHE_ cipher suites seems ok but sends a weird message. A more 
reasonable approach would be to deprecate all cipher suites without _ECDHE_. An 
essential zero trust principle is to minimize the impact of breach such as key 
compromize. Key exchange without forward secrecy should only be allowed in 
resumption.

While the WG is in deprecation mode, please deprecate all non-AEAD cipher 
suites as well. RFC 7540 did this 7.5 years ago...

It is a much bigger problem that IETF is legitimizing bad crypto and bad 
security practice than that TLS used in some small amount of deployed devices 
are labeled depracated.

Cheers,
John

From: TLS  on behalf of Hubert Kario 
Date: Wednesday, 21 December 2022 at 14:59
To: Martin Thomson 
Cc: tls@ietf.org 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites
On Tuesday, 20 December 2022 23:56:22 CET, Martin Thomson wrote:
> On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:
>> use of FFDHE with large key sizes is the best protection against
>> store-and-decrypt-later attacks
>
> This doesn't deprecate use of FFDHE in TLS 1.3, for which we
> have some ludicrously large named groups.  Is that not enough?

Not everybody has migrated to TLS 1.3 yet. Not everybody has migrated to
ECC.

For the people that still have the only options of RSA key exchange or
FFDHE
key exchange, both in TLS 1.2, we need to be crystal clear that they should
pick
FFDHE.

Telling people that they shouldn't use the only things they can use means
that
the advice is unactionable, thus will be ignored.

>> If anything, RSA key exchange should be deprecated first.
>> RFC 8446 deprecated only the DSA ciphersuites, not RSA.
>
> This is an odd statement.  TLS 1.3 ciphersuites no longer
> include the concept of key exchange or signing.

Ciphersuites, yes. Protocol itself, no. It still performs a key exchange.
And TLS 1.3 explicitly deprecates DSA, see below.

> If you are talking about the signing part, both were sort of
> deprecated.  RSASSA-PKCS1_v1.5 (ugh, I hate typing that) is only
> usable within the certificate chain, not in the protocol.  PSS
> was added back.

There's a difference between saying that a TLS 1.3 client MUST NOT
advertise
client hello with TLS_RSA_* ciphersuites listed, and just having TLS 1.3
not supporting RSA key exchange.

Both of them can be called "deprecated", but one is a clearer and stronger
condemnation than the other.

DSA is effectively treated with the former "deprecation":
RFC8446 Section 4.2.3:

>  They MUST NOT be offered or negotiated by any
>  implementation.  In particular, MD5 [SLOTH], SHA-224, and DSA
>  MUST NOT be used.

RSA key exchange has nothing like it.

For me "deprecated" means "You really shouldn't use it", not "You should
stop
using it at the earliest convenience". I.e. MUST NOT vs SHOULD NOT.

> However, for key exchange, which is more relevant to this
> conversation, RSA was indeed removed.  And the draft we're
> discussing does indeed say that RSA key exchange in TLS 1.2 is
> deprecated.
>
> Can you help me better understand the scope of your objection?

I guess my primary objection is with the subject of this thread:
"deprecate all FFDHE cipher suites". That I don't agree with.

As far as the "draft-ietf-tls-deprecate-obsolete-kex-01" text goes, I would
tweak some things, but the general description of FFDHE state I do agree
with:
"that you shouldn't use it in TLSv1.2, but if you have to, there are simple
things to do to make sure you're relatively secure".
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com<http://www.cz.redhat.com>
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

___
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

[Hubert Kario]

On Tuesday, 20 December 2022 23:56:22 CET, Martin Thomson wrote:

On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:

use of FFDHE with large key sizes is the best protection against
store-and-decrypt-later attacks 


This doesn't deprecate use of FFDHE in TLS 1.3, for which we 
have some ludicrously large named groups.  Is that not enough?


Not everybody has migrated to TLS 1.3 yet. Not everybody has migrated to
ECC.

For the people that still have the only options of RSA key exchange or 
FFDHE
key exchange, both in TLS 1.2, we need to be crystal clear that they should 
pick

FFDHE.

Telling people that they shouldn't use the only things they can use means 
that

the advice is unactionable, thus will be ignored.


If anything, RSA key exchange should be deprecated first.
RFC 8446 deprecated only the DSA ciphersuites, not RSA.


This is an odd statement.  TLS 1.3 ciphersuites no longer 
include the concept of key exchange or signing.


Ciphersuites, yes. Protocol itself, no. It still performs a key exchange.
And TLS 1.3 explicitly deprecates DSA, see below.

If you are talking about the signing part, both were sort of 
deprecated.  RSASSA-PKCS1_v1.5 (ugh, I hate typing that) is only 
usable within the certificate chain, not in the protocol.  PSS 
was added back.


There's a difference between saying that a TLS 1.3 client MUST NOT 
advertise

client hello with TLS_RSA_* ciphersuites listed, and just having TLS 1.3
not supporting RSA key exchange.

Both of them can be called "deprecated", but one is a clearer and stronger
condemnation than the other.

DSA is effectively treated with the former "deprecation":
RFC8446 Section 4.2.3:


 They MUST NOT be offered or negotiated by any
 implementation.  In particular, MD5 [SLOTH], SHA-224, and DSA
 MUST NOT be used.


RSA key exchange has nothing like it.

For me "deprecated" means "You really shouldn't use it", not "You should 
stop

using it at the earliest convenience". I.e. MUST NOT vs SHOULD NOT.

However, for key exchange, which is more relevant to this 
conversation, RSA was indeed removed.  And the draft we're 
discussing does indeed say that RSA key exchange in TLS 1.2 is 
deprecated.


Can you help me better understand the scope of your objection?


I guess my primary objection is with the subject of this thread:
"deprecate all FFDHE cipher suites". That I don't agree with.

As far as the "draft-ietf-tls-deprecate-obsolete-kex-01" text goes, I would
tweak some things, but the general description of FFDHE state I do agree 
with:

"that you shouldn't use it in TLSv1.2, but if you have to, there are simple
things to do to make sure you're relatively secure".
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

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

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

[Hubert Kario]

On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote:

On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario  wrote:
Thus the deprecation of it is a matter of taste, not 
cryptographic

necessity.

I'm sorry if I'm being dense here, but isn't all of this a 
SHOULD NOT in RFC 9325?


https://www.rfc-editor.org/rfc/rfc9325.html#name-recommendations-cipher-suit

Maybe I'm misreading that RFC, but given that it's a BCP, it 
seems like deprecation is a natural step that reflects IETF 
consensus.


that RFC marks both TLS_RSA_* and TLS_DHE_* as "SHOULD NOT".
Given that the former is still being exploited close to 25 years after the
Bleichenbacher attack was discovered, while the latter is basically
unexploitable with properly behaving hosts in TLSv1.2, I don't think it's
correct to consider them at the same level.

Yes, if you have ECDHE available, you SHOULD NOT use DHE in TLSv1.2. But if
everything you have is either TLS_RSA_* and TLS_DHE_*, then you're far 
better

of with TLS_DHE_*.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

___
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 Tue, Dec 20, 2022 at 2:56 PM Martin Thomson  wrote:

> On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:
> > use of FFDHE with large key sizes is the best protection against
> > store-and-decrypt-later attacks
>
> This doesn't deprecate use of FFDHE in TLS 1.3, for which we have some
> ludicrously large named groups.  Is that not enough?
>
> > If anything, RSA key exchange should be deprecated first.
> > RFC 8446 deprecated only the DSA ciphersuites, not RSA.
>
> This is an odd statement.  TLS 1.3 ciphersuites no longer include the
> concept of key exchange or signing.
>

Of course?  The first part of this thread says "My understanding is that
we're only discussing deprecating DHE for 1.2. 1.3 is out of scope for this
document."

What's the problem? IETF consensus for TLS 1.2 is recorded in RFC 9325. I
guess one could say the current BCP says "SHOULD NOT", but the TLS WG has
not deprecated these things. I don't know what that means, but it does
sound like an extremely IETF thing to do.

thanks,
Rob
___
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 23:52, Hubert Kario wrote:
> use of FFDHE with large key sizes is the best protection against
> store-and-decrypt-later attacks 

This doesn't deprecate use of FFDHE in TLS 1.3, for which we have some 
ludicrously large named groups.  Is that not enough?

> If anything, RSA key exchange should be deprecated first.
> RFC 8446 deprecated only the DSA ciphersuites, not RSA.

This is an odd statement.  TLS 1.3 ciphersuites no longer include the concept 
of key exchange or signing.

If you are talking about the signing part, both were sort of deprecated.  
RSASSA-PKCS1_v1.5 (ugh, I hate typing that) is only usable within the 
certificate chain, not in the protocol.  PSS was added back.

However, for key exchange, which is more relevant to this conversation, RSA was 
indeed removed.  And the draft we're discussing does indeed say that RSA key 
exchange in TLS 1.2 is deprecated.

Can you help me better understand the scope of your objection?

___
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 Tue, Dec 20, 2022 at 4:53 AM Hubert Kario  wrote:

> Thus the deprecation of it is a matter of taste, not
> cryptographic
> necessity.
>

I'm sorry if I'm being dense here, but isn't all of this a SHOULD NOT in
RFC 9325?

https://www.rfc-editor.org/rfc/rfc9325.html#name-recommendations-cipher-suit

Maybe I'm misreading that RFC, but given that it's a BCP, it seems like
deprecation is a natural step that reflects IETF consensus.

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

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

[Hubert Kario]

I oppose deprecation.

Given that we're still a ways off from standardised post-quantum key 
exchanges,

use of FFDHE with large key sizes is the best protection against
store-and-decrypt-later attacks (buying likely years of additional 
protection)

I think the deprecation is premature.

While FFDHE is far from perfect, in practical deployments none of the 
proposed
attacks against it are practical (yes, static FFDH is vulnerable in TLSv1.2 
but

it's still a harder attack than against static RSA with Bleichenbacher-like
attacks). Thus the deprecation of it is a matter of taste, not 
cryptographic

necessity.

If anything, RSA key exchange should be deprecated first.
RFC 8446 deprecated only the DSA ciphersuites, not RSA.

On Tuesday, 13 December 2022 15:46:29 CET, 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 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.


--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

___
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

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

[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

[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
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/ShRaCsYx4lk/m/46rD81AsBwAJ>
>  and
> from BoringSSL not too long afterwards.
>
>
>
> The DHE construction in TLS 1.2 was flawed in failing to negotiate groups.
> The Logjam <https://weakdh.org/> 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
> <https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-01.html#section-3-2.2>
> ("The group size is at least 2048 bits"), and the previous one
> <https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-00.html#section-3-2.2>
> ("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
> <https://www.rfc-editor.org/rfc/rfc7435#section-3> ("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 the

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

[Martin Thomson]

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

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

[Yaron Sheffer]

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. 

 

Thanks,

    Yaron 

 

From: David Benjamin 
Date: Saturday, 17 December 2022 at 19:25
To: Yaron Sheffer 
Cc: Carrick Bartle , TLS List 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites

 

It is, however, mentioned throughout the actual text of the document, assuming 
we're both looking at draft-ietf-tls-deprecate-obsolete-kex-01. I think the 
document describes its current change just fine. I asked only because I wasn't 
sure which the consensus call was about, since that isn't yet reflected in the 
document. (The document just says the group size must be at least 2048 bits in 
TLS 1.2, and then notes that TLS 1.3 satisfies that already. We're now talking 
here about deprecating the DHE ciphers altogether because, without negotiation, 
constraining group size isn't actually viable.)

 

It sounds like this consensus call was indeed just about TLS 1.2, the more 
narrowly-scoped option, so I consider my question satisfied. :-)

 

On Sat, Dec 17, 2022 at 12:03 PM 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 

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 

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

[David Benjamin]

It is, however, mentioned throughout the actual text of the document,
assuming we're both looking at draft-ietf-tls-deprecate-obsolete-kex-01. I
think the document describes its current change just fine. I asked only
because I wasn't sure which the consensus call was about, since that isn't
yet reflected in the document. (The document just says the group size must
be at least 2048 bits in TLS 1.2, and then notes that TLS 1.3 satisfies
that already. We're now talking here about deprecating the DHE ciphers
altogether because, without negotiation, constraining group size isn't
actually viable.)

It sounds like this consensus call was indeed just about TLS 1.2,
the more narrowly-scoped option, so I consider my question satisfied. :-)

On Sat, Dec 17, 2022 at 12:03 PM 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
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/ShRaCsYx4lk/m/46rD81AsBwAJ>
>  and
> from BoringSSL not too long afterwards.
>
>
>
> The DHE construction in TLS 1.2 was flawed in failing to negotiate groups.
> The Logjam <https://weakdh.org/> 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
> <https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-01.html#section-3-2.2>
> ("The group size is at least 2048 bits"), and the previous one
> <https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-00.html#section-3-2.2>
> ("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
> <https://www.rfc-editor.org/rfc/rfc7435#section-3> ("OSS protocols may
> employ more liberal settings than would be best practice [...]"

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

[Yaron Sheffer]

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 

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 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 

__

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

[Nimrod Aviram]

I'm not sure such an implicit approach best serves everyone's interests...
Vendors would be better served if we explicit communicate expected
timelines for deprecation, and expected timelines where maintaining support
is a "must"/MUST/SHOULD.
And this WG would be better served if we have explicitly communicated such
timelines, since then deprecation is straightforward, instead of the
current situation where we need to have discussions such as the current one.

But I think having this discussion in this thread makes it hard to have the
discussion around FFDHE. Let me bring up this point in a separate thread
later, after the dust around FFDHE has settled :-)

best,
Nimrod


On Fri, 16 Dec 2022 at 18:49, Russ Housley  wrote:

> There have been attempts in the past to signal this to product planners:
>
>SHOULD+This term means the same as SHOULD.  However, it is likely
>   that an algorithm marked as SHOULD+ will be promoted at
>   some future time to be a MUST.
>
>SHOULD-This term means the same as SHOULD.  However, an algorithm
>   marked as SHOULD- may be deprecated to a MAY in a future
>   version of this document.
>
>MUST-  This term means the same as MUST.  However, we expect at
>   some point that this algorithm will no longer be a MUST in
>   a future document.  Although its status will be determined
>   at a later time, it is reasonable to expect that if a
>   future revision of a document alters the status of a MUST-
>   algorithm, it will remain at least a SHOULD or a SHOULD-.
>
> Russ
>
> On Dec 16, 2022, at 11:27 AM, Nimrod Aviram 
> wrote:
>
> > There needs to be some plan with a schedule that gives downstream users
> time to get their act in gear.
> I agree. And the schedule should also allow for deprecation in a
> reasonable timeline.
>
> > Should there be an IETF group to help coordinate things like this?
> I think it'd be better if each group coordinates this for itself.
> We should do this, if we can. I would suggest "Intent to Deprecate"
> documents that e.g. make it clear that you cannot count on TLS 1.2 only in,
> say, 2030. Otherwise we'll have the same conversation around that
> deprecation then.
>
> Is there interest in this?
>
>
>
> On Fri, 16 Dec 2022 at 09:41, Hal Murray  wrote:
>
>>
>> say...@gmail.com said:
>> > For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
>> > endlessly keeping old cipher suites alive. The unwise cost-cutting in
>> those
>> > areas does not constrain the rest of the internet.
>>
>> Agreeded, but the software maintainers can't just drop support for X
>> because
>> it has been deprecated.  There needs to be some plan with a schedule that
>> gives downstream users time to get their act in gear.
>>
>> Should there be an IETF group to help coordinate things like this?  If
>> nothing
>> else, there should be a RFC explaining the problem to vendors planning to
>> ship
>> software that can't be updated -- and showing their potential customers
>> what
>> to consider.
>>   Maybe data sheets should list the RFCs they depend upon -- with a big
>> red
>> arrow nwxt to the ones that have been obsoleted or deprecated.
>>
>> IoT and embedded are not the only problems.  There are many companies
>> that run
>> old stable software.  Ubuntu supports LTS releases for 5 years with 5
>> more
>> available for a fee.
>>   https://ubuntu.com/about/release-cycle
>> Do we have to worry about this area?  Or will the companies like Ubuntu
>> take
>> care of their customers?
>>
>>
>>
>>
>> --
>> These are my opinions.  I hate spam.
>>
>>
>>
>> ___
>> 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

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

[Viktor Dukhovni]

On Tue, Dec 13, 2022 at 09:46:29AM -0500, Sean Turner wrote:

> 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.

My take is that an RFC deprecating TLS 1.2 FFDHE ciphersuites will not
have a positive impact on the ecosystem.  Most security improvements
result from raising the ceiling, not the floor, implementing the
preferred algorithms, and making sure that algorithm negotiation resists
downgrades.

If the protocol's algorithm negotiation fails to protect against
downgrade attacks, then either the protocol needs to be replaced, or
else indeed parameters that make downgrade attacks possible need to be
deprecated.

Otherwise, less-preferred, but widely used (at least in some industry
sectors) parameter choices should be marked as less preferred than
other parameter choices (i.e., in this case, implementations SHOULD
support ECDHE, SHOULD use ECDHE whenever mutually supported), but
should not be "deprecated" (as in marked "DO NOT USE").

If I've not paid enough attention, and missed an important reason
why leaving FFDHE available, while preferring ECDHE opens the door
to downgrade attacks or other critical problems, then of course
deprecation would be appropriate.

Otherwise, as a data point, looking at SMTP IP endpoints that support
DANE (presumably bleeding-edge enough to take non-default security
measures), I see:

TLS 1.3:
 20187 AES256GCM
  7115 CHACHA20POLY1305
12 AES128GCM

TLS 1.2:
  3283 ECDHE
   103 DHE
 3 RSA

TLS 1.0:
 5 DHE
 1 RSA

This supports the idea that raising the ceiling is in fact sufficiently
effective:

* The majorify of servers support and use TLS 1.3.
* The majority of TLS 1.2 servers negotiate ECDHE

In this population of servers I see 108 DHE-preferring/only endpoints
out of ~30k (and 4 RSA endpoints).

The numbers will continue to improve organically, but laggards could
be encouraged by publishing a document that strongly recommends use
of ECDHE (or X25519/X448) whenever possible, rather than DHE.

The scope of any proposed "deprecation" should also be clarified, in
response to David Benjamin's question, as to whether this is just TLS
1.2, or also TLS 1.3.

-- 
Viktor.

___
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 Fri, Dec 16, 2022 at 3:22 AM Peter Gutmann 
wrote:

>  Saying
> "lalalalala I'm not listening, I'm not listening" won't deal with the fact
> that there's a staggering amount of gear out there with product lifecycles
> sometimes measured in decades that needs a sound basis for making decisions
> about what to deploy, which this deprecation isn't providing.
>
> Maybe that's the way to resolve this, make it explicit that the deprecation
> applies for web use and not for other uses like SCADA, embedded, or
> anything
> else that needs to take long-term usage into account.
>

I think describing the situation at the time-of-writing would be fine, but
FFDHE should still be deprecated. At some point, one has to consult
decades-old RFCs to interoperate with decades-old implementations. That's
one of the reasons the IETF keeps the documents around.

I'm a bit skeptical of the timelines you're aiming for, though. TLS 1.2 is
from 2008, so anything older than that is deprecated by RFC 8996.
Additionally, I think RFC 9325 covers this issue, and also gives some
guidelines moving forward: "the overall approach is to encourage systems to
move to TLS 1.3."

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

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

[Carrick Bartle]

The fact that there are long product lifecycles makes the case for
deprecation rather than against it. Imagine that we do not deprecate DHE.
That means that next year, someone will be fully within the standard to
create a long-lived product that uses DHE with TLS 1.2 and nothing more
secure than that. That means that we can't deprecate DHE next year either
for the same reason we can't deprecate it now, and so on, forever. Is that
really the circumstance we want to find ourselves in? To never deprecate
insecure algorithms? That seems overly reckless to me and may leave new
systems vulnerable to known security issues for a long time.

Carrick






On Fri, Dec 16, 2022 at 3:22 AM Peter Gutmann 
wrote:

> Rob Sayre  writes:
>
> >For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> >endlessly keeping old cipher suites alive. The unwise cost-cutting in
> those
> >areas does not constrain the rest of the internet.
>
> And for my part I'm... well not really sick of but resigned to accepting
> the
> fact that as far as the WG seems to be concerned, nothing exists outside of
> the web [*] and there's no need to accommodate anything but that.  Saying
> "lalalalala I'm not listening, I'm not listening" won't deal with the fact
> that there's a staggering amount of gear out there with product lifecycles
> sometimes measured in decades that needs a sound basis for making decisions
> about what to deploy, which this deprecation isn't providing.
>
> Maybe that's the way to resolve this, make it explicit that the deprecation
> applies for web use and not for other uses like SCADA, embedded, or
> anything
> else that needs to take long-term usage into account.
>
> Peter.
>
> [*] Once you exclude your list of IoT, SCADA, embedded, and the case I
> mentioned, transaction processing, you've pretty much ruled out
> everything but web use... well OK, admittedly there's still email (so
> opportunistic encryption) and a bunch of barely-visible stuff like any
> tunnels that for some reason don't already use IPsec/OpenVPN/WireGuard.
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

There have been attempts in the past to signal this to product planners:

   SHOULD+This term means the same as SHOULD.  However, it is likely
  that an algorithm marked as SHOULD+ will be promoted at
  some future time to be a MUST.

   SHOULD-This term means the same as SHOULD.  However, an algorithm
  marked as SHOULD- may be deprecated to a MAY in a future
  version of this document.

   MUST-  This term means the same as MUST.  However, we expect at
  some point that this algorithm will no longer be a MUST in
  a future document.  Although its status will be determined
  at a later time, it is reasonable to expect that if a
  future revision of a document alters the status of a MUST-
  algorithm, it will remain at least a SHOULD or a SHOULD-.

Russ

> On Dec 16, 2022, at 11:27 AM, Nimrod Aviram  wrote:
> 
> > There needs to be some plan with a schedule that gives downstream users 
> > time to get their act in gear.
> I agree. And the schedule should also allow for deprecation in a reasonable 
> timeline.
> 
> > Should there be an IETF group to help coordinate things like this?
> I think it'd be better if each group coordinates this for itself.
> We should do this, if we can. I would suggest "Intent to Deprecate" documents 
> that e.g. make it clear that you cannot count on TLS 1.2 only in, say, 2030. 
> Otherwise we'll have the same conversation around that deprecation then.
> 
> Is there interest in this?
> 
> 
> 
> On Fri, 16 Dec 2022 at 09:41, Hal Murray  > wrote:
> 
> say...@gmail.com  said:
> > For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> > endlessly keeping old cipher suites alive. The unwise cost-cutting in those
> > areas does not constrain the rest of the internet. 
> 
> Agreeded, but the software maintainers can't just drop support for X because 
> it has been deprecated.  There needs to be some plan with a schedule that 
> gives downstream users time to get their act in gear.
> 
> Should there be an IETF group to help coordinate things like this?  If 
> nothing 
> else, there should be a RFC explaining the problem to vendors planning to 
> ship 
> software that can't be updated -- and showing their potential customers what 
> to consider.
>   Maybe data sheets should list the RFCs they depend upon -- with a big red 
> arrow nwxt to the ones that have been obsoleted or deprecated.
> 
> IoT and embedded are not the only problems.  There are many companies that 
> run 
> old stable software.  Ubuntu supports LTS releases for 5 years with 5 more 
> available for a fee.
>   https://ubuntu.com/about/release-cycle 
> 
> Do we have to worry about this area?  Or will the companies like Ubuntu take 
> care of their customers?
> 
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> 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

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

[Nimrod Aviram]

> There needs to be some plan with a schedule that gives downstream users
time to get their act in gear.
I agree. And the schedule should also allow for deprecation in a reasonable
timeline.

> Should there be an IETF group to help coordinate things like this?
I think it'd be better if each group coordinates this for itself.
We should do this, if we can. I would suggest "Intent to Deprecate"
documents that e.g. make it clear that you cannot count on TLS 1.2 only in,
say, 2030. Otherwise we'll have the same conversation around that
deprecation then.

Is there interest in this?



On Fri, 16 Dec 2022 at 09:41, Hal Murray  wrote:

>
> say...@gmail.com said:
> > For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> > endlessly keeping old cipher suites alive. The unwise cost-cutting in
> those
> > areas does not constrain the rest of the internet.
>
> Agreeded, but the software maintainers can't just drop support for X
> because
> it has been deprecated.  There needs to be some plan with a schedule that
> gives downstream users time to get their act in gear.
>
> Should there be an IETF group to help coordinate things like this?  If
> nothing
> else, there should be a RFC explaining the problem to vendors planning to
> ship
> software that can't be updated -- and showing their potential customers
> what
> to consider.
>   Maybe data sheets should list the RFCs they depend upon -- with a big
> red
> arrow nwxt to the ones that have been obsoleted or deprecated.
>
> IoT and embedded are not the only problems.  There are many companies that
> run
> old stable software.  Ubuntu supports LTS releases for 5 years with 5 more
> available for a fee.
>   https://ubuntu.com/about/release-cycle
> Do we have to worry about this area?  Or will the companies like Ubuntu
> take
> care of their customers?
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> 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

[Peter Gutmann]

Rob Sayre  writes:

>For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
>endlessly keeping old cipher suites alive. The unwise cost-cutting in those
>areas does not constrain the rest of the internet.

And for my part I'm... well not really sick of but resigned to accepting the
fact that as far as the WG seems to be concerned, nothing exists outside of
the web [*] and there's no need to accommodate anything but that.  Saying
"lalalalala I'm not listening, I'm not listening" won't deal with the fact
that there's a staggering amount of gear out there with product lifecycles
sometimes measured in decades that needs a sound basis for making decisions
about what to deploy, which this deprecation isn't providing.

Maybe that's the way to resolve this, make it explicit that the deprecation
applies for web use and not for other uses like SCADA, embedded, or anything
else that needs to take long-term usage into account.

Peter.

[*] Once you exclude your list of IoT, SCADA, embedded, and the case I
mentioned, transaction processing, you've pretty much ruled out
everything but web use... well OK, admittedly there's still email (so
opportunistic encryption) and a bunch of barely-visible stuff like any
tunnels that for some reason don't already use IPsec/OpenVPN/WireGuard.

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

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

[Loganaden Velvindron]

On Fri, Dec 16, 2022, 11:41 Hal Murray  wrote:

>
> say...@gmail.com said:
> > For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> > endlessly keeping old cipher suites alive. The unwise cost-cutting in
> those
> > areas does not constrain the rest of the internet.
>
> Agreeded, but the software maintainers can't just drop support for X
> because
> it has been deprecated.  There needs to be some plan with a schedule that
> gives downstream users time to get their act in gear.
>
> Should there be an IETF group to help coordinate things like this?  If
> nothing
> else, there should be a RFC explaining the problem to vendors planning to
> ship
> software that can't be updated -- and showing their potential customers
> what
> to consider.
>   Maybe data sheets should list the RFCs they depend upon -- with a big
> red
> arrow nwxt to the ones that have been obsoleted or deprecated.
>
> IoT and embedded are not the only problems.  There are many companies that
> run
> old stable software.  Ubuntu supports LTS releases for 5 years with 5 more
> available for a fee.
>   https://ubuntu.com/about/release-cycle
> Do we have to worry about this area?  Or will the companies like Ubuntu
> take
> care of their customers?
>
Pressure from auditors will force Ubuntu to help their paying customers to
update cryptographic primitives for compliance ?



>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> 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

[Hal Murray]

say...@gmail.com said:
> For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> endlessly keeping old cipher suites alive. The unwise cost-cutting in those
> areas does not constrain the rest of the internet. 

Agreeded, but the software maintainers can't just drop support for X because 
it has been deprecated.  There needs to be some plan with a schedule that 
gives downstream users time to get their act in gear.

Should there be an IETF group to help coordinate things like this?  If nothing 
else, there should be a RFC explaining the problem to vendors planning to ship 
software that can't be updated -- and showing their potential customers what 
to consider.
  Maybe data sheets should list the RFCs they depend upon -- with a big red 
arrow nwxt to the ones that have been obsoleted or deprecated.

IoT and embedded are not the only problems.  There are many companies that run 
old stable software.  Ubuntu supports LTS releases for 5 years with 5 more 
available for a fee.
  https://ubuntu.com/about/release-cycle
Do we have to worry about this area?  Or will the companies like Ubuntu take 
care of their customers?




-- 
These are my opinions.  I hate spam.



___
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 Thu, Dec 15, 2022 at 4:27 PM Peter Gutmann 
wrote:

>
> It seems the only real reason for deprecating DHE is that it's not
> fashionable.


This kind of discourse isn't cool. If there are good ways to show that
FFDHE cipher suites are ok, let's document them.


> And as my earlier message pointed out, this WG fashion statement
> has real consequences in practice.
>

I'm not sure why you would use the term "fashion statement", as if the
concerns were frivolous.

For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
endlessly keeping old cipher suites alive. The unwise cost-cutting in those
areas does not constrain the rest of the internet.

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

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

[Carrick Bartle]

> without further guidance they've chosen to go with literally the worst
possible option instead of the perfectly-OK one.
You are more than welcome to draft a document stating that, given two
deprecated options, which is preferable.

> It seems the only real reason for deprecating DHE is that it's not
fashionable.

No one has made any statements about the fashionability or otherwise of
DHE. As I stated in a different thread, this document leaves the presence
of DHE in TLS 1.3 completely unscathed. As David Ben reiterated, the
reasoning behind deprecation has been almost entirely based on the
inability to negotiate groups.



On Thu, Dec 15, 2022 at 4:26 PM Peter Gutmann 
wrote:

> Carrick Bartle  writes:
>
> >In the situation you've described, they've been told they shouldn't use
> RSA
> >either, so clearly it doesn't matter to them what we've deprecated or
> not.
>
> Yup, because if you give people the choice between not A but not B either
> then
> they have to ignore one of the two, and without further guidance they've
> chosen to go with literally the worst possible option instead of the
> perfectly-OK one.
>
> Piggybacking a reply to your other message, anything that's online is DoS-
> able.  If I want to DoS a web server, or anything at all for that matter,
> I'll
> hit it with a botnet, an attack that's effective on anything no matter what
> algorithm it uses.
>
> It seems the only real reason for deprecating DHE is that it's not
> fashionable. And as my earlier message pointed out, this WG fashion
> statement
> has real consequences in practice.
>
> Peter.
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

Carrick Bartle  writes:

>In the situation you've described, they've been told they shouldn't use RSA
>either, so clearly it doesn't matter to them what we've deprecated or not. 

Yup, because if you give people the choice between not A but not B either then
they have to ignore one of the two, and without further guidance they've
chosen to go with literally the worst possible option instead of the
perfectly-OK one.

Piggybacking a reply to your other message, anything that's online is DoS-
able.  If I want to DoS a web server, or anything at all for that matter, I'll
hit it with a botnet, an attack that's effective on anything no matter what
algorithm it uses.

It seems the only real reason for deprecating DHE is that it's not
fashionable. And as my earlier message pointed out, this WG fashion statement
has real consequences in practice.

Peter.

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

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

[Carrick Bartle]

In the situation you've described, they've been told they shouldn't use RSA
either, so clearly it doesn't matter to them what we've deprecated or not.
We should deprecate insecure algorithms; the fact that there's a spectrum
of insecurity among deprecated algorithms does not detract from the fact
that they are all best avoided.

On Wed, Dec 14, 2022 at 3:07 AM Peter Gutmann 
wrote:

> Nimrod Aviram  writes:
>
> >Let me clarify that the document also has RSA as a MUST NOT.
> >
> >So there will be no reason to read this document and switch from FFDHE to
> >RSA.
>
> If you tell people they can't have A but they can't have B either then
> they're
> going to have to choose one of the two in order to communicate, and in (at
> least some) banking it's RSA, the most insecure option there is, because
> they've been told they shouldn't use DHE.
>
> Peter.
>
> ___
> 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

[Carrick Bartle]

> Wouldn’t be the first case an RFC gets misinterpreted.

I don't think the IETF's decisions should be dictated by the risk that
someone might potentially misread their documents. That's always a risk.
Someone might misread RFC 8446 as saying "use SSL 3.0 only." Does that mean
the IETF shouldn't publish RFC 8446?

> use depreciation as an excuse to remove support of deprecated algorithms
and protocols.

I'm not sure what the issue is here. Deprecation isn't just an excuse to
remove support of deprecated protocols; it's a good reason to do so. If,
however, they need to interface with legacy systems, they can continue to
do so in spite of official deprecation. No one is going to arrest them for
continuing to use FFDHE.

Carrick


On Wed, Dec 14, 2022 at 5:01 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> True - but, unfortunately, quite a few readers misunderstand that and use
> depreciation as an excuse to remove support of deprecated algorithms and
> protocols.
>
> Wouldn’t be the first case an RFC gets misinterpreted.
>
> Regards,
> Uri
>
> On Dec 14, 2022, at 02:30, Rob Sayre  wrote:
>
> 
> On Tue, Dec 13, 2022 at 8:14 PM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:\
>
>>
>>
>> I think I’ve made my point already – there are devices that use FFDHE,
>> which remain secure (so far), and may require access by new .
>> Thus, an RFC that would prohibit it, sounds, as you said yourself,
>> premature.
>>
>
> Deprecated does not mean prohibited.
>
> thanks,
> Rob
>
> ___
> 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

[Carrick Bartle]

> I certainly am, especially given that there are no security reasons
driving it.

Could you describe your reasoning behind this statement? From my read,
supporters of deprecation have made it pretty clear that the motivation
behind deprecating DHE is security considerations: there is no way to
securely negotiate it without introducing potential DoS issues.


On Tue, Dec 13, 2022 at 8:14 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> Maybe you are saying this decision is premature.
>
>
>
> I certainly am, especially given that there are no security reasons
> driving it.
>
>
>
> Surely there is a limit to this reasoning, though.
>
>
>
> Of course.
>
>
>
> There is a MacOS 9 system right next to me, and it doesn't support
> anything beyond SSL3. I would not expect the IETF to accommodate that
> system.
>
>
>
> Correct. And I wouldn’t expect the IETF to accommodate whatever Windows 95
> used to support, if anybody still has it. But, as you said, there’s a limit
> to this reasoning as well.
>
>
>
> So, can you explain your point a bit more?
>
>
>
> I think I’ve made my point already – there are devices that use FFDHE,
> which remain secure (so far), and may require access by new .
> Thus, an RFC that would prohibit it, sounds, as you said yourself,
> premature.
>
>
>
> I think "zero security reasons" sounds like something we should work out,
> but arguments like "who cares for systems like SCADA" are a bit off the
> mark. The IETF can't perpetually support systems that can't be upgraded,
> because attacks always get better.
>
>
>
> I see a great distance between “perpetual” and “premature”. And SCADA is
> just one area, which I brought up because it’s closer to me than, e.g.,
> browsers-and-websites realm.
>
>
>
> And stand by my opinion that deprecating a perfectly functional and secure
> protocol (for reasons I consider frivolous at best) and ignore the likely
> harm such deprecation would cause, is, er, “premature”.
>
>
>
>
>
>
>
> thanks,
>
> Rob
>
>
>
>
>
> On Tue, Dec 13, 2022 at 3:01 PM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
> That sounds like deprecation to me (stop building new things this way...)
>
>
>
> Build new things that stop interoperating with old things? Does not sound
> smart to me.
>
>
>
> Not to mention that there’s zero security reasons for this deprecation.
>
>
>
> I support deprecating all FFDHE cipher suites. The IETF should not
> perpetually support systems that can't be upgraded.
>
>
>
> Yeah, who cares for systems like SCADA. Sure.
>
>
>
>
>
> On Tue, Dec 13, 2022 at 7:51 AM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
> I do not support deprecation, because there will be deployed devices (IoT,
> SCADA) that aren’t upgradable – and the new stuff will have to access them.
>
>
>
> I’ll spare the group my personal opinion about this draft.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> *From: *TLS  on behalf of Ira McDonald <
> blueroofmu...@gmail.com>
> *Date: *Tuesday, December 13, 2022 at 10:47
> *To: *Sean Turner , Ira McDonald 
> *Cc: *TLS List 
> *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites
>
>
>
> Hi,
>
>
>
> Yes - I support deprecating all FFDHE cipher suites including well-known
> groups.
>
>
>
> Cheers,
>
> - Ira
>
>
>
>
>
> 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 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

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

[Carrick Bartle]

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 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

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

[Blumenthal, Uri - 0553 - MITLL]

True - but, unfortunately, quite a few readers misunderstand that and use depreciation as an excuse to remove support of deprecated algorithms and protocols. Wouldn’t be the first case an RFC gets misinterpreted. Regards,UriOn Dec 14, 2022, at 02:30, Rob Sayre  wrote:On Tue, Dec 13, 2022 at 8:14 PM Blumenthal, Uri - 0553 - MITLL  wrote:\ I think I’ve made my point already – there are devices that use FFDHE, which remain secure (so far), and may require access by new . Thus, an RFC that would prohibit it, sounds, as you said yourself, premature.Deprecated does not mean prohibited.thanks,Rob


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Tue, Dec 13, 2022 at 03:51:33PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I do not support deprecation, because there will be deployed devices
> (IoT, SCADA) that aren’t upgradable – and the new stuff will have to
> access them.

Any stuff that needs to access such devices already has to be special.
One more MUST to ignore is not a big deal for such case.



-Ilari

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

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

[Peter Gutmann]

Nimrod Aviram  writes:

>Let me clarify that the document also has RSA as a MUST NOT.
>
>So there will be no reason to read this document and switch from FFDHE to
>RSA.

If you tell people they can't have A but they can't have B either then they're
going to have to choose one of the two in order to communicate, and in (at
least some) banking it's RSA, the most insecure option there is, because
they've been told they shouldn't use DHE.

Peter.

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

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

[Nimrod Aviram]

Let me clarify that the document also has RSA as a MUST NOT.
So there will be no reason to read this document and switch from FFDHE to
RSA.


On Wed, 14 Dec 2022 at 06:09, Peter Gutmann 
wrote:

> Blumenthal, Uri - 0553 - MITLL  writes:
>
> >I do not support deprecation, because there will be deployed devices (IoT,
> >SCADA) that aren’t upgradable – and the new stuff will have to access
> them.
>
> It's actually much worse than just SCADA, there are deployments in things
> like
> wholesale banking where the semi-deprecation of DH suites has led to them
> falling back to RSA instead.  This pointless removal of FFDHE, while it'll
> be
> written as MUST NOT FFDHE, will actually be MUST RSA in some environments.
>
> In other words not only will it not make things any more secure, it'll make
> some things much, much less secure.
>
> Peter.
>
> ___
> 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

[Rob Sayre]

On Tue, Dec 13, 2022 at 8:14 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:\

>
>
> I think I’ve made my point already – there are devices that use FFDHE,
> which remain secure (so far), and may require access by new .
> Thus, an RFC that would prohibit it, sounds, as you said yourself,
> premature.
>

Deprecated does not mean prohibited.

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

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

[Blumenthal, Uri - 0553 - MITLL]

Maybe you are saying this decision is premature. 

 

I certainly am, especially given that there are no security reasons driving it.

 

Surely there is a limit to this reasoning, though. 

 

Of course.

 

There is a MacOS 9 system right next to me, and it doesn't support anything 
beyond SSL3. I would not expect the IETF to accommodate that system.

 

Correct. And I wouldn’t expect the IETF to accommodate whatever Windows 95 used 
to support, if anybody still has it. But, as you said, there’s a limit to this 
reasoning as well. 

 

So, can you explain your point a bit more? 

 

I think I’ve made my point already – there are devices that use FFDHE, which 
remain secure (so far), and may require access by new . Thus, an RFC 
that would prohibit it, sounds, as you said yourself, premature.

 

I think "zero security reasons" sounds like something we should work out, but 
arguments like "who cares for systems like SCADA" are a bit off the mark. The 
IETF can't perpetually support systems that can't be upgraded, because attacks 
always get better.

 

I see a great distance between “perpetual” and “premature”. And SCADA is just 
one area, which I brought up because it’s closer to me than, e.g., 
browsers-and-websites realm.

 

And stand by my opinion that deprecating a perfectly functional and secure 
protocol (for reasons I consider frivolous at best) and ignore the likely harm 
such deprecation would cause, is, er, “premature”.

 

 

 

thanks,

Rob

 

 

On Tue, Dec 13, 2022 at 3:01 PM Blumenthal, Uri - 0553 - MITLL 
 wrote:

That sounds like deprecation to me (stop building new things this way...)

 

Build new things that stop interoperating with old things? Does not sound smart 
to me.

 

Not to mention that there’s zero security reasons for this deprecation.

 

I support deprecating all FFDHE cipher suites. The IETF should not perpetually 
support systems that can't be upgraded.

 

Yeah, who cares for systems like SCADA. Sure.

 

 

On Tue, Dec 13, 2022 at 7:51 AM Blumenthal, Uri - 0553 - MITLL 
 wrote:

I do not support deprecation, because there will be deployed devices (IoT, 
SCADA) that aren’t upgradable – and the new stuff will have to access them.

 

I’ll spare the group my personal opinion about this draft.

-- 

V/R,

Uri

 

 

From: TLS  on behalf of Ira McDonald 

Date: Tuesday, December 13, 2022 at 10:47
To: Sean Turner , Ira McDonald 
Cc: TLS List 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites

 

Hi,

 

Yes - I support deprecating all FFDHE cipher suites including well-known groups.

 

Cheers,

- Ira

 

 

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 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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

Blumenthal, Uri - 0553 - MITLL  writes:

>I do not support deprecation, because there will be deployed devices (IoT,
>SCADA) that aren’t upgradable – and the new stuff will have to access them.

It's actually much worse than just SCADA, there are deployments in things like
wholesale banking where the semi-deprecation of DH suites has led to them
falling back to RSA instead.  This pointless removal of FFDHE, while it'll be
written as MUST NOT FFDHE, will actually be MUST RSA in some environments.

In other words not only will it not make things any more secure, it'll make
some things much, much less secure.

Peter.

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

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

[Rob Sayre]

Hi,

Maybe you are saying this decision is premature. Surely there is a limit to
this reasoning, though. There is a MacOS 9 system right next to me, and it
doesn't support anything beyond SSL3. I would not expect the IETF to
accommodate that system.

So, can you explain your point a bit more? I think "zero security reasons"
sounds like something we should work out, but arguments like "who cares for
systems like SCADA" are a bit off the mark. The IETF can't perpetually
support systems that can't be upgraded, because attacks always get better.

thanks,
Rob


On Tue, Dec 13, 2022 at 3:01 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> That sounds like deprecation to me (stop building new things this way...)
>
>
>
> Build new things that stop interoperating with old things? Does not sound
> smart to me.
>
>
>
> Not to mention that there’s zero security reasons for this deprecation.
>
>
>
> I support deprecating all FFDHE cipher suites. The IETF should not
> perpetually support systems that can't be upgraded.
>
>
>
> Yeah, who cares for systems like SCADA. Sure.
>
>
>
>
>
> On Tue, Dec 13, 2022 at 7:51 AM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
> I do not support deprecation, because there will be deployed devices (IoT,
> SCADA) that aren’t upgradable – and the new stuff will have to access them.
>
>
>
> I’ll spare the group my personal opinion about this draft.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> *From: *TLS  on behalf of Ira McDonald <
> blueroofmu...@gmail.com>
> *Date: *Tuesday, December 13, 2022 at 10:47
> *To: *Sean Turner , Ira McDonald 
> *Cc: *TLS List 
> *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites
>
>
>
> Hi,
>
>
>
> Yes - I support deprecating all FFDHE cipher suites including well-known
> groups.
>
>
>
> Cheers,
>
> - Ira
>
>
>
>
>
> 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 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

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

[Blumenthal, Uri - 0553 - MITLL]

That sounds like deprecation to me (stop building new things this way...)

 

Build new things that stop interoperating with old things? Does not sound smart 
to me.

 

Not to mention that there’s zero security reasons for this deprecation.

 

I support deprecating all FFDHE cipher suites. The IETF should not perpetually 
support systems that can't be upgraded.

 

Yeah, who cares for systems like SCADA. Sure.

 

 

On Tue, Dec 13, 2022 at 7:51 AM Blumenthal, Uri - 0553 - MITLL 
 wrote:

I do not support deprecation, because there will be deployed devices (IoT, 
SCADA) that aren’t upgradable – and the new stuff will have to access them.

 

I’ll spare the group my personal opinion about this draft.

-- 

V/R,

Uri

 

 

From: TLS  on behalf of Ira McDonald 

Date: Tuesday, December 13, 2022 at 10:47
To: Sean Turner , Ira McDonald 
Cc: TLS List 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites

 

Hi,

 

Yes - I support deprecating all FFDHE cipher suites including well-known groups.

 

Cheers,

- Ira

 

 

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 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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Rob Sayre]

That sounds like deprecation to me (stop building new things this way...)

I support deprecating all FFDHE cipher suites. The IETF should not
perpetually support systems that can't be upgraded.

thanks,
Rob


On Tue, Dec 13, 2022 at 7:51 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> I do not support deprecation, because there will be deployed devices (IoT,
> SCADA) that aren’t upgradable – and the new stuff will have to access them.
>
>
>
> I’ll spare the group my personal opinion about this draft.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> *From: *TLS  on behalf of Ira McDonald <
> blueroofmu...@gmail.com>
> *Date: *Tuesday, December 13, 2022 at 10:47
> *To: *Sean Turner , Ira McDonald 
> *Cc: *TLS List 
> *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites
>
>
>
> Hi,
>
>
>
> Yes - I support deprecating all FFDHE cipher suites including well-known
> groups.
>
>
>
> Cheers,
>
> - Ira
>
>
>
>
>
> 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 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

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

[David Benjamin]

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 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

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

[Salz, Rich]

I support deprecating all of them. My reason is not because I think there are 
known weaknesses, but because we can remove code.

There are apparently devices that cannot be updated to do this and that's okay. 
 There are apparently devices that could not be upgraded to support TLS 1.3 and 
we defined it anyway. :)


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

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

[Loganaden Velvindron]

I support.

On Tue, Dec 13, 2022, 18:47 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 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

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

[Blumenthal, Uri - 0553 - MITLL]

I do not support deprecation, because there will be deployed devices (IoT, 
SCADA) that aren’t upgradable – and the new stuff will have to access them.

 

I’ll spare the group my personal opinion about this draft.

-- 

V/R,

Uri

 

 

From: TLS  on behalf of Ira McDonald 

Date: Tuesday, December 13, 2022 at 10:47
To: Sean Turner , Ira McDonald 
Cc: TLS List 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites

 

Hi,

 

Yes - I support deprecating all FFDHE cipher suites including well-known groups.

 

Cheers,

- Ira

 

 

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 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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ira McDonald]

Hi,

Yes - I support deprecating all FFDHE cipher suites including well-known
groups.

Cheers,
- Ira


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 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