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

On Wed, Sep 16, 2020 at 12:47 PM David Benjamin <davidben@chromium.org>
wrote:

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

> 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 <nimrod.aviram@gmail.com>
> wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>