Subject: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

From: "Martin Thomson" <[email-masked]>
Date: Tue, 09 Mar 2021 02:33:12 +1100

Well overdue.  We should do this.

The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the document content.  I only see static or semi-static DH and ECDH key exchange being deprecated (in the document as non-ephemeral).

---

From: John Mattsson <[email-masked]>
Date: Mon, 8 Mar 2021 16:34:14 +0000

+1 for forbidding more old crap.

Lack of forward secrecy should imply at least NOT RECOMMENDED.

Does it make sense to forbid things for TLS 1.0 and TLS 1.1 when we soon have an RFC forbidding use of TLS 1.0 and TLS 1.1?

Cheers,
John

-----Original Message-----
From: TLS <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Date: Monday, 8 March 2021 at 16:34
To: "[email-masked]" <[email-masked]>
Subject: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Carrick Bartle <[email-masked]>
Date: Mon, 8 Mar 2021 09:52:33 -0800

Agreed. I'll change the title to reflect that.

> On Mar 8, 2021, at 7:33 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: David Benjamin <[email-masked]>
Date: Mon, 8 Mar 2021 13:05:38 -0500

I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:

- The construction is broken. The leak itself in the Raccoon attack comes
from TLS 1.2 removing leading zeros. We can't change the meaning of the
existing code points, so any fix there would involve dropping them.

- It lacks group negotiation, which makes it very difficult to migrate away
from small groups. At least in the web, it's already no longer supported by
most implementations.
https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ
https://bugzilla.mozilla.org/show_bug.cgi?id=1496639
https://weakdh.org/

On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle <cbartle891=
[email-masked]> wrote:

> > The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to
> match the document content.  I only see static or semi-static DH and ECDH
> key exchange being deprecated (in the document as non-ephemeral).
> >

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 09 Mar 2021 05:09:01 +1100

One thing at a time?

On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
> - The construction is broken. The leak itself in the Raccoon attack 
> comes from TLS 1.2 removing leading zeros. We can't change the meaning 
> of the existing code points, so any fix there would involve dropping 
> them.
> 
> - It lacks group negotiation, which makes it very difficult to migrate 
> away from small groups. At least in the web, it's already no longer 
> supported by most implementations.
> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle 
> <cbartle891=[email-masked]> wrote:

---

From: Andrei Popov <[email-masked]>
Date: Mon, 8 Mar 2021 18:15:19 +0000

TLS_DHE is weak when used with interoperable key lengths. It also causes interop issues dues to several instances of under-specification (leading zeros, lack of group negotiation). I'm in favor of deprecating TLS_DHE.

Cheers,

