> KEMs are not "key agreement" algorithms as suggested by this draft name. In a key agreement algorithm, both parties contribute to the shared secret. With a KEM, only one party generates the the shared secreat value.
This is not generally accurate with the KEM schemes under consideration for adoption by any standards bodies: in the -hybrid-design and -mlkem-key-agreement documents, the `Client` generates an ephemeral keypair, and the `Server` encapsulates to that keypair, but especially in ML-KEM which is under consideration in both documents, the KEM randomly sampled message `m` is sampled by the `Server` but the final `shared_secret` resulting from `Encaps` and `Decaps` is based on computing over the message `m`, the public key `PK` generated by the `Client`, as well as the randomized ciphertext `CT` generated by the `Server`. The encapsulated message `m` is not actually the `shared_secret` that is the input to the TLS 1.3 key schedule, even independent of the entire handshake transcript being included into the full key schedule as well. The naming of the document excluded 'key exchange' and 'key establishment', and went with 'key agreement', but that is a weakly held name, On Thu, Mar 28, 2024 at 5:08 PM Russ Housley <hous...@vigilsec.com> wrote: > Sean: > > I observe that ML-KEM is not a Elliptic curve group or a Finite Field > Diffie-Hellman group. I really think we want to include sepport for KEMs. > but a separate range is needed. I assume it will be carved out of the > Elliptic curve group range. > > KEMs are not "key agreement" algorithms as suggested by this draft name. > In a key agreement algorithm, both parties contribute to the shared > secret. With a KEM, only one party generates the the shared secreat value. > > Russ > > > On Mar 28, 2024, at 10:52 AM, Sean Turner <s...@sn3rd.com> wrote: > > > > <author hat> > > > > **WARNING: Potential bikeshed** > > > > -connolly-tls-mlkem-key-agreement has suggested that code points for the > NIST PQ be registered in the TLS Supported Groups IANA registry [1]. > Currently [2], the registry is carved up into three blocks as follows: > > > > Range: 0-255, 512-65535 > > Registration Procedures: Specification Required > > Note: Elliptic curve groups > > > > Range 256-511 > > Registration Procedures: Specification Required > > Note: Finite Field Diffie-Hellman groups > > > > Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the > path for PQ KEM algorithms (and maybe regardless of whether this is the > path), we should really replace the “Elliptic curve groups” note in the > 0-255, 512-65535 range row with something else. I am open to suggestions, > but would like to propose “unallocated”. I have submitted the following > issue: > > https://github.com/tlswg/rfc8447bis/issues/54 > > and this PR: > > https://github.com/tlswg/rfc8447bis/pull/55 > > to address this. > > > > spt > > > > [1] > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 > > > > [2] Originally, RFC 8442 defined the name of the registry as "EC Named > Curve Registry” and then RFC 7919 re-named it “Supported Groups” and carved > out the FFDH space. > > _______________________________________________ > 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
