Subject: [TLS] TLS ECH, how much can the hint stick out?

From: Christian Huitema <[email-masked]>
Date: Tue, 8 Sep 2020 08:19:53 -0700

The ECH proposal for Encrypted SNI is almost ready, but for a very small
debate. The original proposal was using trial description to distinguish
between ECH aware responses to the encrypted inner Client-Hello from non
ECH aware response to the "cover" outer CH. This is problematic in the
QUIC use case. The latest proposal is to embed a "hint" in 8 bytes of
the Server Random. The proposal was for ECH-aware servers to use eight
bytes of a hash of the inner Client Random as a hint. Analysis shows
that this enables two attacks:

1) If the Client Hello is replayed, the same hint will be present in the
response to the original CH and to the response to the copy, providing
observers with a clear indication that ECH was used.

2) If the Client Hello is intercepted by an MITM attacker, the attacker
can rewrite the server's response before presenting it to the client.
The attacker formats its own Server Hello that reuses the Server Random
from the original server response, but use its own key share, etc. The
hint will cause the ECH aware client to create an handshake key using
the inner CH. In a QUIC set up, the MITM attacker can easily detect
that, before even transmitting the server's certificate. Thus, the MITM
attacker can detect usage of ECH.

We have a simple proposal that solves the replay attack: set the hint as
a hash of both the inner Client Random and the "non-hint" bytes of the
Server Random. That's clearly a good idea, but it does not solve the
active MITM attack. Solving that requires tying the hint with the
handshake key derived by the original server, for example by hashing the
inner Client Random, the "non-hint" bytes of the Server Random, and the
server key share. That's harder to implement, so the question is about
cost and opportunity.

This all relates to how much ECH is "sticking out". The current stance
is that a passive attacker cannot distinguish between a client using ECH
to access a hidden SNI and a client merely greasing the ECH extension.
The observation is that there may be many potential active attacks,
especially if the server shares its ESNI/ECH configuration publicly. If
there are many such attacks, and if defense of the hint against MITM is
hard to implement, implementing the defense might make the code more
fragile, with little actual gain. But I am not convinced by that
argument, because it smells a lot like "the other side of the boat is
leaking too, why should I plug this particular leak?"

And so, at Chris Wood's request, I am sending this message to the list.

-- Christian Huitema

---

From: Christopher Patton <[email-masked]>
Date: Tue, 8 Sep 2020 11:22:40 -0700

Hi Christian, Hi list,

The "don't stick out" property is a steganographic security goal: we want
the "real" protocol, i.e. TLS with ECH acceptance, to be indistinguishable
from the "cover" protocol, i.e., the handshake pattern in which the client
sends a "dummy" ECH extension that is ignored or rejected by the server.
This is a property that TLS was never designed to have, but it seems that
we need some degree of it in order to deploy ECH. The fundamental question
that Christian raises is what is the right threat model for this property.

The "status quo" threat model considers a distinguisher that is strictly
passive---it does not interfere with a handshake or probe the server---and
that does not know the ECH configuration. This seems (to me, at least)
sufficient to account for middleboxes that might ossify on the ECH
extension. It also seems achievable, both by the ECH as it is and for the
proposed change.

The distinguishing attacks described by Christian are much stronger, in the
sense that they involve an active attacker. I don't believe there is any
way of implementing ECH---either as it is or with the proposed
change---that defeats active attacks in general. In particular---and as
Christian points out---an active attacker can probe the server to learn the
ECH configuration (via the ECH retry logic), which it can use to easily
distinguish the real protocol from the cover protocol. This works
regardless of whether the change is adopted.

In my view, achieving don't-stick-out-security against active attackers
requires us to revisit the design of ECH altogether. The main difficulty is
that client-facing servers publish the ECH configuration in a way that's
easily accessible to an active attacker. Keeping the configuration secret
may provide a way to achieve security, and some deployments might opt to do
this; but the vast majority won't. We might consider adding support for
this deployment scenario, but this can (and should, I think) wait for a
later draft.

