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).
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
