Subject: [TLS] [ECH] Reverting the config ID change

From: "Christopher Wood" <[email-masked]>
Date: Mon, 08 Feb 2021 14:29:20 -0800

We previously had a server-selected label for the ECHConfig, but that has since been replaced with a client-computed identifier. There are a couple of problems with this change in practice (see [1]), so the following PR proposes reverting back to the old behavior: 

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

There is a separate issue [2] regarding the length of this identifier, but we can address that separately.

Please have a look at the PR and provide feedback. We'd like to merge this soon. 

Thanks,
Chris

[1] https://github.com/tlswg/draft-ietf-tls-esni/issues/375
[2] https://github.com/tlswg/draft-ietf-tls-esni/issues/379

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 16 Feb 2021 05:43:32 -0800

On the heels of this change, here's another PR that I'd folks to weigh in on:

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

Thanks,
Chris

On Mon, Feb 8, 2021, at 2:29 PM, Christopher Wood wrote:
> We previously had a server-selected label for the ECHConfig, but that 
> has since been replaced with a client-computed identifier. There are a 
> couple of problems with this change in practice (see [1]), so the 
> following PR proposes reverting back to the old behavior: 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 16 Feb 2021 09:29:24 -0500

I find the language around "optional" configuration identifiers confusing
here.  Both of these proposals require ECHConfig to specify an identifier,
and both of them require the client to transmit one, so it doesn't seem
very "optional".  I think the point is that special case usage profiles are
permitted in which the client ignores the indicated ID and substitutes a
different one.  Given that that is arranged by mutual agreement outside of
the protocol, I'm not sure why it needs to be mentioned in the draft, but
if it's going to be included, I hope we can find a clearer presentation.

Substantively, this seems fine to me..

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Feb 2021 13:02:27 -0800

I am not in favor of shrinking this to a single byte, as it significantly
limits future flexibility.

As far as I can tell, the argument here is to limit the entropy available
for tracking, but recall that in this case the attacker controls the DNS
and they can (for instance) provide a unique IPv6 address, so this doesn't
see, like a good tradeoff.

-Ekr

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 16 Feb 2021 13:31:40 -0800

On Tue, Feb 16, 2021, at 1:02 PM, Eric Rescorla wrote:
> I am not in favor of shrinking this to a single byte, as it 
> significantly limits future flexibility.
> 
> As far as I can tell, the argument here is to limit the entropy 
> available for tracking, but recall that in this case the attacker 
> controls the DNS and they can (for instance) provide a unique IPv6 
> address, so this doesn't see, like a good tradeoff.

That's true, but I'd personally prefer one tracking vector to two. This structure also better aligns with other proposed use cases for HPKE configurations. I also don't see an immediate need for flexibility in this value given that there are extensions in ECHConfigContents already.

That said, my primary goal here is consistency. I'd be happy with whatever outcome provided that it's usable in other contexts where we need HPKE configurations, Oblivious DoH being one of them. 

Best,
Chris

> 
> -Ekr
> 
> 
> On Tue, Feb 16, 2021 at 5:44 AM Christopher Wood <[email-masked]> wrote:

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 17 Feb 2021 10:00:45 +1100

On Wed, Feb 17, 2021, at 08:31, Christopher Wood wrote:
> That's true, but I'd personally prefer one tracking vector to two. This 
> structure also better aligns with other proposed use cases for HPKE 
> configurations. I also don't see an immediate need for flexibility in 
> this value given that there are extensions in ECHConfigContents already.

I don't see the tracking angle as relevant here.  The only things that might matter is size, collision probability (for greasing), and consistency.  Size doesn't matter, because it's a handful of bytes at most; collisions matter little because the cost is a resource the server is prepared to spend anyway; consistency with something that can also change isn't worth much.

The primary argument I would have in support of this is YAGNI.  The number of active keys should be much smaller than 256, and there's a slot for extensions should that need arise.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Feb 2021 15:33:38 -0800

On Tue, Feb 16, 2021 at 3:01 PM Martin Thomson <[email-masked]> wrote:

> I don't see the tracking angle as relevant here.  The only things that
> might matter is size, collision probability (for greasing), and
> consistency.  Size doesn't matter, because it's a handful of bytes at most;
> collisions matter little because the cost is a resource the server is
> prepared to spend anyway; consistency with something that can also change
> isn't worth much.
>
> The primary argument I would have in support of this is YAGNI.  The number
> of active keys should be much smaller than 256, and there's a slot for
> extensions should that need arise.
>

