Mitigate HRR when possible

[chris-wood]

This issue tracks any changes to the ECH specification that can mitigate or minimize the probability of HRR in the context of ECH. Note that it is not meant to disable ECH when HRR occurs, but rather to make this case unlikely. This may mean, for example, giving guidance on how to construct ClientHellos based on server hints in the HTTPS record, though this is somewhat orthogonal to ECH.

cc @sftcd, @ekr, @martinthomson, @davidben, @cjpatton

[davidben]

As you say, this seems orthogonal to ECH. I suspect anything we do here will want to be separate work, where we can give it the time it deserves. (Should be solvable, but I'd want us to work through the downgrade implications.)

[sftcd]

Hiya,

On 03/06/2021 22:30, David Benjamin wrote:

As you say, this seems orthogonal to ECH.

I'm not so sure. ECH gives the client more information as it identifies a DH group that the frontend implements and that the backend knows about. That allows us to e.g. state that if all 3 support key shares with that group then HRR ought not happen. We can also avoid a potential leak if the server-chosen key share group didn't have a key share in the outer CH, but only in the inner, e.g. by saying "don't do that":-)

I'd also argue that there are some similar statements we could make about potential leaks, e.g. pointing out that if the server-chosen ciphersuite is in both inner and outer CH then we avoid a possible leak.

Maybe a "footguns to avoid" section in the spec?

I suspect anything we do here will want to be separate work, where we can give it the time it deserves. (Should be solvable, but I'd want us to work through the downgrade implications.)

Sounds fair. Though I think I'd prefer we (try to) stick to guidance and not further complicate SVCB if that's at all possible.

Cheers, S.

[chris-wood]

I'm not so sure. ECH gives the client more information as it identifies a DH group that the frontend implements and that the backend knows about.

The HPKE group is not necessarily the same as the TLS group, for better or worse, so it's not clear to me that one can infer the backend supports x25519 for TLS just because the client-facing server supports the x25519-based DHKEM.

[sftcd]

On 03/06/2021 23:10, Christopher Wood wrote:

I'm not so sure. ECH gives the client more information as it identifies a DH group that the frontend implements and that the backend knows about.

The HPKE group is not necessarily the same as the TLS group, for better or worse, so it's not clear to me that one can infer the backend supports x25519 for TLS just because the client-facing server supports the x25519-based DHKEM.

Sure. But we can say that if they do all support it, then HRR isn't likely (I think), and maybe even RECOMMEND that servers try ensure that's the case?

Until we hit the fun of hybrid PQC stuff, that ought be fairly easy for a lot of servers to do, and tooling could be developed to check it works ok, e.g. while setting up ECH and rolling keys. I'm sure there'd be issues with load balancing and out-of-whack server configs, but we can still say that it's a better setup I hope.

S.

[davidben]

Indeed our implementation supports a bunch of NIST curves for TLS due to TLS's long legacy, but we have no plans to support them in ECH. We already support a hybrid PQC group in TLS (CECPQ2), but we are not yet putting it in ECH and HPKE. (Someday, maybe, but those keys are kinda big and there are enough problems to solve with ECH as it is.)

The configurations also have very different deployment characteristics. ECH groups come from ECH keys, which are long-lived and integrated into a whole key rotation, DNS, and TLS config pipeline. TLS groups can be changed unilaterally be a single server instance with no coordination elsewhere in the fleet. Moreover, in Split Mode ECH, the ECH keys are a property of the client-facing server, while the TLS configuration is a property of the backend server. These two may have nothing to do with each other.

Divining TLS configuration directly from ECH keys is really a non-starter.

[sftcd]

On 03/06/2021 23:30, David Benjamin wrote:

Divining TLS configuration directly from ECH keys is really a non-starter.

Well, "divining" is a slightly pejorative term here though.

I think there are likely to be many setups where its entirely practical to ensure the ECH group works for all relevant TLS servers and don't see why we ought not recommend that that be done where possible.

I'm sure in the most complex cases of the biggest fleets it's harder than for a small hoster, but I'd argue we ought try do our best for the latter as well as the former.

S.

[martinthomson]

NSS has a similar to what @davidben describes. We have no plan to support P-256 in HPKE, for instance. PQ support is very much TBD as well, but I expect one to move independent of the other.

The only option I see here is an extension to ECH configurations that signals group support. But I mostly don't want to have extensions. The existing measures we use for avoiding HRR are working and I see no reason to fortify those.

[ekr]

I also do not believe we should do anything as part of ECH, for several reasons.

First, it's unnecessary to deploy ECH. Given that we're going to have HRR, we have to bear that design burden anyway.

Second, it's orthogonal in the sense that one might want to have group signaling w/o ECH, even if you used the same record.

Third, it's not necessarily straightforward to design a mechanism like this without introducing downgrade attacks. Recall that ECHConfig is not authenticated and so any signal received is untrustworthy. As a concrete example, in the current design, each ECH key is a separate ECHConfig, and the server has no way of knowing the entire set of keys the client saw. So what happens if the client and server both have the preference order A, B for both ECH and TLS key establishment and the attacker strips A from ECHConfig. If the client relies on this, you will end up with B, even though TLS 1.3 would normally negotiate A. It's possible you can fix this, for instance by folding the entire set of ECHConfigs into the transcript, but the point here is that this needs real design and analysis, and it would be inappropriate to recommend that clients us ECH as a hint absent that analysis.

As MT notes, this seems like a natural place for extensions.

-Ekr

On Thu, Jun 3, 2021 at 3:37 PM Martin Thomson @.***> wrote:

NSS has a similar to what @davidben https://github.com/davidben describes. We have no plan to support P-256 in HPKE, for instance. PQ support is very much TBD as well, but I expect one to move independent of the other.

The only option I see here is an extension to ECH configurations that signals group support. But I mostly don't want to have extensions. The existing measures we use for avoiding HRR are working and I see no reason to fortify those.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tlswg/draft-ietf-tls-esni/issues/440#issuecomment-854230605, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIPLII5MBJUEFUGNNK37HLTQ773HANCNFSM46BQDQQA .

[chris-wood]

Thanks to @davidben's new draft I think we can safely punt this issue. (Thanks, David!)