Thanks! The PR is here, happy to hear comments and corrections: https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/1
best, Nimrod On Fri, 18 Sep 2020 at 12:04, Nimrod Aviram <nimrod.avi...@gmail.com> wrote: > 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