I don't find YAGNI that persuasive in this case. It's not significant extra
complexity to have this field bigger and it basically makes it impossible
to have any structure.

-Ekr

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 16 Feb 2021 16:21:46 -0800

>  It's not significant extra complexity to have this field bigger and it basically makes it impossible to have any structure.

What do you mean by structure? How does a byte not provide sufficient "structure"?

> On Feb 16, 2021, at 3:33 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Feb 16, 2021 at 3:01 PM Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> I don't find YAGNI that persuasive in this case. It's not significant extra complexity to have this field bigger and it basically makes it impossible to have any structure.
> 
> -Ekr
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Feb 2021 00:30:54 +0000

Hiya,

On 16/02/2021 21:31, Christopher Wood wrote:
> That's true, but I'd personally prefer one tracking vector to two.
> This structure also better aligns with other proposed use cases for
> HPKE configurations. I also don't see an immediate need for
> flexibility in this value given that there are extensions in
> ECHConfigContents already.
FWIW, I think one octet is ok.

I'd prefer zero and forced trial decryption I think but
living with 1 is doable.

Yet another value to manage (a multi-octet server chosen
config id) or a client calculated value (as per -09) both
seem worse.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Feb 2021 16:34:02 -0800

On Tue, Feb 16, 2021 at 4:21 PM Carrick Bartle <[email-masked]>
wrote:

>  It's not significant extra complexity to have this field bigger and it
> basically makes it impossible to have any structure.
>
>

It's not long enough to encode much. As a concrete example, what if the
label is actually an encrypted version of the private key? Or you have a
distributed generation algorithm that you don't want to synchronize?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Feb 2021 16:34:52 -0800

On Tue, Feb 16, 2021 at 4:31 PM Stephen Farrell <[email-masked]>
wrote:

> config id)

How is it any harder to manage a multi-octet server-chosen value than a
single-octet server-chosen value?

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Feb 2021 00:44:42 +0000

> single-octet server-chosen value?

Easier for the library on the server side. If it's >1 octet
then someone will want some semantics. If ==1 then they'll
have to accept none and possible collisions so it can be
handled independently inside the library.

But as I said, I prefer zero which is even easier:-)

S.

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 16 Feb 2021 16:57:36 -0800

I see. It seems reasonable to me to leave it as a variable-length vector to provide flexibility. Since the best mitigation for the privacy issue, regardless of the length of the config_id, is to have a large anonymity set as described in Security and Privacy Goals, it doesn't seem like a longer config_id is, in all cases, a major privacy trade-off.

> On Feb 16, 2021, at 4:34 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Feb 16, 2021 at 4:21 PM Carrick Bartle <[email-masked] <mailto:[email-masked]>> wrote:
> It's not long enough to encode much. As a concrete example, what if the label is actually an encrypted version of the private key? Or you have a distributed generation algorithm that you don't want to synchronize?
> 
> -Ekr
>

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Feb 2021 17:01:37 -0800

The shorter ID was described as such: "significantly limits future
flexibility."

What "flexibility" is lost?

thanks,
Rob

On Tue, Feb 16, 2021 at 4:57 PM Carrick Bartle <cbartle891=
[email-masked]> wrote:

> I see. It seems reasonable to me to leave it as a variable-length vector
> to provide flexibility. Since the best mitigation for the privacy issue,
> regardless of the length of the config_id, is to have a large anonymity set
> as described in Security and Privacy Goals, it doesn't seem like a longer
> config_id is, in all cases, a major privacy trade-off.
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Feb 2021 08:00:00 -0800

> handled independently inside the library.

The server is free to enforce 1 byte.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Feb 2021 16:24:55 +0000

> The server is free to enforce 1 byte.

A server operator would be free to do that. The person
writing the code likely would not be as some server
operator would also be free to try impose semantics
on a multibyte field.

S.

---

From: Jonathan Hoyland <[email-masked]>
Date: Wed, 17 Feb 2021 16:35:03 +0000

I know that ECH doesn't provide security against probing attackers, but
such an attacker could easily maintain a list of active keys, and drop
connections using them.
If the key ID is very long, this would be highly effective at allowing
grease ECH connections, but blocking real ECH connections.

