Spec assumes HPKE uses HKDF

[cjpatton]

From Section 6.1:

   When sending ClientHello, the client first computes ClientHelloInner,
   including any PSK binders, and then MAY substitute extensions which
   it knows will be duplicated in ClientHelloOuter.  To do so, the
   client computes a hash H of the entire ClientHelloInner message with
   the same hash as for the KDF used to encrypt ClienHelloInner.  Then,
   the client removes and and replaces extensions from ClientHelloInner
   with a single "outer_extensions" extension.  The list of
   outer_extensions include those which were removed from
   ClientHelloInner, in the order in which they were removed.  The hash
   contains the full ClientHelloInner hash H computed above.

This assumes that the KDF specifies some underlying hash function. From the HPKE spec, it seems like all that's required of the KDF is that it's an "extract-then-expand" KDF: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-05#section-4

In fact, the currently assigned code points are all for HKDF: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-05#section-7.2

But there's no requirement that the KDF always have some underlying hash function. As an alternative to HKDF, one can imagine a dedicated primitive that satisfies the extract-then-expand API but is not constructed from a hash function.

[cjpatton]

Impacted fields:

• ClientEncryptedCH.record_digest
• OuterExtensions.hash

[chris-wood]

We can probably replace Hash with Extract and be done with it.

[cjpatton]

Putting on my theorist hat, I'd say that the extract function is a "randomness extractor" and not a collision resistant hash function. We want the latter in this context. From a practical stand point, using the extract function is more hashing than we need.

I'd suggest doing away with OuterExtensions.hash (see #263) and figuring something else out for ClientEncryptedCH.record_digest. Could we simply require HKDF be used with HPKE?

[chris-wood]

Sure, but in practice randomness extractors use a collision resistant hash or PRF (CBC) under the hood.

I don't think we can require HKDF for HPKE. That seems too restrictive. We might just say that ECH requires HKDF-based HPKE ciphersuites, as HKDF is already paramount for TLS 1.3, and then just reference HKDF's hash function.

[cjpatton]

271 addresses this issue.

[martinthomson]

As I mentioned on the list, we can use the KDF in place of a hash.

[cjpatton]

I tend to agree. I'll create a new PR.

[cjpatton]

Have a look at #276, @martinthomson!

[chris-wood]

Resolved in #276. Closing.