Re: [TLS] [EXTERNAL] Re: Regarding draft-bartle-tls-deprecate-ffdhe

2021-03-09 Thread Brian Smith 
Andrei Popov  wrote:

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

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXTERNAL] Re: Regarding draft-bartle-tls-deprecate-ffdhe

2021-03-08 Thread David Benjamin 
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  wrote:

> 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
> 
>
>
>
> Our telemetry shows extremely low usage of TLS_DHE cipher suites and I’m
> in favor of deprecating them.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS  *On Behalf Of * Brian Smith
> *Sent:* Monday, March 8, 2021 4:13 PM
> *To:* Martin Thomson 
> *Cc:*  
> *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
>
> (Speaking only for myself)
> ___
> 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] [EXTERNAL] Re: Regarding draft-bartle-tls-deprecate-ffdhe

2021-03-08 Thread Andrei Popov 
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

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

Cheers,

Andrei

From: TLS  On Behalf Of Brian Smith
Sent: Monday, March 8, 2021 4:13 PM
To: Martin Thomson 
Cc:  
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
(Speaking only for myself)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXTERNAL] Re: Regarding draft-bartle-tls-deprecate-ffdhe

2021-03-08 Thread Andrei Popov 
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  On Behalf Of Martin Thomson
Sent: Monday, March 8, 2021 10:09 AM
To: David Benjamin ; Carrick Bartle 

Cc:  
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:
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou
> ps.google.com%2Fa%2Fchromium.org%2Fg%2Fblink-dev%2Fc%2FAAdv838-koo%2Fm
> %2FbJv17voIBAAJdata=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5
> f995fc7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C637508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=eb3SfPDYI
> BMeqtBRlCwTB5U4kc4r9%2FkREnmrHN%2FAegc%3Dreserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> illa.mozilla.org%2Fshow_bug.cgi%3Fid%3D1496639data=04%7C01%7CAndr
> ei.Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf
> 86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C2000sdata=jQ0%2B%2Bh9q%2BSdHqIpeEyr9M08p8cAD6MG5U9OG4z9ybN
> 4%3Dreserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweak
> dh.org%2Fdata=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5f995fc
> 7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> 7508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=nyyFho5b73MVWuD
> nV0uBdfZB2sUs4WUHox4q4aI3m9M%3Dreserved=0
> 
> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle 
>  wrote:
> > Agreed. I'll change the title to reflect that.
> > 
> > > On Mar 8, 2021, at 7:33 AM, Martin Thomson  wrote:
> > > 
> > > 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).
> > > 
> > > ___
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > www.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=04%7C01%7CAndrei.
> > > Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988b
> > > f86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7
> > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > > CJXVCI6Mn0%3D%7C2000sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJl
> > > MxGrSHmk%3Dreserved=0
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=04%7C01%7CAndrei.Popo
> > v%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf86f14
> > 1af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > %3D%7C2000sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJlMxGrSHmk%3D&
> > amp;reserved=0

___
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJlMxGrSHmk%3Dreserved=0

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