That said, it is worth considering mitigations against known attacks, in
particualr (1). I think the suggestion for mitigating (2) adds too much
complexity, and if it doesn't fully address the intended threat model (I
don't think it does), then we'll likely need to replace it in the future. I
think it's better to keep things simple until we fully address the intended
threat model.

Best,
Chris P.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 8 Sep 2020 14:36:27 -0400

I think we all agree that this discussion concerns attacks that are outside
the baseline threat model, and that we are therefore not "obligated" to
defeat.  However, I also agree with Christian that each additional proposed
defense adds some value, even if the protection is limited -- enough value
to be worth including, but only if it doesn't impede deployment of ECH.

If we can establish how difficult it would be to hash the server keyshare
into the hint in various implementations, I think we'll have our answer.  I
suspect it is difficult enough to create a problem for someone, but I'm not
a TLS implementer.

On Tue, Sep 8, 2020 at 2:23 PM Christopher Patton <cpatton=
[email-masked]> wrote:

> The distinguishing attacks described by Christian are much stronger, in
> the sense that they involve an active attacker. I don't believe there is
> any way of implementing ECH---either as it is or with the proposed
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Christopher Patton <[email-masked]>
Date: Tue, 8 Sep 2020 11:57:57 -0700

> suspect it is difficult enough to create a problem for someone, but I'm not

One data point: In the standard Go implementation, the ServerHello.random
is computed well before the "key_shares" extension is serialized [1].
Changing this would be somewhat invasive, but perhaps not prohibitively
so.

Best,
Chris P.

[1]
https://github.com/golang/go/blob/master/src/crypto/tls/handshake_server_tls13.go#L83

---

From: Mike Bishop <[email-masked]>
Date: Thu, 10 Sep 2020 18:51:59 +0000

This is primarily an active attack, but not purely so.  Clearly the MITM is an active attacker, but there are situations in QUIC (and DTLS, I presume) where a ClientHello gets retransmitted.  Depending on server infrastructure, the client might get two different responses.  This isn’t limited to cases where the observer/attacker is the one performing the replay.

So I think we need to decide whether it’s a goal that, given that relatively narrow situation, the observer shouldn’t be able to identify ECH acceptance by comparing two ServerHellos that both respond to the same ClientHello.

From: TLS <[email-masked]> On Behalf Of Christopher Patton
Sent: Tuesday, September 8, 2020 2:23 PM
To: Christian Huitema <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] TLS ECH, how much can the hint stick out?

Hi Christian, Hi list, 

The "don't stick out" property is a steganographic security goal: we want the "real" protocol, i.e. TLS with ECH acceptance, to be indistinguishable from the "cover" protocol, i.e., the handshake pattern in which the client sends a "dummy" ECH extension that is ignored or rejected by the server. This is a property that TLS was never designed to have, but it seems that we need some degree of it in order to deploy ECH. The fundamental question that Christian raises is what is the right threat model for this property.

The "status quo" threat model considers a distinguisher that is strictly passive---it does not interfere with a handshake or probe the server---and that does not know the ECH configuration. This seems (to me, at least) sufficient to account for middleboxes that might ossify on the ECH extension. It also seems achievable, both by the ECH as it is and for the proposed change.

The distinguishing attacks described by Christian are much stronger, in the sense that they involve an active attacker. I don't believe there is any way of implementing ECH---either as it is or with the proposed change---that defeats active attacks in general. In particular---and as Christian points out---an active attacker can probe the server to learn the ECH configuration (via the ECH retry logic), which it can use to easily distinguish the real protocol from the cover protocol. This works regardless of whether the change is adopted.

In my view, achieving don't-stick-out-security against active attackers requires us to revisit the design of ECH altogether. The main difficulty is that client-facing servers publish the ECH configuration in a way that's easily accessible to an active attacker. Keeping the configuration secret may provide a way to achieve security, and some deployments might opt to do this; but the vast majority won't. We might consider adding support for this deployment scenario, but this can (and should, I think) wait for a later draft.

