Subject: [TLS] Static DH timing attack

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 Sep 2020 15:04:19 +0000

https://raccoon-attack.com/

Do we need a short RFC saying “do not use static DH” ?

I am probably not the only one thinking fondly of draft-green-tls-static-dh-in-tls13 now.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 9 Sep 2020 18:18:59 +0300

I also want to remind about so called "Enterprise TLS" — if I remember
correctly, they introduced this bug to their modified TLS 1.3
specification...

ср, 9 сент. 2020 г., 18:04 Salz, Rich <rsalz=[email-masked]>:

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

---

From: Karthik Bhargavan <[email-masked]>
Date: Wed, 9 Sep 2020 17:19:13 +0200

Hi Rich,

I think static DH, or reusing ephemerals, has always been a weak point of TLS implementations: e.g. if you don’t validate the peer’s public value, you may leak your (reusable) private value. In principle, if implemented correctly, static DH can be ok if you don’t care about forward secrecy, but TLS 1.2 also did this weird thing of truncating the result of DH to strip leading zeroes, which leads to this attack. Retiring static DH and forbidding ephemeral key reuse in TLS 1.2 seems like the safest way forward.

Note that TLS 1.3 does not truncate the result of DH, and neither does draft-green-tls-static-dh-in-tls13, and both (should) ask for peer keys to be validated, so these issues should not apply to TLS 1.3 implementations (unless they are buggy.)

-Karthik

> On 9 Sep 2020, at 17:04, Salz, Rich <rsalz=[email-masked]> wrote:
>

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 10 Sep 2020 09:23:02 +0000

>Do we need a short RFC saying “do not use static DH” ?

There are two things arguing against it:

Reason the first: Static-ephemeral DH was a dumb idea when it was proposed in
X9.42 more than twenty years ago and hasn't gotten any better since then.  If
people haven't learned from twenty years of papers and attacks then yet
another publication telling them about it probably won't make any difference.

Reason the second: Telling people not to use static-ephemeral DH will mean
telling them not to use 25519 key exchange, which will make their heads
asplode.

Peter.

---

From: Achim Kraus <[email-masked]>
Date: Thu, 10 Sep 2020 15:36:08 +0200

> telling them not to use 25519 key exchange, which will make their heads

So, risking damaged heads:
Does using x25519 for ECDHE is significant less secure
than using it with e.g. secp384r1?

Or do I mix-up things and "DH with 25519 keys" is something different?

best regards
Achim Kraus

---

From: Dan Brown <[email-masked]>
Date: Thu, 10 Sep 2020 15:17:59 +0000

From: TLS <[email-masked]> On Behalf Of Salz, Rich
> Do we need a short RFC saying “do not use static DH” ?

Don’t TLS 0-RTT and ESNI/ECH via HPKE use a type of (semi)static ECDH? If so, then an RFC to ban static (EC)DH in TLS would need to be very clear about not referring to these use cases of static ECDH.

My 2c. What about combining static ECDH (instead of signatures) with ephemeral ECDH, e.g. for more fully deniable authentication?  (ECMQV does this.)  (Perhaps this is also similar to the KEMTLS proposal for PQC, https://ia.cr/2020/534 - still need to study that.)

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 10 Sep 2020 12:00:40 -0400

Dan,

What you suggest, namely,  DH for both static and ephemeral keys is what
OPTLS was about and this approach is now specified in
https://tools.ietf.org/html/draft-ietf-tls-semistatic-dh-01.

I was never too happy with the name semi-static for such protocol, and
people may think that if static is bad then semi-static is semi-bad :-)
So maybe it should be replaced with something else

It is essentially a DH-KEM, namely a KEM implemented via DH. It has the
advantage over generic KEMs that  g^x sent by the client acts as an
ephemeral KEM public key (producing g^xy) and also as an encapsulation
under the server's public key (producing g^xs).  This shaves one full round
trip relative to a generic KEM-based protocol (this applies to the
protocols with and without client authentication).

Hugo

On Thu, Sep 10, 2020 at 11:19 AM Dan Brown <[email-masked]> wrote:

> *From:* TLS <[email-masked]> *On Behalf Of *Salz, Rich
> Don’t TLS 0-RTT and ESNI/ECH via HPKE use a type of (semi)static ECDH? If
> so, then an RFC to ban static (EC)DH in TLS would need to be very clear
> about not referring to these use cases of static ECDH.
>
>
>
> My 2c. What about combining static ECDH (instead of signatures) with
> ephemeral ECDH, e.g. for more fully deniable authentication?  (ECMQV does
> this.)  (Perhaps this is also similar to the KEMTLS proposal for PQC,
> https://ia.cr/2020/534 - still need to study that.)
>
>
> ------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Sep 2020 18:11:02 +0000

> telling them not to use 25519 key exchange, which will make their heads

Do you mean this because people will confuse DH with ECDHE ?

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 11 Sep 2020 02:21:04 +0000

Achim Kraus <[email-masked]> writes:

>Does using x25519 for ECDHE is significant less secure than using it with
>e.g. secp384r1?

The NIST curves AFAIK are never used that way, it's only done with 25519
(there was something about it in an OpenPGP draft, but I think GPG went
straight to 25519 and only used ECDSA for signatures).

What I'm specifically referring to is DH run sideways, as someone put it
during the X9.42 discussion, i.e. used in static-ephemeral mode to try and
make it work like it's RSA.

In all the code audits I've done of 25519 used that way, I've never seen it
used correctly.  Usually there isn't just one mistake made but many of them.
It's such an obvious problem that that and misuse of RC4-equivalent modes/
algorithms like GCM and ChaCha20 are the first things I look for in crypto
code.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 11 Sep 2020 02:23:48 +0000

>Do you mean this because people will confuse DH with ECDHE ?

See my reply to Achim, it's not that but because banning static-ephemeral
(EC)DH will also affect all the cases where it's being applied as it if were
RSA.

Which, given that it's such a footgun would IMHO be a good thing, but others
will probably disagree :-).

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 11 Sep 2020 13:03:46 +0000

