dstebila / draft-ietf-tls-hybrid-design Goto Github PK

Florence D asked:
There are several points in the draft where properties of, or restrictions on KEMs, are mentioned but it's not clear whether this applies to all KEMs, just to the next-generation KEMs, or just to the NIST Round 3 candidates. I think it's important to clarify this, drawing a distinction between post-quantum and classical KEMs (specifically FFDH and ECDH modelled as KEMs) as well as between general next-generation KEMs and the NIST Round 3 candidates.

We should address it; however it's not clear how - (EC)DH does not satisfy the CCA assumptions currently in the draft, and I can't immediately think how to address the CDH assumptions they do exhibit...

(Filing this so we don't lose track of the other issue from the TLSWG thread.)

Section 3.2 defines a HybridKeyExchange structure with length prefixes and justifies it by saying:

However we do add structure in the concatenation procedure, specifically including length fields, so that the concatenation operation is unambiguous. Note that among the Round 2 candidates in the NIST Post-Quantum Cryptography Standardization Project, not all algorithms have fixed public key sizes; for example, the SIKE key encapsulation mechanism permits compressed or uncompressed public keys at each security level, and the compressed and uncompressed formats are interoperable.

This justification, particularly the example, doesn't hold. While SIKE permits both compressed or uncompressed public keys, any TLS code point would need to pick one or the other (see RFC8446). Once the form is picked, I believe it is fixed-width.

Unlike #1, there isn't an immediate security flaw with variable-length public keys, but I also would consider it a sign of a poorly-specified primitive. We've seen elsewhere that such designs lead to interop issues (e.g. tlswg/tls13-spec#458), as well as general implementation complexity. (Anecdotally, every time I review code that uses ECDSA, I find a mistake in handling the variable-length signature encoding.)

Additionally, one of the benefits of switching this design to the simpler separate codepoints model is to avoid a lowest common denominator problem. The specification could say to concatenate them, note that this requires fixed-length public keys (which is true in practice), and then mention in passing that if anyone does try to hybridize a variable-length algorithm, they can introduce length prefixes for just that code point. (And then in standardization we'll correct the flaw in the primitive, so no one ever needs to implement it! 😉)

I don't know how to do this...

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf

The reference to [HOFFMAN] in the appendix should be removed: it is a dead document.

FIPS 202 is mentioned without a reference. It might also be good to say that this is actually talking about SHA-3.

Related: It might be better to say "SHA-3" instead of Keccak in the document.