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

From: "Christopher Wood" <[email-masked]>
Date: Mon, 17 Aug 2020 14:09:51 -0700

HPKE recently removed the Hash() interface from the KDF, which means we need to either (a) change how the config_digest (formerly record_digest) is computed, or (b) constrain ECH to HKDF-based HPKE ciphersuites. This PR takes approach (b):

   https://github.com/tlswg/draft-ietf-tls-esni/pull/271

Please have a look and provide feedback. 

Thanks,
Chris

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 18 Aug 2020 07:42:09 +1000

On Tue, Aug 18, 2020, at 07:09, Christopher Wood wrote:
> HPKE recently removed the Hash() interface from the KDF, which means we 
> need to either (a) change how the config_digest (formerly 
> record_digest) is computed, or (b) constrain ECH to HKDF-based HPKE 
> ciphersuites. This PR takes approach (b):
> 

Was there discussion about just defining a set of hash function identifiers and adding those to the config?

Or maybe just running the HPKE KDF with a fixed input.  Unless I've missed something critical, you don't need any sort of preimage resistance for this, it's only for identification purposes.

---

From: Christopher Patton <[email-masked]>
Date: Mon, 17 Aug 2020 14:55:37 -0700

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?

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.

Chris P.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 18 Aug 2020 08:30:18 +1000

> 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.
> "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).

---

From: Christopher Patton <[email-masked]>
Date: Mon, 17 Aug 2020 16:04:10 -0700

Just to be clear, you're proposing something like this? Referring to the
KDF API called for in draft-irtf-cfrg-hpke-05:

config_digest = Expand(PRK=Extract("some_salt", "some_label", IKM=config),
"some_info", 16)
It's maybe more hashing than necessary, but I'd be good with this.

Chris P.

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 17 Aug 2020 16:05:40 -0700

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

If we're going to use all of HKDF (extract + expand), then let's just use the HPKE's Extract+Expand functions in sequence. 

Best,
Chris

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 18 Aug 2020 09:27:39 +1000

On Tue, Aug 18, 2020, at 09:04, Christopher Patton wrote:
> Just to be clear, you're proposing something like this? Referring to 
> the KDF API called for in draft-irtf-cfrg-hpke-05:
> 
> config_digest = Expand(PRK=Extract("some_salt", "some_label", 
> IKM=config), "some_info", 16)

Something like that yeah.  And yes, that's a lot of hashing.  But that's a lower-order concern.  Maybe if we try to find a KDF that doesn't cost so much to operate we won't feel so bad about this.

---

From: Christopher Patton <[email-masked]>
Date: Mon, 17 Aug 2020 16:57:36 -0700

I worked out this suggestion into a PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/276

Please have a look!
Chris P.

On Mon, Aug 17, 2020 at 4:28 PM Martin Thomson <[email-masked]> wrote:

> Something like that yeah.  And yes, that's a lot of hashing.  But that's a
> lower-order concern.  Maybe if we try to find a KDF that doesn't cost so
> much to operate we won't feel so bad about this.
>