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

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