Original text:
5.2. <del> A particular instance of a ratchet tree is based on the following cryptographic primitives, defined by the ciphersuite in use: </del>  <del> An HPKE ciphersuite, which specifies a Key Encapsulation Mechanism (KEM), an AEAD encryption scheme, and a hash function </del>  <del> A Derive-Key-Pair function that produces an asymmetric key pair for the specified KEM from a symmetric secret </del>  Each node in a ratchet tree contains up to five values: Each MLS session uses a single ciphersuite that specifies the following primitives to be used in group key computations: <del> A hash function </del>  <del> A key encapsulation mechanism (KEM) </del>  <del> An AEAD encryption algorithm </del>  A signature algorithm <del> The ciphersuite's KEM used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption.  Each ciphersuite has a "Derive-Key-Pair" function that maps octet strings of length "Nsk" (a KEM-specific constant defined by HPKE) to HPKE key pairs. This function is defined to be HPKE's "DeriveKeyPair" function. </del>  Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying protocol 7.8. <del> Group keys are derived using the HKDF-Extract and HKDF-Expand functions as defined in RFC5869, as well as the functions defined below: </del>  <del> The Hash function used by HKDF is the ciphersuite hash algorithm. Hash.length is its output length in bytes.  In the below diagram: </del>  <del> HKDF-Extract takes its salt argument from the top and its IKM </del>  argument from the left <del> Derive-Secret takes its Secret argument from the incoming arrow </del>  When processing a handshake message, a client combines the following information to derive new epoch secrets: each key/nonce pair MUST NOT be used to encrypt more than one message. <del> Keys, nonces and secrets of ratchets are derived using Derive-App- Secret.  The context in a given call consists of the index of the sender's leaf in the ratchet tree and the current position in the ratchet.  In particular, the index of the sender's leaf in the </del>  ratchet tree is the same as the index of the leaf in the AS Tree used to initialize the sender's ratchet. The context used for the derivation of the "exported_value" MAY be empty while each application SHOULD provide a unique label as an <del> input of the HKDF-Expand-Label for each use case.  This is to prevent </del>  two exported outputs from being generated with the same values and used for different functionalities. the definition of application_secret.) The secret of any other node in the tree is derived from its parent's <del> secret using a call to Derive-App-Secret. </del>  If N is a node index in the AS Tree then the secrets of the children of N are defined to be: S was used to encrypt or (successfully) decrypt a message, or if a key, nonce, or secret derived from S has been consumed.  (This <del> goes for values derived via Derive-Secret as well as HKDF-Expand- Label.) </del>  Here, S may be the "init_secret", "commit_secret", "epoch_secret", "application_secret" as well as any secret in the AS Tree or one of These ciphersuites map to HPKE primitives and TLS signature schemes as follows I-D.irtf-cfrg-hpke RFC8446: <del> The hash used for HKDF computations in MLS is the same hash used in the HPKE KDF for the ciphersuite. </del> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment, therefore the ciphersuites only inlcude modern, yet well-established

Reviewer comments:
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Our HPKE dependency provides a perfectly usable KDF. We should just use that instead of nailing a dependency to HKDF. This will mainly be a matter of changing and calls to the corresponding calls on the HPKE KDF.
I can't wait to see the implementations.
Thanks for the enthusiasm, but I don't think this is a spec issue :)

Revised text:
5.2.  <ins> A particular instance of a ratchet tree is defined by the same parameters that define an instance of HPKE, namely: </ins>  <ins> A Key Encapsulation Mechanism (KEM), including a "DeriveKeyPair" function that creates a key pair for the KEM from a symmetric secret </ins>  <ins> A Key Derivation Function (KDF), including "Extract" and "Expand" functions An AEAD encryption scheme </ins> Each node in a ratchet tree contains up to five values: Each MLS session uses a single ciphersuite that specifies the following primitives to be used in group key computations:  <ins> HPKE parameters: A Key Encapsulation Mechanism (KEM) </ins>  <ins> A Key Derivation Fucntion (KDF) </ins>  <ins> An AEAD encryption algorithm </ins> A signature algorithm  <ins> The HPKE parameters are used to instantiate HPKE I-D.irtf-cfrg-hpke for the purpose of public-key encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying protocol 7.8.  <ins> Group keys are derived using the "Extract" and "Expand" functions from the KDF for the group's ciphersuite, as well as the functions defined below: </ins>  <ins> The value "KDF.Nh" is the size of an output from "KDF.Extract", in bytes.  In the below diagram: </ins>  <ins> KDF.Extract takes its salt argument from the top and its IKM </ins> argument from the left  <ins> DeriveSecret takes its Secret argument from the incoming arrow </ins> When processing a handshake message, a client combines the following information to derive new epoch secrets: each key/nonce pair MUST NOT be used to encrypt more than one message.  <ins> Keys, nonces and secrets of ratchets are derived using DeriveAppSecret.  The context in a given call consists of the index of the sender's leaf in the ratchet tree and the current position in the ratchet.  In particular, the index of the sender's leaf in the </ins> ratchet tree is the same as the index of the leaf in the AS Tree used to initialize the sender's ratchet. The context used for the derivation of the "exported_value" MAY be empty while each application SHOULD provide a unique label as an  <ins> input of the ExpandWithLabel for each use case.  This is to prevent </ins> two exported outputs from being generated with the same values and used for different functionalities. the definition of application_secret.) The secret of any other node in the tree is derived from its parent's  <ins> secret using a call to DeriveAppSecret. </ins> If N is a node index in the AS Tree then the secrets of the children of N are defined to be: S was used to encrypt or (successfully) decrypt a message, or if a key, nonce, or secret derived from S has been consumed.  (This  <ins> goes for values derived via DeriveSecret as well as ExpandWithLabel.) </ins> Here, S may be the "init_secret", "commit_secret", "epoch_secret", "application_secret" as well as any secret in the AS Tree or one of These ciphersuites map to HPKE primitives and TLS signature schemes as follows I-D.irtf-cfrg-hpke RFC8446:  It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment, therefore the ciphersuites only inlcude modern, yet well-established