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

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

On Thu, 17 Sep 2020 at 17:12, Douglas Stebila <douglas@stebila.ca> wrote:

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