That said, it is worth considering mitigations against known attacks, in particualr (1). I think the suggestion for mitigating (2) adds too much complexity, and if it doesn't fully address the intended threat model (I don't think it does), then we'll likely need to replace it in the future. I think it's better to keep things simple until we fully address the intended threat model.

Best,

Chris P.

---

From: Christopher Patton <[email-masked]>
Date: Thu, 10 Sep 2020 12:43:17 -0700

Hi Mike,

I've since updated the proposal to address the replay attack, but not
Christian's MITM attack:
https://github.com/tlswg/draft-ietf-tls-esni/pull/287

A quick question about Chrisitian's suggestion of using the "key_shares" to
derive the hint. I believe a slightly stronger variant of the MITM attack
beats this mitigation: suppose the server replays not only the original
hint, but also the original "key_shares" shares extension. It won't be able
to decrypt the client's response, but can't the attacker still detect ECH
usage?

Best,
Chris P.

On Thu, Sep 10, 2020 at 11:52 AM Mike Bishop <[email-masked]> wrote:

> This is primarily an active attack, but not purely so.  Clearly the MITM
> is an active attacker, but there are situations in QUIC (and DTLS, I
> presume) where a ClientHello gets retransmitted.  Depending on server
> infrastructure, the client might get two different responses.  This isn’t
> limited to cases where the observer/attacker is the one performing the
> replay.
>
>
>
> So I think we need to decide whether it’s a goal that, given that
> relatively narrow situation, the observer shouldn’t be able to identify ECH
> acceptance by comparing two ServerHellos that both respond to the same
> ClientHello.
>
>
>
> *From:* TLS <[email-masked]> *On Behalf Of *Christopher Patton
> *Sent:* Tuesday, September 8, 2020 2:23 PM
> *To:* Christian Huitema <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] TLS ECH, how much can the hint stick out?
>
>
>
> Hi Christian, Hi list,
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Sep 2020 12:57:35 -0700

On Thu, Sep 10, 2020 at 11:52 AM Mike Bishop <[email-masked]> wrote:

> infrastructure, the client might get two different responses.
>

This doesn't sound correct. In this circumstance, the client and the server
might have mismatched SH values and the handshake will fail. To the best of
my knowledge, the server is required to behave consistently in this case,
even if it consists of multiple machines.

-Ekr

---

From: Mike Bishop <[email-masked]>
Date: Thu, 10 Sep 2020 21:21:16 +0000

Certainly it’s better for the server if it can be consistent, especially if it expects multi-packet first flights.  If the same back-end sees both, it can discard the second, and that’s what I’d expect most of the time.  But here’s what I think is possible:

The client sends an Initial packet (randomly selected Destination CID), PTOs, then sends another Initial packet to the same Destination CID.  On the server side, the infrastructure assumes that Initial packets whose CIDs aren’t issued by them can be routed to a random back-end, and that back-end will set a new DCID that routes to it in the future.

The client will receive either of the Server Initial packets, switch to the new DCID, and will reject the other because attempts to change the server’s CID a second time.  The connection succeeds because whichever server’s ServerHello is used also has its DCID used, so all subsequent packets go to that back-end.

From: Eric Rescorla <[email-masked]> 
Sent: Thursday, September 10, 2020 3:58 PM
To: Mike Bishop <[email-masked]>
Cc: Christopher Patton <cpatton=[email-masked]>; Christian Huitema <[email-masked]>; [email-masked]
Subject: Re: [TLS] TLS ECH, how much can the hint stick out?

On Thu, Sep 10, 2020 at 11:52 AM Mike Bishop <[email-masked] <mailto:[email-masked]> > wrote:

This is primarily an active attack, but not purely so.  Clearly the MITM is an active attacker, but there are situations in QUIC (and DTLS, I presume) where a ClientHello gets retransmitted.  Depending on server infrastructure, the client might get two different responses.  

This doesn't sound correct. In this circumstance, the client and the server might have mismatched SH values and the handshake will fail. To the best of my knowledge, the server is required to behave consistently in this case, even if it consists of multiple machines.

