Subject: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets

From: Nimrod Aviram <[email-masked]>
Date: Wed, 16 Sep 2020 19:26:56 +0300

Dear all,

We are writing to ask about the possible security impact of
variable-length secrets on the "Hybrid key exchange in TLS 1.3" RFC
[1].

As you probably know, when using key material of variable length
and processing this material using hash functions, a timing side
channel may arise. In broad terms, when the secret is longer, the hash
function may need to process more blocks internally. In some unfortunate
circumstances, this has led to timing attacks, e.g. Lucky Thirteen [2]
and the newly-disclosed Raccoon Attack [3]. To be clear, we are not
aware of any attack on the proposed standard. Rather, we view this as
an opportunity to defend-in-depth against such attacks, while work on
the standard is in progress.

Our proposal is to add language to the RFC explaining that variable-length
secrets may enable such attacks, and should therefore be avoided when
possible.  Currently, the language seems to allow for variable-length
secrets, should the need arise:
"Variable-length shared secrets ... if it is envisioned that this
specification
be used with algorithms which do not have fixed-length shared secrets ..."

We also note that a related RFC exists, "Hybrid Post-Quantum Key
Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2"
[4]. However, that RFC apparently only uses BIKE, Kyber or SIKE as the
PQ KEM. To our knowledge, all three KEMs have fixed-length secrets. It
may be prudent to add cautionary language to that document as well,
in case other KEMs are used in the future.

Kind regards,
The Raccoon Team

[1]
https://www.ietf.org/id/draft-ietf-tls-hybrid-design-00.html#name-open-questions
[2] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6547131
[3] https://raccoon-attack.com/
[4]
https://tools.ietf.org/id/draft-campagna-tls-bike-sike-hybrid-05.html#name-key-exchange-algorithms

---

From: David Benjamin <[email-masked]>
Date: Wed, 16 Sep 2020 12:47:42 -0400

"Variable-length" and "secret" don't really go together in the same
sentence, as your work demonstrates. I would actually go further and strike
that text altogether. I don't think it needs to be an open question. That
lets us stick with a simple construction.

While the public values aren't secret so there's less strong of a
guarantee, I'd go even further to drop the length prefixes inside
the HybridKeyExchange structure. That saves four bytes on the wire. If
someone does want to allocate a codepoint that needs the length prefixes,
they can always define it for that code point. (That's another nice thing
about using separate code points for separate hybrids rather than generic
crypto combinators. We don't have to design for every improbable
possibility.)

I will note, we did have variable-width public values in DHE, but that
caused interop issues and we fixed it in
https://github.com/tlswg/tls13-spec/pull/458.

David

On Wed, Sep 16, 2020 at 12:27 PM Nimrod Aviram <[email-masked]>
wrote:

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

---

From: David Benjamin <[email-masked]>
Date: Wed, 16 Sep 2020 12:56:59 -0400

> crypto combinators. We don't have to design for every improbable

I see the draft mentions SIKE having both compressed and uncompressed
variants as a justification, but that's not a reason for variable-length
public values. Any TLS code point using such a KEM should pick a particular
encoding so there's just the one mode, in the same way that ECDH keys have
both compressed and uncompressed encodings, but RFC8446 picks a single
format. (https://tools.ietf.org/html/rfc8446#section-4.2.8.2) Allowing both
means we either need a negotiation (so they should have been separate code
points), or we end up with a giant interop and complexity mess.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 16 Sep 2020 20:28:46 +0300

> in case other KEMs are used in the future.

Searching for newest available versions of finalists/alternates
specifications, all have constant output lengths except Kyber (usually
32 octets, but HQC uses 64, and FrodoKEM and SIKE use 16 at Cat1 and 24
at Cat3).

Kyber is a bit odd case. The spec uses raw XOF output as key, and the
specification does not seem to say anywhere how long the output should
be. The reference implementation always uses 32 octets as output
length.

So none of the finalists/alternates need variable-length secret fields.
And with TLS 1.3, due to the way secret is injected into key schedule,
a length field would only be strictly needed for injectivity if there
are multiple variable-length subkeys.

And with regards to TLS 1.2, I would just leave it. Adding PQC to TLS
1.2 is harder than adding PQC to TLS 1.3 (this is definitely not one
of those "old versions for free" cases), and TLS 1.2 is pretty much
obsolete anyway.

-Ilari

---

From: Douglas Stebila <[email-masked]>
Date: Thu, 17 Sep 2020 10:12:37 -0400

Given that all the finalists and alternate candidates have fixed
length shared secrets, and your observations on the potential for
timing attacks, I'm fine with dealing with only fixed length secrets,
removing the paragraph discussing the possibility for variable-length
shared secrets from the TLS 1.3 hybrid KEX draft, and adding a note
regarding the risks as identified by the Raccoon attack.

Douglas

On Wed, Sep 16, 2020 at 12:27 PM Nimrod Aviram <[email-masked]> wrote:
> "Variable-length shared secrets ... if it is envisioned that this specification
> [1] https://www.ietf.org/id/draft-ietf-tls-hybrid-design-00.html#name-open-questions
> [4] https://tools.ietf.org/id/draft-campagna-tls-bike-sike-hybrid-05.html#name-key-exchange-algorithms
>
>

---

From: Nimrod Aviram <[email-masked]>
Date: Fri, 18 Sep 2020 12:04:05 +0300

Sounds good to me.
I'm happy to send a PR making these changes, but couldn't find the
repository for the document.
Could you please point me to it?

best,
Nimrod

---

From: Nimrod Aviram <[email-masked]>
Date: Fri, 25 Sep 2020 11:47:38 +0300

Thanks!
The PR is here, happy to hear comments and corrections:
https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/1

best,
Nimrod

---

From: Douglas Stebila <[email-masked]>
Date: Fri, 25 Sep 2020 10:16:01 -0400

Thanks!  I've merged it in.

On Fri, Sep 25, 2020 at 4:48 AM Nimrod Aviram <[email-masked]> wrote:
>> I'm happy to send a PR making these changes, but couldn't find the repository for the document.