Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

On Fri, Mar 29, 2024 at 1:42 PM Deirdre Connolly <durumcrustulum@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 <housley@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 <sean@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
>