Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites

[Martin Thomson <[e-mail]>]

On Tue, Aug 18, 2020, at 07:55, Christopher Patton wrote:
> Hi Martin, 
>  
> > Or maybe just running the HPKE KDF with a fixed input.
> Do you mean something like this? Let `config_digest = KDF.extract("some 
> salt", "some label", config)`, where `config` is the ECH configuration?

Sure.  I would probably use all of HKDF though, see below.

> > Unless I've missed something critical, you don't need any sort of 
> preimage resistance for this, it's only for identification purposes.
> The manner in which `config_digest` is computed could be significant to 
> "don't stick out", depending on how you define this property. For 
> example, one requirement for the hash function might be that it is 
> one-way.

So the current system has the property that anyone in possession of the original config can confirm that this is the config in use.  And we have assumed that the config does not contain secrets.

Being unable to recover one input seems to be a KDF property.  We could feed config to that input (for the full HKDF, that would be IKM, I think).  See definition 7 in https://eprint.iacr.org/2010/264.pdf, which supports the theory that a KDF is a PRF with respect to at least one input (\sigma in the same).

I think that the only case where being able to compute the inverse becomes interesting is if the config contains a secret.  Let's say that you use a config that includes a PSK.  The answer there could just be "don't do that then".  Or we could work something out (for example, a nonce of sufficient length might ensure that a secret could not be reconstructed even if everything else were predictable).