Is this document going to define how ephemeral hybrid shares are generated?

[dconnolly]

For example, do I create a single random seed, split it, and feed half to X25519 keygen and the other half to Kyber768 keygen? Do each component scheme just do everything independently? The document as it stands would allow me to do both and be compliant.

[bwesterb]

Either is fine, and I do not see a reason to mandate one of them. But I could be missing something.

An aside: HPKE does require KEMs to specify their keygen explicitly, and so we do for the hybrid there in section 3.3.

[dconnolly]

Defining something is better than nothing, as someone may come up with some other deranged scheme because it was never written down; that DeriveKeyPair is pretty great

[bwesterb]

Most APIs won't allow you to pass the seed: the obvious thing to do then is simply call keygen for both separately, and that's perfectly fine. That is how BoringSSL does it. If we mandate a certain way to generate both components, we'd have to complicate that simple approach.

[dconnolly]

Fair enough, can that be made explicit? X25519Kyber768Draft00.KeyGen() = (X25519.KeyGen(), Kyber768.keyGen()) or similar

[bwesterb]

draft-ietf-tls-hybrid-design, of which this is an instantiation writes

   [TLS13] requires that ``The key_exchange values for each
   KeyShareEntry MUST be generated independently.'' In the context of
   this document, since the same algorithm may appear in multiple named
   groups, we relax the above requirement to allow the same key_exchange
   value for the same algorithm to be reused in multiple KeyShareEntry
   records sent in within the same ClientHello.  However, key_exchange
   values for different algorithms MUST be generated independently.

Is that satisfactory or too implicit?

[dconnolly]

draft-ietf-tls-hybrid-design, of which this is an instantiation writes

   [TLS13] requires that ``The key_exchange values for each
   KeyShareEntry MUST be generated independently.'' In the context of
   this document, since the same algorithm may appear in multiple named
   groups, we relax the above requirement to allow the same key_exchange
   value for the same algorithm to be reused in multiple KeyShareEntry
   records sent in within the same ClientHello.  However, key_exchange
   values for different algorithms MUST be generated independently.

Is that satisfactory or too implicit?

I will probably submit suggestions to clarify that language in draft-ietf-tls-hybrid-design too (one can possibly read 'independently' and 'different algorithms' to include the hybrid one, too), but I think it should be made explicit: in the X25519Kyber758Draft00 instantiation, this means X25519Kyber758Draft00.KeyGen() = (X25519.KeyGen(), Kyber758.KeyGen()) every time, although the invocation of each component scheme may have been done once and the resulting values used in multiple KeyShareEntrys in one ClientHello. The way it currently stands, the only component value likely to be in multiple KeyShareEntrys is X25519, not Kyber758, so maybe making it explicit that that is an acceptable implementation of this document would be helpful.

[dconnolly]

draft-ietf-tls-hybrid-design, of which this is an instantiation writes

   [TLS13] requires that ``The key_exchange values for each
   KeyShareEntry MUST be generated independently.'' In the context of
   this document, since the same algorithm may appear in multiple named
   groups, we relax the above requirement to allow the same key_exchange
   value for the same algorithm to be reused in multiple KeyShareEntry
   records sent in within the same ClientHello.  However, key_exchange
   values for different algorithms MUST be generated independently.

Is that satisfactory or too implicit?

I will probably submit suggestions to clarify that language in draft-ietf-tls-hybrid-design too (one can possibly read 'independently' and 'different algorithms' to include the hybrid one, too), but I think it should be made explicit: in the X25519Kyber758Draft00 instantiation, this means X25519Kyber758Draft00.KeyGen() = (X25519.KeyGen(), Kyber758.KeyGen()) every time, although the invocation of each component scheme may have been done once and the resulting values used in multiple KeyShareEntrys in one ClientHello. The way it currently stands, the only component value likely to be in multiple KeyShareEntrys is X25519, not Kyber758, so maybe making it explicit that that is an acceptable implementation of this document would be helpful.

(Not ignoring the KEMTLS work but you know)

[bwesterb]

Ok, let me know when it lands in hybrid-design, and then we can add an appropriate remark here.