-Ekr

From: TLS <[email-masked] <mailto:[email-masked]> > On Behalf Of Christopher Patton
Sent: Tuesday, September 8, 2020 2:23 PM
To: Christian Huitema <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [TLS] TLS ECH, how much can the hint stick out?

Hi Christian, Hi list, 

Best,

Chris P.

_______________________________________________
TLS mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/tls

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 10 Sep 2020 17:26:14 -0400

I don't know enough about QUIC's connection management rules to know
whether Mike's scenario here is strictly compliant, but I don't think we
need to figure that out, because the mitigation (mixing in
ServerHello.Random[0:24]) is pretty trivial.

The interesting question here is about mixing in the server key_share,
which seems somewhat less trivial.

On Thu, Sep 10, 2020 at 5:22 PM Mike Bishop <[email-masked]> wrote:

> Certainly it’s better for the server if it can be consistent, especially
> if it expects multi-packet first flights.  If the same back-end sees both,
> it can discard the second, and that’s what I’d expect most of the time.
> But here’s what I think is possible:
>
>
>
> The client sends an Initial packet (randomly selected Destination CID),
> PTOs, then sends another Initial packet to the same Destination CID.  On
> the server side, the infrastructure assumes that Initial packets whose CIDs
> aren’t issued by them can be routed to a random back-end, and that back-end
> will set a new DCID that routes to it in the future.
>
>
>
> The client will receive either of the Server Initial packets, switch to
> the new DCID, and will reject the other because attempts to change the
> server’s CID a second time.  The connection succeeds because whichever
> server’s ServerHello is used also has its DCID used, so all subsequent
> packets go to that back-end.
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Thursday, September 10, 2020 3:58 PM
> *To:* Mike Bishop <[email-masked]>
> *Cc:* Christopher Patton <cpatton=[email-masked]>;
> Christian Huitema <[email-masked]>; [email-masked]
> This doesn't sound correct. In this circumstance, the client and the
> server might have mismatched SH values and the handshake will fail. To the
> best of my knowledge, the server is required to behave consistently in this
> case, even if it consists of multiple machines.
>
>
>
> -Ekr
>
>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Sep 2020 15:11:40 -0700

> packets go to that back-end.

OK, this can't happen in DTLS because the CID management works differently.

While it's not clear to me that QUIC explicitly prohibits this (it would be
prohibited if CRYPTO frames were STREAM frames because of
draft-ietf-tls-quic-transport S 2.2, it seems like it's  quite bad practice
because the result will be that the losing server has a pending handshake
which it continues to retransmit on until the client times out.

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Thu, 10 Sep 2020 17:45:48 -0700

On 9/10/2020 12:43 PM, Christopher Patton wrote:
> A quick question about Chrisitian's suggestion of using the
> "key_shares" to derive the hint. I believe a slightly stronger variant
> of the MITM attack beats this mitigation: suppose the server replays
> not only the original hint, but also the original "key_shares" shares
> extension. It won't be able to decrypt the client's response, but
> can't the attacker still detect ECH usage?

No, I don't think the server can detect ECH usage by doing that. The
client will complete the exchange as if connected to the server. The
client's response would pretty much the same as if the server's response
had not been modified, and the MITM will not be able to test whether
this is ECH or not. If it could, ECH would be seriously broken.

But there may be some attack plausible by playing with the ciphersuite,
or maybe the TLS version extension. I don't think so, but I can't prove
it either way. One solution would be to incorporate more elements in the
hash. Another would be to serialize the whole server hello, with a
proforma random, and add to the hint hash the server hello bytes that
follow the "random" part.

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 11 Sep 2020 11:46:28 +1000

> OK, this can't happen in DTLS because the CID management works differently.

Right.

> While it's not clear to me that QUIC explicitly prohibits this (it 
> would be prohibited if CRYPTO frames were STREAM frames because of 
> draft-ietf-tls-quic-transport S 2.2, it seems like it's  quite bad 
> practice because the result will be that the losing server has a 
> pending handshake which it continues to retransmit on until the client 
> times out.

