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 <doug...@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.avi...@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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