Got it, thanks.

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Sep 2020 10:06:18 -0400

> algorithms like GCM and ChaCha20 are the first things I look for in crypto

I am sure you know that ephemeral-static DH was original used for S/MIME.  The reasoning for ephemeral-static DH was not to make it work like RSA.  Rather, the idea was to provide authentication of the static DH key holder by certifying the static DH public key.  Then, the ephemeral DH key pair is generated using the parameters from the certificate.  One important aspect of this approach was to avoid picking a single group for all of the DH keys.

Russ

---

From: "Filippo Valsorda" <[email-masked]>
Date: Fri, 11 Sep 2020 19:49:44 +0200

I feel like there should be nothing controversial in the context of TLS.
 * Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a MUST NOT, because they can't be implemented securely.
 * Reusing ephemeral shares for ECDHE and DHE ought to be a MUST NOT in all TLS versions, because it's unnecessary and has been a requirement for many attacks now.
 * Non-ephemeral ECDH ciphersuites (TLS_ECDH_*) ought to be a SHOULD NOT, because again ECDH share reuse enables a whole class of attacks.
 * FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DHE_*) ought to be a SHOULD NOT, because they are specified in a dangerous way that is not secure if shares are reused.
If any of the above are not already the case, it should be a quick and easy document.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 12 Sep 2020 03:48:25 +0000

Filippo Valsorda <[email-masked]> writes:

>   Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a
>	MUST NOT, because they can't be implemented securely.
>
>   Reusing ephemeral shares for ECDHE and DHE ought to be a MUST NOT in all
>	TLS versions, because it's unnecessary and has been a requirement for many
>	attacks now.
>
>   Non-ephemeral ECDH ciphersuites (TLS_ECDH_*) ought to be a SHOULD NOT,
>	because again ECDH share reuse enables a whole class of attacks.
>
>   FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DHE_*) ought to be a SHOULD NOT,
>	because they are specified in a dangerous way that is not secure if shares
>	are reused.

I agree with the first two but not the last.  Why is non-ephemeral DH a MUST
NOT but non-ephemeral ECDH a SHOULD NOT?  There's nothing magic about the EC
form that makes it any better or safer.

And for the FFDHE ciphersuites, they're not specified in a dangerous way,
people implement them in a dangerous way.  You really have to go out of your
way to get it wrong, in the case of RACCOON it's actually more effort to get
it wrong (keep old copies of values floating around and reuse them over and
over) than to get it right (generate a fresh value every time).  So it doesn't
need a "don't do FFDHE", it needs a "here's a lot of stupid things you can do
with FFDHE if you put your mind to it.  Don't do any of them".

Or maybe it can be turned into a more general "here are some dumb things that
people have done with TLS over the years.  Check your server to make sure
you're not doing them".  Posting your web server's private key as a .p12 file
in a subdirectory below $DocumentRoot, for example, would be high on my list.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 12 Sep 2020 03:51:51 +0000

Russ Housley <[email-masked]> writes:

>I am sure you know that ephemeral-static DH was original used for S/MIME. The
>reasoning for ephemeral-static DH was not to make it work like RSA. Rather,
>the idea was to provide authentication of the static DH key holder by
>certifying the static DH public key.

... thus making it quack like RSA, with a certified static public key.  That's
exactly the point I was making about running DH sideways, taking a key
agreement mechanism and beating it into a form where it worked more like RSA
key transport.

Peter.

---

From: "Filippo Valsorda" <[email-masked]>
Date: Sat, 12 Sep 2020 14:15:48 +0200

> form that makes it any better or safer.

Non-ephemeral DH is affected by the Raccoon attack, ECDH is not.

> in a subdirectory below $DocumentRoot, for example, would be high on my list.

There are two peers involved in ciphersuite selection, so recommending everyone avoids an unsafe ciphersuite can protect connections even if only one side takes the advice, and even if it's not the side that made the implementation error.

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 16 Sep 2020 10:09:13 +0800

> about not referring to these use cases of static ECDH.

"should not use (semi)static DH  for session key agreement scenario" ?
"may use (semi)static ECDH for no forward security requirement  0-RTT
scenario" ?