QUIC does prohibit this.  This looks like another case of a client that sent an Initial and went away: a situation that servers have to deal with.  In any case, the server cannot retransmit indefinitely because it is bound by the anti-amplification limit.  I believe that QUIC works if the server doesn't arm a timer at this point, if it comes to that.

---

From: Christopher Patton <[email-masked]>
Date: Thu, 10 Sep 2020 18:54:13 -0700

Hi Christian,

> this is ECH or not. If it could, ECH would be seriously broken.

I think we should be careful with the word "broken" ... here we're talking
about "don't stick out", which is a deployment consideration only. The main
security goal is confidentiality of the ClientHelloInner.

> follow the "random" part.

The latter seems to be the lowest cost in terms of implementation
complexity. Nevertheless, I continue to believe that its cost outweighs the
benefit of this mechanism. To summarize my reasons:

   1. The class of active attacks it addresses is quite narrow, and we have
   no reason to believe that it poses a deployment risk to ECH. (It certainly
   doesn't invalidate the main security goal.)
   2. We know of much simpler active attacks for distinguishing real ECH
   from cover ECH, which means the intended threat model isn't fully addressed.
   3. Any future mechanism that rigorously addresses the intended threat
   model will replace what we specify today. It seems like good hygiene to
   keep the thing we'll be replacing as simple as possible.

The current proposal (https://github.com/tlswg/draft-ietf-tls-esni/pull/287)
doesn't stick out much to passive attackers, and it even mitigates
(accidental) replay attacks. This ought to be enough to begin experimenting
with deployment. We won't know what the real-world deployment risks are
until we do.

Best,
Chris P.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 11 Sep 2020 13:26:05 +0000

*   I think we should be careful with the word "broken" ... here we're talking about "don't stick out", which is a deployment consideration only. The main security goal is confidentiality of the ClientHelloInner.

Perhaps this is just being pedantic, but I disagree with the tone of this. We want deployable confidentiality, and “don’t stick out” is something we believe is a necessary requirement to be deployable.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 11 Sep 2020 13:52:35 +0000

IMHO, Rich is 100% correct here. 

If it’s not deployable (and to me it means **universally** deployable, not merely within the US), if fails *all* of the security goals completely. 

Regards,
Uri

> On Sep 11, 2020, at 09:27, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> 
> I think we should be careful with the word "broken" ... here we're talking about "don't stick out", which is a deployment consideration only. The main security goal is confidentiality of the ClientHelloInner.
>

---

From: Karthik Bhargavan <[email-masked]>
Date: Fri, 11 Sep 2020 15:59:41 +0200

Perhaps I am misunderstanding the design constraints and the following idea
has been thought of and discarded, but could we not remove trial decryption
and replace it with a trial HMAC, at the cost of adding yet more crypto.

- The outer ClientHello contains an ECH extension as usual.
- The ServerHello ALWAYS echoes the ECH extension, whether it chooses the inner or outer ClientHello.
- This ServerHello extension contains an HMAC  of (say) an empty bytestring (or the current transcript)
   with a key derived from the chosen handshake secret (i.e. either using the innerCH or outerCH),
- On receiving the ServerHello, the client generates both possible handshake secrets and both
  possible HMAC keys, verifies the HMAC and uses it to choose the correct handshake secret.

Does the above still conflict with QUIC and open up active MitM attacks?

Best,
Karthik

> On 8 Sep 2020, at 17:19, Christian Huitema <[email-masked]> wrote:
>

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 11 Sep 2020 10:08:44 -0400

Karthik: That approach works, but unless the ECH echo is universally
deployed, it still reveals to a passive observer whether the server is
ECH-enabled.  That means, at least for several years, exchanges that are
using ECH will likely "stick out" to a passive observer.  This is something
we are trying to avoid.

---

From: Karthik Bhargavan <[email-masked]>
Date: Sat, 12 Sep 2020 01:20:14 +0200

Ok, in that case it is worth making the don’t “stick out” property more precise.

1) We can either try to prevent the attacker from learning whether ECH was actually used in a particular connection, or
2) We can try to prevent the attacker from learning whether the server supports ECH at all.

