On Wed, Sep 16, 2020 at 12:47 PM David Benjamin <david...@chromium.org> wrote:
> "Variable-length" and "secret" don't really go together in the same > sentence, as your work demonstrates. I would actually go further and strike > that text altogether. I don't think it needs to be an open question. That > lets us stick with a simple construction. > > While the public values aren't secret so there's less strong of a > guarantee, I'd go even further to drop the length prefixes inside > the HybridKeyExchange structure. That saves four bytes on the wire. If > someone does want to allocate a codepoint that needs the length prefixes, > they can always define it for that code point. (That's another nice thing > about using separate code points for separate hybrids rather than generic > crypto combinators. We don't have to design for every improbable > possibility.) > I see the draft mentions SIKE having both compressed and uncompressed variants as a justification, but that's not a reason for variable-length public values. Any TLS code point using such a KEM should pick a particular encoding so there's just the one mode, in the same way that ECDH keys have both compressed and uncompressed encodings, but RFC8446 picks a single format. (https://tools.ietf.org/html/rfc8446#section-4.2.8.2) Allowing both means we either need a negotiation (so they should have been separate code points), or we end up with a giant interop and complexity mess. > I will note, we did have variable-width public values in DHE, but that > caused interop issues and we fixed it in > https://github.com/tlswg/tls13-spec/pull/458. > > David > > 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
