Thanks! I've merged it in. On Fri, Sep 25, 2020 at 4:48 AM Nimrod Aviram <nimrod.avi...@gmail.com> wrote: > > 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