I gather the consensus is that we should try to obtain (2) at least until ECH support becomes ubiquitous on the server side?
Since TLS 1.3 moves all but a few SH extensions to EE, I suppose there isn’t any other extension to hide this signal in.

In that case, I guess using a value derived from the handshake key as part of the ServerRandom should probably work.
That is, when constructing the ServerHello:

- first set the first N bytes of the server random to 0
- compute the hanshake secret (based on either the inner or outer CH)
- compute the signal of N bytes as
  signal = HKDF-Expand-Label(handshake secret, “s hs hmac”, Transcript-Hash(ClientHello..ServerHello), N)
- replace the first N bytes of the server random with signal

This is a somewhat icky design, but I think we should be able to justify it for (say) N <= 16 bytes.

> On 11 Sep 2020, at 16:08, Ben Schwartz <[email-masked]> wrote:
> 
> Karthik: That approach works, but unless the ECH echo is universally deployed, it still reveals to a passive observer whether the server is ECH-enabled.  That means, at least for several years, exchanges that are using ECH will likely "stick out" to a passive observer.  This is something we are trying to avoid.
> 
> On Fri, Sep 11, 2020 at 10:00 AM Karthik Bhargavan <[email-masked] <mailto:[email-masked]>> wrote:
> > On 8 Sep 2020, at 17:19, Christian Huitema <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 11 Sep 2020 18:56:16 -0700

On 9/11/2020 4:20 PM, Karthik Bhargavan wrote:

> 1) We can either try to prevent the attacker from learning whether ECH
> was actually used in a particular connection, or
> I gather the consensus is that we should try to obtain (2) at least
> until ECH support becomes ubiquitous on the server side?
> Since TLS 1.3 moves all but a few SH extensions to EE, I suppose there
> isn’t any other extension to hide this signal in.
>
> In that case, I guess using a value derived from the handshake key as
> part of the ServerRandom should probably work.
>   signal = HKDF-Expand-Label(handshake secret, “s hs hmac”,
> Transcript-Hash(ClientHello..ServerHello), N)

I like that design a lot. It is more robust than my proposal to mix the
key share in the hint.

In other words, makes the hint dependent on the actual handshake secret.
That's pretty much what I was aiming for when asking to make the hash
dependent on the key components of the handshake secret. I was concerned
with a potential circular dependency between the secret, the hint and
the server random, which is why I was looking at mixing various elements
in the hash that computes the hint. But Karthik is of course right, the
handshake secret itself does not depend on the transcript; that
dependency is only introduced when the label is derived.

Any big issue keeping N=8?

-- Christian Huitema

---

From: Karthik Bhargavan <[email-masked]>
Date: Sat, 12 Sep 2020 13:55:43 +0200

> Any big issue keeping N=8
> 
Regarding the length of N, I gather that the trade-off is that if it is too short, the probability of collisions between the signal and randomly generated server randoms becomes significant,
and so does the probability of an active MitM forging the signal. Is there some other concern? 
8 bytes seems fine for these considerations. Is the idea that we would reuse the downgrade sentinel?

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 12 Sep 2020 22:58:14 +1000

On Sat, Sep 12, 2020, at 21:55, Karthik Bhargavan wrote:
> Regarding the length of N, I gather that the trade-off is that if it is 
> too short, the probability of collisions between the signal and 
> randomly generated server randoms becomes significant,

If they collide, you could test with trial decryption, but 8 bytes seems like it might be enough that you might choose not to bother.

---

From: Karthik Bhargavan <[email-masked]>
Date: Sat, 12 Sep 2020 18:59:36 +0200

> Karthik: That approach works, but unless the ECH echo is universally deployed, it still reveals to a passive observer whether the server is ECH-enabled.  That means, at least for several years, exc…

I would like to return to this point, after some discussion with Chris Wood, who points out that anybody can query a server to see if it supports ECH.

