Fix issues introduced in #114 about mls-protocol

[kkohbrok]

That was exactly the question I was asking on the list, i.e., if we need an explicit "derive-keypair" function. The idea with deriving the private key directly was to avoid a redundant derive-key operation. I'm totally fine re-doing the PR to represent either approach.

[beurdouche]

Merging that PR too quickly is on me.
For the parent derivation, we can just use what the formal model for TreeKEM does, which is roughly the HKDF_Expand_Label Richard points out. The part I don't like about this, is to define Derive-Key-Pair in the MLS specification as it depends on the HPKE internal algorithm.

The TreeKEM formal specification, it is done the following way (because we know that the HPKE interface we use can take random bytes as a secret key):

(** Key Derivation: compute a parent secret from the group secret *)
val derive_parent_secret: alg:algorithm_hash -> context:bytes -> secret_s -> Tot secret_s
let derive_parent_secret alg context s =
  Spec.HKDF.hkdf_expand_label alg s "parent" context size_secret

(** Key Derivation: compute a KEM encryption key from the group secret *)
val derive_encryption_secret: alg:algorithm_hash -> context:bytes -> secret_s -> Tot key_secret_s
let derive_encryption_secret alg context s =
  Spec.HKDF.hkdf_expand_label alg s "kem enc" context size_key_secret

In the MLS specification, I suggest we avoid defining anything new but point to the HPKE spec instead.
As it provides the KEM scheme, it should also provide ways to derive the HPKEPrivateKey from an octet string and the function that transform an HPKEPrivateKey to a HPKEPublicKey.
I suggest we define, in the HPKE document, something like HPKE_secret_to_public () that we already need anyway and eventually HPKE_bytes_to_secret () that maps the random bytes to an HPKEPrivateKey. For X25519 we don't even need the second function but generically we probably need it.
That would lead to define the following in the MLS spec:

(** Key Derivation: compute a KEM encryption key from the group secret *)
val mls_derive_encryption_secret: alg:algorithm_hash -> context:bytes -> secret_s -> Tot key_secret_s
let mls_derive_encryption_secret alg context s =
  let output = Spec.HKDF.hkdf_expand_label alg s "kem enc" context size_key_secret in
  Spec.HPKE.bytes_to_secret alg output

@bifurcation ?

[bifurcation]

I don't think we can delegate this to HPKE. HPKE doesn't have a need for anything like Derive-Key-Pair. We do, so it's on us to define it. The point @kkohbrok's raises about avoiding unnecessary operations is relevant here: If we're forking the hashes like this, then we can remove the hashing part from Derive-Key-Pair, so that it's really just a definition of how you convert from an octet string to a private key (and thus its public key).

[beurdouche]

I disagree, it is not for MLS to define the bytes_to_secret and secret_to_public functions for all asymmetric schemes possibly used in HPKE. In MLS we should have to do only what TreeKEM does, aka, 2 KDFs, one outputing the parent's secret, one outputing the KEM encryption key, and that's it.
I am willing to accept defining Derive-Public-Key here but this is already odd.

[bifurcation]

If it's not our job, whose is it? It's not HPKE's job, because they don't have a need to convert byte strings to private keys. Some document needs to define this conversion in order for MLS to be implementable.

[beurdouche]

I agree we are in trouble here :) But I still wish that if we can avoid it, we should.

[bifurcation]

I agree that the KEM schemes themselves should define these things, like Curve25519 does. But it's like two lines of text. I'm not too bothered with it.

[kkohbrok]

I think I'm a bit lost here. How do we go forward?

Regarding the use of an abstract KDF: I was mostly just adapting the existing text, which used an abstract hash function if I recall correctly. I didn't touch the texts that got more concrete because they seemed to be a little outdated anyway. That shouldn't be a problem though.

[beurdouche]

@bifurcation Ok, looking at this now, I am not sure what we decided in the end.
I would be ok to define Derive-Key-Pair as you said but as it is KEM specific so there is no good solution for P256 or for whatever PQ KEM that would have a specific way of generating keys from pseudo random bytes...

[beurdouche]

@karthikbhargavan any suggestion here

[beurdouche]

Fixed by #139