Andrei

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Martin Thomson
Sent: Monday, March 8, 2021 10:09 AM
To: David Benjamin <[email-masked]>; Carrick Bartle <cbartle891=[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: [EXTERNAL] Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

One thing at a time?

On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou
> ps.google.com%2Fa%2Fchromium.org%2Fg%2Fblink-dev%2Fc%2FAAdv838-koo%2Fm
> %2FbJv17voIBAAJ&amp;data=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5
> f995fc7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C637508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=eb3SfPDYI
> BMeqtBRlCwTB5U4kc4r9%2FkREnmrHN%2FAegc%3D&amp;reserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> illa.mozilla.org%2Fshow_bug.cgi%3Fid%3D1496639&amp;data=04%7C01%7CAndr
> ei.Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf
> 86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C2000&amp;sdata=jQ0%2B%2Bh9q%2BSdHqIpeEyr9M08p8cAD6MG5U9OG4z9ybN
> 4%3D&amp;reserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweak
> dh.org%2F&amp;data=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5f995fc
> 7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> 7508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=nyyFho5b73MVWuD
> nV0uBdfZB2sUs4WUHox4q4aI3m9M%3D&amp;reserved=0
> 
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > www.ietf.org%2Fmailman%2Flistinfo%2Ftls&amp;data=04%7C01%7CAndrei.
> > > Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988b
> > > f86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7
> > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > > CJXVCI6Mn0%3D%7C2000&amp;sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJl
> > > MxGrSHmk%3D&amp;reserved=0
> > 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.ietf.org%2Fmailman%2Flistinfo%2Ftls&amp;data=04%7C01%7CAndrei.Popo
> > v%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf86f14
> > 1af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > %3D%7C2000&amp;sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJlMxGrSHmk%3D&
> > amp;reserved=0

_______________________________________________
TLS mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&amp;data=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJlMxGrSHmk%3D&amp;reserved=0

---

From: Carrick Bartle <[email-masked]>
Date: Mon, 8 Mar 2021 10:52:15 -0800

If the draft to deprecate 1.0 and 1.1 becomes an RFC while this is still a draft, I'll remove all mention of 1.0/1.1.

> On Mar 8, 2021, at 8:34 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 8 Mar 2021 10:55:39 -0800

> If the draft to deprecate 1.0 and 1.1 becomes an RFC while this is still a draft, I'll remove all mention of 1.0/1.1.

I expect it to become an RFC this week.

-Ben

---

From: Carrick Bartle <[email-masked]>
Date: Mon, 8 Mar 2021 11:06:14 -0800

I'm not opposed to expanding the scope of this document to include deprecating DHE. Is there a major advantage to that being its own draft?

> On Mar 8, 2021, at 10:09 AM, Martin Thomson <[email-masked]> wrote:
> 
> One thing at a time?
>

---

From: David Benjamin <[email-masked]>
Date: Mon, 8 Mar 2021 14:24:55 -0500

I guess it's a question of what the goal of this draft is. I don't
particularly care as long as it's self-consistent. :-)

We've got the title, "FFDH(E)", which would suggest targeting TLS_DH_*,
TLS_DHE_*, and even NamedGroup.ffdhe*, and not anything around ECDH(E).
We've got the contents, which are targeting non-PFS flows, EC or FF. That
is, TLS_DH_*, TLS_ECDH_*, and uses of (EC)DHE that aren't actually
ephemeral.
We've got the Raccoon citation, which would suggest[*] targeting TLS_DH_*
and TLS_DHE_*, due to the buggy construction, and possibly also the non-PFS
modes of both 1.3 FFDHE and 1.2/1.3 ECDHE because key reuse is more fragile.

[*] From the conclusion of the paper: "The most straightforward mitigation
against the attack is to remove support for TLS-DH(E) entirely, as most
major client implementations have already stopped supporting them"

On Mon, Mar 8, 2021 at 2:06 PM Carrick Bartle <[email-masked]> wrote:

> I'm not opposed to expanding the scope of this document to include
> deprecating DHE. Is there a major advantage to that being its own draft?
>
>

---

From: Carrick Bartle <[email-masked]>
Date: Mon, 8 Mar 2021 12:28:00 -0800

Great, sounds good to me then.

> On Mar 8, 2021, at 11:24 AM, David Benjamin <[email-masked]> wrote:
> 
> I guess it's a question of what the goal of this draft is. I don't particularly care as long as it's self-consistent. :-)
> 
> We've got the title, "FFDH(E)", which would suggest targeting TLS_DH_*, TLS_DHE_*, and even NamedGroup.ffdhe*, and not anything around ECDH(E).
> We've got the contents, which are targeting non-PFS flows, EC or FF. That is, TLS_DH_*, TLS_ECDH_*, and uses of (EC)DHE that aren't actually ephemeral.
> We've got the Raccoon citation, which would suggest[*] targeting TLS_DH_* and TLS_DHE_*, due to the buggy construction, and possibly also the non-PFS modes of both 1.3 FFDHE and 1.2/1.3 ECDHE because key reuse is more fragile.
> 
> [*] From the conclusion of the paper: "The most straightforward mitigation against the attack is to remove support for TLS-DH(E) entirely, as most major client implementations have already stopped supporting them"
> 
> On Mon, Mar 8, 2021 at 2:06 PM Carrick Bartle <[email-masked] <mailto:[email-masked]>> wrote:
> > On Mar 8, 2021, at 10:09 AM, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > One thing at a time?
> > 
> >> https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ <https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ>
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1496639 <https://bugzilla.mozilla.org/show_bug.cgi?id=1496639>
> >> https://weakdh.org/ <https://weakdh.org/>
> >> 
> >> <cbartle891=[email-masked] <mailto:[email-masked]>> wrote:
> >>>> On Mar 8, 2021, at 7:33 AM, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> >>>> 
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> >>> 
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>

---

From: Brian Smith <[email-masked]>
Date: Mon, 8 Mar 2021 16:12:57 -0800

It is sad that nobody is willing to discuss the obvious downsides of this
proposal as written, which should at least be mentioned in the security
considerations. Without discussing the downsides we're reducing engineering
to politics. If we discuss the downsides then we can substantially improve
the proposal.

Deprecating FFDHE key exchange without deprecating RSA key exchange will
substantially increase the usage of RSA key exchange and thus make server
key compromise more dangerous. At a minimum, RSA key exchange should be
deprecated at the same time, in the same document.

Look at Windows Server 2012 and similar legacy products that are in
widespread use, which don't support any PFS cipher suites except FFDHE.
Please deprecate RSA key exchange at the same time so that there is enough
motivation for vendors of these legacy products to add safe alternatives
and/or for users of these legacy implementations to upgrade to something
new that implements a safe alternative. (Note that Windows Server 2012 did
add a patch to enable increasing its FFDHE key size to safe sizes.)

It would be useful for the browser vendors that recently dropped FFDHE
support to share their measurements for how much RSA key exchange usage
increased after their changes. That would help us quantify the real-world
impact of this change.

RSA key exchange uses flawed and error-prone cryptography that is prone to
side channels as well, PKCS#1 encryption/decryption. Previous studies have
found widespread flaws in implementations that are (AFAICT) even more
easily exploitable than the Racoon attack is.

It is easy to imagine a perfect implementation of RSA key exchange that
also perfectly protects the server's private key. It is unrealistic to
expect implementations to actually live up to that ideal. When RSA key
exchange is used, then a government that can effectively undo all the past
encryption of a server if it can force the server operator to disclose the
key, even for a perfect implementation of RSA key exchange.

Deprecating RSA key exchange at the same time as FFDHE will encourage
adoption of newer products that also often support TLS 1.3.

Without creating a new, correct, way to use FFDHE key exchange, we're left
with elliptic curve (ECDHE) key exchange as the only reasonable and
widely-implemented key exchange mechanism.

Cheers,
Brian
(Speaking only for myself)

---

From: Brian Smith <[email-masked]>
Date: Mon, 8 Mar 2021 16:23:17 -0800

> to politics. If we discuss the downsides then we can substantially improve

To clarify: the RFC is about deprecating non-ephemeral cipher suites and
reusing keys in implementing the ephemeral cipher suites. I don't know of
any practical issues with the RFC as written, although I think the blanket
prohibition of reuse of ECDHE keys is maybe not really justified.

The proposal that I'm saying needs to be improved is the proposal of
deprecating the ephemeral FFDHE cipher suites at the same time. IMO that's
the part that should have deprecation of RSA cipher suites done at the same
time.

Cheers,
Brian

---

From: Andrei Popov <[email-masked]>
Date: Tue, 9 Mar 2021 00:30:27 +0000

Hi Brian,

  *   Look at Windows Server 2012 and similar legacy products that are in widespread use, which don't support any PFS cipher suites except FFDHE.
Windows Server 2012/Windows 8 support both TLS_ECDHE_ECDSA and TLS_ECDHE_RSA cipher suites: TLS Cipher Suites in Windows 8 - Win32 apps | Microsoft Docs<https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-8>

Our telemetry shows extremely low usage of TLS_DHE cipher suites and I’m in favor of deprecating them.

Cheers,

Andrei

From: TLS <[email-masked]> On Behalf Of Brian Smith
Sent: Monday, March 8, 2021 4:13 PM
To: Martin Thomson <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: [EXTERNAL] Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

It is sad that nobody is willing to discuss the obvious downsides of this proposal as written, which should at least be mentioned in the security considerations. Without discussing the downsides we're reducing engineering to politics. If we discuss the downsides then we can substantially improve the proposal.

Deprecating FFDHE key exchange without deprecating RSA key exchange will substantially increase the usage of RSA key exchange and thus make server key compromise more dangerous. At a minimum, RSA key exchange should be deprecated at the same time, in the same document.

Look at Windows Server 2012 and similar legacy products that are in widespread use, which don't support any PFS cipher suites except FFDHE. Please deprecate RSA key exchange at the same time so that there is enough motivation for vendors of these legacy products to add safe alternatives and/or for users of these legacy implementations to upgrade to something new that implements a safe alternative. (Note that Windows Server 2012 did add a patch to enable increasing its FFDHE key size to safe sizes.)

It would be useful for the browser vendors that recently dropped FFDHE support to share their measurements for how much RSA key exchange usage increased after their changes. That would help us quantify the real-world impact of this change.

RSA key exchange uses flawed and error-prone cryptography that is prone to side channels as well, PKCS#1 encryption/decryption. Previous studies have found widespread flaws in implementations that are (AFAICT) even more easily exploitable than the Racoon attack is.

It is easy to imagine a perfect implementation of RSA key exchange that also perfectly protects the server's private key. It is unrealistic to expect implementations to actually live up to that ideal. When RSA key exchange is used, then a government that can effectively undo all the past encryption of a server if it can force the server operator to disclose the key, even for a perfect implementation of RSA key exchange.

Deprecating RSA key exchange at the same time as FFDHE will encourage adoption of newer products that also often support TLS 1.3.

Without creating a new, correct, way to use FFDHE key exchange, we're left with elliptic curve (ECDHE) key exchange as the only reasonable and widely-implemented key exchange mechanism.

Cheers,
Brian

---

From: David Benjamin <[email-masked]>
Date: Mon, 8 Mar 2021 20:03:14 -0500

Chrome dropped TLS 1.2 DHE nearly five years ago now. I don't have data on
the current DHE-to-RSA conversion, but I can tell you what it was then.
When we put it under a fallback for measurement, only 2% of connections
negotiated DHE. Of that 2%, 95% used 1024-bit DHE. That means we really
only had 2% * 5% = 0.1% of connections that actually used it effectively.
https://groups.google.com/a/chromium.org/g/security-dev/c/dYyhKHPnrI0/m/pNxx8vTKBAA

At 95% with no group negotiation, clearing DHE-1024 was implausible without
a *dramatic* shift in the server population. Moreover, there is a TLS
client with a *maximum* DHE group size of 1024-bit, so servers risked
interop problems if they switched to larger group sizes. (To say nothing of
DoS risks because DHE is pretty slow.) The code points are basically stuck.
It's a pity we didn't have RFC7919 from the start, but anyone implementing
it can already implement ECDHE and now TLS 1.3. It also doesn't help here
because, by reusing the old TLS 1.2 DHE code points, it's not possible for
a client to offer RFC7919 TLS 1.2 DHE without simultaneously offering
legacy TLS 1.2 DHE.

All those numbers were five years ago. ECDHE deployment has increased
substantially, so DHE's value has only gone down. Looks like Firefox
dropped it more recently, so perhaps they'll have more recent numbers.

David

On Mon, Mar 8, 2021 at 7:30 PM Andrei Popov <Andrei.Popov=
[email-masked]> wrote:

> Hi Brian,
>
>
>
>    - Look at Windows Server 2012 and similar legacy products that are in
> Windows Server 2012/Windows 8 support both TLS_ECDHE_ECDSA and
> TLS_ECDHE_RSA cipher suites: TLS Cipher Suites in Windows 8 - Win32 apps
> | Microsoft Docs
> <https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-8>
>
>
>
> *From:* TLS <[email-masked]> *On Behalf Of * Brian Smith
> *Sent:* Monday, March 8, 2021 4:13 PM
> *To:* Martin Thomson <[email-masked]>
> *Cc:* <[email-masked]> <[email-masked]>
> *Subject:* [EXTERNAL] Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe
>
>
>

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 9 Mar 2021 01:42:43 +0000

Server 2012 with the exception of the AES-GCM cipher suites only support ECDHE.

________________________________________
From: TLS <[email-masked]> on behalf of Brian Smith <[email-masked]>
Sent: Monday, March 8, 2021 4:12 PM
To: Martin Thomson
Cc: <[email-masked]>
Subject: Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

Cheers,
Brian

---

From: Carrick Bartle <[email-masked]>
Date: Mon, 8 Mar 2021 19:08:31 -0800

> I think the blanket prohibition of reuse of ECDHE keys is maybe not really justified.

Why is that?

> IMO that's the part that should have deprecation of RSA cipher suites done at the same time.

RSA seems to me to be too off-topic for this draft. (It also seems to me that RSA is still too widely used and not broken enough to merit deprecation.) If you think this draft requires that RSA key exchange also be deprecated, that could be done in a parallel draft.

> On Mar 8, 2021, at 4:23 PM, Brian Smith <[email-masked]> wrote:
> 
> Brian Smith <[email-masked] <mailto:[email-masked]>> wrote:
> To clarify: the RFC is about deprecating non-ephemeral cipher suites and reusing keys in implementing the ephemeral cipher suites. I don't know of any practical issues with the RFC as written, although I think the blanket prohibition of reuse of ECDHE keys is maybe not really justified.
> 
> The proposal that I'm saying needs to be improved is the proposal of deprecating the ephemeral FFDHE cipher suites at the same time. IMO that's the part that should have deprecation of RSA cipher suites done at the same time.
> 
> Cheers,
> Brian

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 9 Mar 2021 03:12:56 +0000

David Benjamin <[email-masked]> writes:

>against the attack is to remove support for TLS-DH(E) entirely, as most major
>client implementations have already stopped supporting them"

Just as you need to automatically add "in mice" to the end of any announcement
of a new medical result, so you also need to add "on the web" to the end of
any pronouncement about TLS.  This only applies to the special bubble of the
web.  For other situations, the effect of banning DHE will be to force
everyone to move to RSA.  I've already seen this in payments processing
applications, instead of using the secure-unless-you-implement-it-really-badly
DHE they use the almost-impossible-to-do-securely RSA, because someone has
told them not to use DHE.

So a blanket ban of DHE will lead to a net loss in security.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 9 Mar 2021 03:14:23 +0000

>increased after their changes. That would help us quantify the real-world

... in mice.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 8 Mar 2021 22:57:19 -0500

> > I think the blanket prohibition of reuse of ECDHE keys is maybe not

Because there are still many TLS (non-web) implementations that don't
do ECDHE.

Is there a credible active MiTM attack that can cause a server and
client both capable of ECDHE to use FFDHE or RSA key exchange?

If so, a properly scoped (to the web or the public Internet, ...)
deprecation of FFDHE and RSA key exchange is then justified.

If not, then I am cursed to ever repeat a key message of RFC7435:

    * In practice security improves more when you raise the ceiling,
      rather the floor.

    * If you set the bar too high, users will resort to less secure,
      but more accessible technologies.

If your basic protocol is basically sound (has downgrade-resistant
feature negotiation) then deprecation can be counter-productive in
the short to medium term, so long as a non-negligible fraction of
the installed base is then no longer tall enough to take the ride.

Therefore, a better approach may be to recommend that for key
exchange ECDHE should be prioritised ahead of EDH and RSA.

The effort may also be largely redundant, affecting only the
deployments that are likely to end up resorting to suboptimal
choices.

Below, for example, is the default TLS 1.2 ordered cipherlist for
OpenSSL 1.1.1.  All other parameters being equal, in each group
the order is kECDHE+aECDSA, kECDHE+aRSA and finally kDHE+aRSA:

  ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AESGCM(256) Mac=AEAD
  ECDHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=ECDH   Au=RSA  Enc=AESGCM(256) Mac=AEAD
  DHE-RSA-AES256-GCM-SHA384     TLSv1.2 Kx=DH     Au=RSA  Enc=AESGCM(256) Mac=AEAD

  ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
  ECDHE-RSA-CHACHA20-POLY1305   TLSv1.2 Kx=ECDH   Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
  DHE-RSA-CHACHA20-POLY1305     TLSv1.2 Kx=DH     Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD

  ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AESGCM(128) Mac=AEAD
  ECDHE-RSA-AES128-GCM-SHA256   TLSv1.2 Kx=ECDH   Au=RSA  Enc=AESGCM(128) Mac=AEAD
  DHE-RSA-AES128-GCM-SHA256     TLSv1.2 Kx=DH     Au=RSA  Enc=AESGCM(128) Mac=AEAD

  ECDHE-ECDSA-AES256-SHA384     TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AES(256)  Mac=SHA384
  ECDHE-RSA-AES256-SHA384       TLSv1.2 Kx=ECDH   Au=RSA  Enc=AES(256)  Mac=SHA384
  DHE-RSA-AES256-SHA256         TLSv1.2 Kx=DH     Au=RSA  Enc=AES(256)  Mac=SHA256

  ECDHE-ECDSA-AES128-SHA256     TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AES(128)  Mac=SHA256
  ECDHE-RSA-AES128-SHA256       TLSv1.2 Kx=ECDH   Au=RSA  Enc=AES(128)  Mac=SHA256
  DHE-RSA-AES128-SHA256         TLSv1.2 Kx=DH     Au=RSA  Enc=AES(128)  Mac=SHA256

  ECDHE-ECDSA-AES256-SHA        TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
  ECDHE-RSA-AES256-SHA          TLSv1 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
  DHE-RSA-AES256-SHA            SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1

  ECDHE-ECDSA-AES128-SHA        TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
  ECDHE-RSA-AES128-SHA          TLSv1 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
  DHE-RSA-AES128-SHA            SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1

  -- Finally, last resort kRSA
  AES256-GCM-SHA384             TLSv1.2 Kx=RSA    Au=RSA  Enc=AESGCM(256) Mac=AEAD
  AES128-GCM-SHA256             TLSv1.2 Kx=RSA    Au=RSA  Enc=AESGCM(128) Mac=AEAD
  AES256-SHA256                 TLSv1.2 Kx=RSA    Au=RSA  Enc=AES(256)  Mac=SHA256
  AES128-SHA256                 TLSv1.2 Kx=RSA    Au=RSA  Enc=AES(128)  Mac=SHA256
  AES256-SHA                    SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
  AES128-SHA                    SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1

There's hardly any need to goad the ecosystem to prefer ECDHE when
available, that's already done.

> > suites done at the same time.

Here of course RSA means RSA key exchange, not RSA signatures.

> RSA seems to me to be too off-topic for this draft. (It also seems to
> me that RSA is still too widely used and not broken enough to merit
> deprecation.) If you think this draft requires that RSA key exchange
> also be deprecated, that could be done in a parallel draft.

I think there's a valid point here, either deprecate "kRSA" first
or both together.  Making it clear that no auditor's checklist
should become "green" by disabling DHE and leaving just RSA
key exchange standing.

-- 
    Viktor.

---

From: John Mattsson <[email-masked]>
Date: Tue, 9 Mar 2021 06:15:53 +0000

Brian Smith wrote:
>Deprecating FFDHE key exchange without deprecating RSA key exchange will substantially increase the usage >of RSA key exchange and thus make server key compromise more dangerous. At a minimum, RSA key >exchange should be deprecated at the same time, in the same document. 

Deprecating static RSA and everything else that does not have PFS is long overdue. RFC 7540 did this 6 years ago, and it was not a day too late. Strange that the best TLS profiling was/is done by HTTPBIS.

Viktor Dukhovni wrote:
>In practice security improves more when you raise the ceiling, rather the floor.

Let’s start with mandating support of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for the remaining TLS 1.2 implementations. RFC 7540 did this 6 years ago, and it was not a day too late.

Cheers,
John

From: TLS <[email-masked]> on behalf of Brian Smith <[email-masked]>
Date: Tuesday, 9 March 2021 at 01:13
To: Martin Thomson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

Cheers,
Brian

---

From: Rob Sayre <[email-masked]>
Date: Mon, 8 Mar 2021 22:25:29 -0800

On Mon, Mar 8, 2021 at 10:16 PM John Mattsson <john.mattsson=
[email-masked]> wrote:

> substantially increase the usage >of RSA key exchange and thus make server
> key compromise more dangerous. At a minimum, RSA key >exchange should be
> Deprecating static RSA and everything else that does not have PFS is long
> overdue. RFC 7540 did this 6 years ago, and it was not a day too late.
> Strange that the best TLS profiling was/is done by HTTPBIS.
>

That is strange.

> Let’s start with mandating support of
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for the remaining TLS 1.2
> implementations. RFC 7540 did this 6 years ago, and it was not a day too
> late.
>

I don't understand the motivation. Why not deprecate all of the RSA cipher
suites?

thanks,
Rob

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Mar 2021 02:35:50 -0500

On Mon, Mar 08, 2021 at 10:25:29PM -0800, Rob Sayre wrote:

> On Mon, Mar 8, 2021 at 10:16 PM John Mattsson wrote:
> >
> > Viktor Dukhovni wrote:
> > implementations. RFC 7540 did this 6 years ago, and it was not a day
> > too late.
> 

If you mean all the RSA key exchange suites, sure where that's a viable
choice.  It was already argued upthread that this needs to be done
before or as part of deprecating FFDHE, lest the latter just lead to
reversion to RSA key exchange.

This would be a rather drastic floor-raising exercise, possibly in
excess of the present ceiling in some market niches.  The results
are not always what we want or expect.

As suggested above, it may first be prudent to specify some MTI
ECDHE ciphers, and check that these are being widely and correctly
implemented and deployed in some of the less familiar places that
have not done so already.

If there are major code size or other resource limits that preclude
support for both FFDHE and ECDHE, or even ECDHE alone, little is likely
to be gained by specifying that the floor is now 2 feet above the
ceiling.

I realise that my focus primarily on the ceiling and not the floor is
not universally shared, and may even be heretical in some circles, but
whether or not it should be the dominant concern, it surely warrants
some thought, because otherwise you do eventually run out of room in
between.

So my take is that barring emergencies, deprecations mostly take care of
themselves, because the better options are compelling and preferred by
default.  Such emergencies aside, deprecation can happen once "nobody"
is using an algorithm, not only on the web, but more broadly across all
the market sectors that consume IETF technologies.

Today, I sent Wietse a patch set that disables "medium" ciphers in
Postfix by default and requires TLS 1.2 (rather than 1.0) when TLS is
"mandatory" (submission, DANE, or other destination-specific policy).
I hope it will be merged in time for Postfix 3.6.

At this point, systems using TLS 1.0, SEED, RC4, IDEA or 3DES in SMTP
TLS are rare, and not expected to peers for mandatory TLS.  The ceiling
has been high for quite some time, and the floor raising is just a
formality.  Also, I'm just changing default settings, not removing
functionality.  If someone still needs the legacy crypto in some
dusty corner of their network, I'm not going to stop them.

-- 
    Viktor.

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 9 Mar 2021 11:29:40 -0800

> Because there are still many TLS (non-web) implementations that don't

I'm confused: if those implementations don't do ECDHE, what's wrong with prohibiting the way it's used?

>    * In practice security improves more when you raise the ceiling,

This sort of suggests that we should never deprecate anything, ever, no?

> On Mar 8, 2021, at 7:57 PM, Viktor Dukhovni <[email-masked]> wrote:
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Mar 2021 16:04:57 -0500

> with prohibiting the way it's used?

The proposal on the table is to deprecate FFDHE.  If the software stack
has no ECDHE, and only has FFDHE, it would then have to resort to RSA
key exchange.

> This sort of suggests that we should never deprecate anything, ever, no?

No, rather it suggests that *before* we deprecate, we first work to get
everyone to use stronger options, and then, crisis situations aside,
wait for the long tail to effectively peter out.  Then deprecate, once
it is clear that it is mostly a formality.

The difficult question is how to handle situations where the long tail
is mostly invisible to the IETF community, i.e. happens on isolated
networks, that use (and may be audited against) our standards, but don't
show up in Internet surveys, ...  It may then be hard to know when to
declare to declare victory.  I don't have a good answer for that.
This is where Peter Gutmann et. al., may be able to help.

Deprecation is not always easy, and we don't always the desired outcome.

I hear that in Germany operators of some services are expected to
operate their systems in accordance with "state of the art" practices
(I guess BCP).  This may allow a distinction between "tolerable" and
"best practice", where things we might deprecate would no longer be
"best practice", but are still within the standard, and expected
to interoperate if implemented by both (all relevant) parties.

So short of deprecation, one might say that the legacy algorithms:

    * Are not recommended.
    * Can't be expected to be widely implemented
    * Should only be used when the preferred choices
      are not available.

Which is not nearly as strong as "MUST NOT", which is what I take
deprecation to mean.  Am I wrong about the intended meaning of
"deprecation"?

-- 
   Viktor.

---

From: Brian Smith <[email-masked]>
Date: Tue, 9 Mar 2021 16:22:01 -0800

> <https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-8>

Thanks. I forgot about the CBC cipher suites. What I mean to say is that it
doesn't support any cipher suites with AEAD ciphers and PFS except the DHE
ones. The result was that Firefox had to choose between enabling the
CBC-SHA2 cipher suites or enabling RSA + AEAD for compatibility with it,
and they chose to latter; see
https://bugzilla.mozilla.org/show_bug.cgi?id=1638369.

Cheers,
Brian

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 9 Mar 2021 16:47:19 -0800

> The proposal on the table is to deprecate FFDHE. 

Sorry, the title of the document is incorrect and will be changed. The actual proposal is not to deprecate FFDHE but to deprecate FFDH and prohibit key reuse for FFDHE.

> On Mar 9, 2021, at 1:04 PM, Viktor Dukhovni <[email-masked]> wrote:
>

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 9 Mar 2021 16:49:18 -0800

Oh, never mind, presumably you're referring to the proposal in this thread.

> On Mar 9, 2021, at 4:47 PM, Carrick Bartle <cbartle891=[email-masked]> wrote:
>

---

From: Brian Smith <[email-masked]>
Date: Tue, 9 Mar 2021 17:12:36 -0800

> I think the blanket prohibition of reuse of ECDHE keys is maybe not

PFS isn't all-or-nothing. I do think each key should be used when
practical, although I don't know why it would be bad to reuse a key for a
very short period of time. E.g. if one has a key, and as soon as it is used
once, asynchronously kicks off the generation of its replacement, then
using that key until the replacement has been generated seems OK to me.
Things get more problematic the longer/more the key is reused.

IMO that's the part that should have deprecation of RSA cipher suites done
> at the same time.
>
> RSA seems to me to be too off-topic for this draft. (It also seems to me
> that RSA is still too widely used and not broken enough to merit
> deprecation.) If you think this draft requires that RSA key exchange also
> be deprecated, that could be done in a parallel draft.
>

RSA is on-topic because deprecating DHE cipher suites quite directly leads
to more use of RSA key exchange. There's already evidence of this from
Firefox, where they had to enable more RSA key exchange cipher suites
immediately after disabling the DHE cipher suites.

It is true that RSA key exchange is widely used; the purpose of deprecating
it is to put political pressure on implementers to make it less widely
used. That's the whole point of these deprecation RFCs.

RSA is the worst key exchange mechanism in TLS w.r.t. to PFS, which is the
reason the paper cites for avoiding ECDH key reuse for ECDHE cipher suites.
Why is it horrible to reuse an ECDH key a few times but it's OK to reuse an
RSA key millions of times?

Is RSA "broken enough"? That goes back to my point that while in theory one
could do a perfect job of protecting their server's private keys, in
practice many will fail at it. That's why we mandated PFS cipher suites in
TLS 1.3 and in HTTP/2, to reduce the harm in losing control of the private
key.

The draft makes the good point that it would be hard to secure a DH(E)
implementation against timing attacks. But, RSA is the *hardest* to secure
key exchange mechanism w.r.t. timing attacks. Not only does it require very
careful coding within the core crypto library, but it also requires very
error-prone and non-obvious logic within the TLS implementation. Raccoon
mitigations wouldn't require that. (For the record, the difficulty of
mitigating the timing side channels mentioned in the Raccoon paper seems to
be quite overstated. We could all do it if we wanted to.)

