I should add that Cloudflare's fork of crypto/tls has ECH support in case that's of interest to the official Golang maintainers.

CC @golang/security

We were just talking about this today. It seems like a reasonable thing to implement given the direction the ecosystem is going. I think we're likely to prioritize client support first, but given the existence of stuff like Caddy, server support also seems reasonable.

I think we'll want to design the API such that we can internally wire up the net/http client to automatically populate the necessary information via e.g. the DNS discovery mechanism (or manually configure it by passing a tls.Config).

Thank you Roland 😁 Thousands of users appreciate that!

Is there work being done somewhere on this proposal or will start working on this proposal after ECH has been fully standardized to RFC?

I think ideally we'd like to get at least the client half of this in for 1.23, but we still need to decide on what the API will look like.

To just throw something out there, perhaps a very simple first option, which would support clients and leave the door open for sever support, would be to just add a field to tls.Config containing an already serialized ECHConfigList.

e.g.

type Config struct {
    ...

    // EncryptedClientHelloConfigList is a serialized ECHConfigList. If
    // provided, clients will attempt to connect to servers using Encrypted
    // Client Hello (ECH) using one of the provided ECHConfigs. Servers
    // currently ignore this field.
    EncryptedClientHelloConfigList []byte
}

A client that populates this would then populate Config.ServerName as usual, and the internals would take care of the rest. One open question is how it would handle ECH failures, i.e. do we want to offer a knob to control whether we allow fallback or not (I would default to just failing closed, but others might have strong opinions on this).

This would hide away most of the internals of the ECH configuration, allowing direct passthrough for supported discovery mechanisms, and allow us to be as opinionated as we want in terms of picking HPKE cipher suites and such (which is generally a goal of crypto/tls).

For server support we'd then either reuse the EncryptedClientHelloConfigList field with an additional field for private keys, or a map between ECHConfig and private keys.

I have some questions that I don't know about:

1. is there an existing HPKE implementation in go?
2. if we set the EncryptedClientHelloConfigList in serialized form, how do we generate the serialized config? Or would it be more convenient to receive a non-serialized structure? Would it be too much of a performance issue?
3. if we use serialized config, how do we validate/handle error for invalid config?

1. Not yet. I suspect we'll use this as a learning experience to develop an internal-only HPKE API and then based on that experience propose a public one.
2. ECH configs will be fetched from the various discovery mechanisms. It seems unlikely to me (based on a survey of the current ecosystem) that (client) users will ever be generating them themselves, nor should they likely be altering configs they get from elsewhere
3. I'm not entirely convinced that users should be attempting to validate ECH configs themselves. In the case of an error the config should be re-fetched using one of the discovery methods, and if that continues to fail, should stop trying to use ECH for that particular host.

Let's make this proposal about the client side, which the discussion has focused on, and we can revisit the server part in a separate proposal when we have ideas about what the API looks like.

1. is there an existing HPKE implementation in go?

1. Not yet. I suspect we'll use this as a learning experience to develop an internal-only HPKE API and then based on that experience propose a public one.

Actually, I saw on Wikipedia's article about Server Name Indication that cloudflare/go implemented ECH support in this commit from July, last year. This was merged on Feb 9th '24. You asked specifically about HPKE; I'm no expert, but there's a hpke.go file and a separate folder called hpke as well.

In the commit note, it does mention an external dependency requirement, to cloudflare/circl. That hpke folder looks like it is duplicated in the circl repository in fact.

Adds support for draft 13 of the Encrypted ClientHello (ECH) extension
for TLS. This requires CIRCL to implement draft 08 or later of the HPKE
specification (draft-irtf-cfrg-hpke-08).

Maybe cloudflare's licenses are compatible with golang's and their library could be merged into the standard library? It looks like a lot of work was put into that initial commit (38 changed files with 7,335 additions and 35 deletions)!

Maybe cloudflare's licenses are compatible with golang's and their library could be merged into the standard library?

FWIW, license compatibility is not enough; we require a CLA so that all code can be distributed under the simple Go license, not an amalgamation of many licenses.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

The proposal details are in #63369 (comment).

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

The proposal details are in #63369 (comment).

Change https://go.dev/cl/578575 mentions this issue: crypto/tls: add ech client support