So, hiding whether a server supports ECH or not (which I called level 2) is a significantly higher bar than hiding whether a particular connection is using ECH or not (level 1).
I would like to understand how the WG feels about this requirement and that there is consensus that we need (2) and not just (1).

If we only need (1) then using a ServerHello ECH extension feels more principled to me.
Of course, the ServerHello.random trick should work for both, but at the cost of implementation complexity.

-Karthik

---

From: Christian Huitema <[email-masked]>
Date: Sat, 12 Sep 2020 11:38:51 -0700

The ServerHello ECH extension approach has lots of good properties, but
also one big risk. What if a server decides that ECH is not needed for
this connection, and does not send the extension at all? The connection
will work just fine, because for the client absence of the extension
implies "using the outer CH". Implementation laziness could easily lead
to a state in which only the ECH-using connections use the ECH
extensions in the Server Hello. That would fail both (1) and (2).

-- Christian Huitema

On 9/12/2020 9:59 AM, Karthik Bhargavan wrote:
>> deployed, it still reveals to a passive observer whether the server
>> is ECH-enabled.  That means, at least for several years, exchanges
>> that are using ECH will likely "stick out" to a passive observer. 
>> This is something we are trying to avoid.
>
> I would like to return to this point, after some discussion with Chris
> Wood, who points out that anybody can query a server to see if it
> supports ECH.
>
> So, hiding whether a server supports ECH or not (which I called level
> 2) is a significantly higher bar than hiding whether a particular
> connection is using ECH or not (level 1).
> I would like to understand how the WG feels about this requirement and
> that there is consensus that we need (2) and not just (1).
>
>> On Fri, Sep 11, 2020 at 10:00 AM Karthik Bhargavan
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>

---

From: Christopher Patton <[email-masked]>
Date: Sat, 12 Sep 2020 11:41:02 -0700

I agree with Christian. The reason to use the ServerHello.random trick is
to make real ECH connections look like connections in which the client
sends a dummy ECH extension to a non-ECH server. In particular, this design
pattern is needed for property (1).

Property (2) is achievable if the ECH configuration is secret, i.e., if the
server is deployed in such a way that it does not reveal it speaks ECH
unless the client offers the right configuration. In particular, the server
need not publish the ECH config, either via DNS or the ECH retry logic.
This won't be feasible for the vast majority of deployments.

As I said above, I think ECH should support use cases for which keeping the
configuration secret is feasible. The trial decryption mechanism might
provide this already, but overall the trial HMAC approach is a much better
design. It would be useful if someone from QUICville could chime in on how
painful it would be to implement. (It doesn't seem that bad for vanilla
TLS.)

Chris P.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 14 Sep 2020 17:50:13 +0000

*   So, hiding whether a server supports ECH or not (which I called level 2) is a significantly higher bar than hiding whether a particular connection is using ECH or not (level 1).

  *   I would like to understand how the WG feels about this requirement and that there is consensus that we need (2) and not just (1).

I do not see Level 2 being a requirement.  (I don’t see how you could make it work but I’m not a cryptographer.)

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Sep 2020 08:00:01 -0700

> Property (2) is achievable if the ECH configuration is secret, i.e., if
> the server is deployed in such a way that it does not reveal it speaks ECH

I think this is the key point:
1. If the ECH Config is public, it's trivial to tell whether the client is
trying to do ECH
2. If the ECH Config is public, it's also trivial to tell whether the
server does ECH
3. It's reasonable to expect that if the client is trying to do ECH and the
server does ECH, you will get ECH.

That limits the degree to which it is useful to conceal whether a given
connection is using ECH. From my perspective, the purpose of this piece of
the design is to discourage middleboxes from blindly suppressing ECH, but
at the point where you are willing to actively intercept each connection,
the ECH Config attack seems much easier.  Note that if the deployment
environment changes so that it would be desirable to fold the handshake key
into this value, this can be done later with an ECH Config extension and
will not need to appear on the wire.

-Ekr