An adversary using this strategy against a one byte id would have high
collateral damage, but against an eight byte id would virtually none.

Providing some resistance to probing adversaries is a nice-to-have, even if
we can't provide complete protection.

My preference would be for a shorter id.

Regards,

Jonathan

---

From: Carrick Bartle <[email-masked]>
Date: Wed, 17 Feb 2021 09:41:18 -0800

Numerous ways a client can "stick out" have been identified, to the point where it's trivial to block connections using real ECH, regardless of the length of the config_id, which was why I thought we'd largely dropped the attempt not to stick out.

> On Feb 17, 2021, at 8:35 AM, Jonathan Hoyland <[email-masked]> wrote:
> 
> I know that ECH doesn't provide security against probing attackers, but such an attacker could easily maintain a list of active keys, and drop connections using them.
> If the key ID is very long, this would be highly effective at allowing grease ECH connections, but blocking real ECH connections.
> 
> An adversary using this strategy against a one byte id would have high collateral damage, but against an eight byte id would virtually none.
> 
> Providing some resistance to probing adversaries is a nice-to-have, even if we can't provide complete protection.
> 
> On Wed, 17 Feb 2021 at 16:25, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Tue, Feb 16, 2021 at 4:44 PM Stephen Farrell <[email-masked] <mailto:[email-masked]>>
> > wrote:
> > 
> >>
> >>

---

From: Jonathan Hoyland <[email-masked]>
Date: Wed, 17 Feb 2021 17:51:55 +0000

Being totally indistinguishable is probably impossible, but all else being
equal more resistance is better than less, no?

Regards,

Jonathan

On Wed, 17 Feb 2021 at 17:41, Carrick Bartle <[email-masked]> wrote:

> Numerous ways a client can "stick out" have been identified, to the point
> where it's trivial to block connections using real ECH, regardless of the
> length of the config_id, which was why I thought we'd largely dropped the
> attempt not to stick out.
>
>
>

---

From: Carrick Bartle <[email-masked]>
Date: Wed, 17 Feb 2021 09:59:45 -0800

Not if "more resistence" is still trivial.

> On Feb 17, 2021, at 9:51 AM, Jonathan Hoyland <[email-masked]> wrote:
> 
> Being totally indistinguishable is probably impossible, but all else being equal more resistance is better than less, no?
> 
> Regards,
> 
> Jonathan
> 
> On Wed, 17 Feb 2021 at 17:41, Carrick Bartle <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 17, 2021, at 8:35 AM, Jonathan Hoyland <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Feb 2021 13:00:00 -0800

> operator would also be free to try impose semantics

Yeah, I don't really agree that we should restrict every server in order to
make it easier for the people writing SSL stacks to tell server operators
"no".

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Feb 2021 21:05:28 +0000

> make it easier for the people writing SSL stacks to tell server operators

Yes, we disagree.

(This mail has as much fresh content as the one to which I'm
replying:-)

S.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 17 Feb 2021 17:27:55 -0500

One interesting property of ECH is that it can enable deniable connection
to the public name for GREASE users.  In other words, a passive onlooker
cannot tell the difference between a GREASE user who is actually connecting
to "www.example.com" and an ECH user whose ECHConfig.public_name is "
www.example.com".  Even an active onlooker cannot be sure that the GREASE
user was really connecting to the specified domain, unless they have
confidence that they have exhaustively enumerated the valid ECHConfigs.  In
some contexts, adding doubt to a user activity attribution can be a
meaningful privacy gain.

Adding visible structure to the config_id has the potential to impair this
privacy gain.  If all known ECHConfig.config_ids for a public_name have
some visible structure, GREASE users will be more readily distinguished
with higher confidence, and have less privacy.

I'd like to avoid inviting significant visible structure in the config_id
field (say, >2 bytes of non-random content) unless we have a compelling use
case in mind.

---

From: Christopher Patton <[email-masked]>
Date: Mon, 22 Feb 2021 18:12:30 -0800

Hi Chris, all,

On the heels of this change, here's another PR that I'd folks to weigh in
> on:

I support this change as-is. It seems to me that a 1-byte config_id
provides enough flexibility to support any use case we have envisioned thus
far. I suggest we pull the trigger on it.

Best,
Chris P.