Anyway, to be clear, I'm not advocating for DHE cipher suites in TLS 1.2.
I'm advocating against encouraging more use of RSA cipher suites, and I'm
against encouraging the continued use of TLS 1.2 in general. Deprecating
(EC)DH(E) key exchange without deprecating RSA has the rhetorical effect of
saying RSA key exchange is not as dangerous as (EC)DH(E); I don't think
that's true at all. Things need to upgrade to TLS 1.3 and things need to
drop RSA key exchange in favor of forward secret key exchange.

Cheers,
Brian

---

From: Watson Ladd <[email-masked]>
Date: Tue, 9 Mar 2021 17:15:48 -0800

> it is clear that it is mostly a formality.

Depreciation is how you get the laggards to replace things.
Depreciation leads, not tails, replacement. Because we depreciated
RC4, PCI stopped being silly about mandating its uses. Had we not done
this, they would have continued as is.

> to interoperate if implemented by both (all relevant) parties.

This was already done via the UTA working group.

>     * Should only be used when the preferred choices

That is depreciation.

> deprecation to mean.  Am I wrong about the intended meaning of

There is no protocol police. To the extent that industries want to
ensure that systems are secure, they have to ensure updates for the
life of the system. I think it's reasonable to require implementation
and deployment of 12 year old standards.

Sincerely,
Watson Ladd

--
Astra mortemque praestare gradatim

---

From: Carrick Bartle <[email-masked]>
Date: Wed, 10 Mar 2021 09:49:09 -0800

> deprecation to mean.  Am I wrong about the intended meaning of

That's my understanding as well.