On Tue, Nov 25, 2025 at 4:06 PM Benjamin Kaduk <bkaduk= [email protected]> wrote:
> # Ben Kaduk's review of draft-ietf-tls-mlkem-05 > CC @kaduk > > I do not support publication of this document at this time; see the > "discuss" points for specific items that IMO should be blocking. (I'm not > an AD anymore, of course, so they aren't actually blocking just because I > think they should be, but this is a handy review template...) > > ## Discuss > > ### KeyShare semantics > > In §4.2 when we write > > > The KeyShareClientHello includes a list of KeyShareEntry structs that > represent the key establishment algorithms the client supports. For each > parameter of ML-KEM the client supports, the corresponding KeyShareEntry > consists of a NamedGroup that indicates the appropriate parameter, and a > key_exchange value that is the pk output of the KeyGen algorithm. > > that misrepresents the semantics of the "key_share" extension (and I > assume we are not attempting to redefine core TLS 1.3 semantics). > "key_share" contains cryptographic parameters but makes no indication about > algorithms that the client (or server) supports -- that role is fulfiled by > "supported_groups". > Oh, good catch. Is there a reason that this paragraph should exist at all? Don't the grafs below starting with "For the ..." carry all the information you need to know? In fact, I think we could omit most of this section, because it's just redundant with RFC 8446. > (It's also a bit strange to have prose describing what KeyShareClientHello > contains without corresponding prose about the KeyShareServerHello, but > since we're not actually redefining what TLS 1.3 says I guess we don't need > to. But by that measure we don't need to have prose about > KeyShareClientHello, either.) > Agreed. It's just an opportunity for confusion. ## Comments > > ### Presumption of migrating beyond hybrids > > In §1.1 we note that "Having a purely post-quantum (not hybrid) key > establishment option for TLS 1.3 is necessary for migrating beyond hybrids > and for users that want or need post-quantum security without hybrids" > which is true if we presuppose that there is a need to migrate beyond > hybrids and user desire to achieve post-quantum security without hybrids, > but does not really justify those presuppositions. I think we should try > to avoid value judgements (which may be hard to achieve consensus on), and > thus that we should rather say something like "This document defines > key-establishment options for TLS 1.3 that use solely post-quantum > algorithms, without a hybrid construction that also includes a traditional > cryptographic algorithm". > I concur with Ben. This seems like a much more straightforward factual statement. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
