On Fri, Mar 29, 2024 at 1:42 PM Deirdre Connolly <durumcrustu...@gmail.com> wrote:
> > 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, > I would probably rank order these as establishment > agreement > exchange, but I'm not going to argue about these. -Ekr > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
