Conversation
This was referenced Jul 8, 2026
gmelodie
reviewed
Sep 2, 2026
Comment on lines
+36
to
+41
| In RFC 9849, clients can only use the server provided `retry_configs` if the | ||
| outer handshake authenticates successfully with the given | ||
| ECHConfig.contents.public_name. This means that if servers wish to support the | ||
| `retry_configs` fallback they MUST use a valid domain name and hold the | ||
| corresponding Server Certificate. This is the retry mechanism in RFC 9849; | ||
| there is nothing libp2p specific about this. |
Contributor
There was a problem hiding this comment.
Suggested change
| In RFC 9849, clients can only use the server provided `retry_configs` if the | |
| outer handshake authenticates successfully with the given | |
| ECHConfig.contents.public_name. This means that if servers wish to support the | |
| `retry_configs` fallback they MUST use a valid domain name and hold the | |
| corresponding Server Certificate. This is the retry mechanism in RFC 9849; | |
| there is nothing libp2p specific about this. | |
| Servers MUST use a valid domain name and hold the corresponding Server Certificate to support the `retry_configs` fallback. This is the retry mechanism in RFC 9849; there is nothing libp2p specific about this. |
Comment on lines
+43
to
+44
| If the server does not have a valid public_name and certificate, the client can | ||
| only fail the connection. |
Contributor
There was a problem hiding this comment.
Suggested change
| If the server does not have a valid public_name and certificate, the client can | |
| only fail the connection. | |
| The client MUST fail the connection If the server does not have a valid public_name and certificate pair. |
Comment on lines
+53
to
+54
| Servers SHOULD rotate their keys once a month, and keep the prior ECH Config | ||
| keys around for 1 week to assist stale clients. |
Contributor
There was a problem hiding this comment.
Maybe add the reasoning behind the time windows here? (i.e. once a month, 1 week)
|
|
||
| ## Client ECH Config Caching | ||
|
|
||
| Clients SHOULD cache the ECHConfigList for no more than 48 hours. Note that a |
|
|
||
| ## Server Key Rotation | ||
|
|
||
| Servers SHOULD rotate their keys once a month, and keep the prior ECH Config |
There was a problem hiding this comment.
Suggested change
| Servers SHOULD rotate their keys once a month, and keep the prior ECH Config | |
| Servers SHOULD rotate their ECH key pairs once a month, and keep the prior ECH Config |
| ## Overview | ||
|
|
||
| This document specifies minor changes to the [libp2p TLS Handshake](./tls.md) to | ||
| enable support for [RFC 9849]: TLS Encrypted Client Hello. The primary benefit |
There was a problem hiding this comment.
Suggested change
| enable support for [RFC 9849]: TLS Encrypted Client Hello. The primary benefit | |
| enable support for [RFC 9849]: TLS Encrypted ClientHello. The primary benefit |
|
|
||
| #### Authenticated Rejection | ||
|
|
||
| In RFC 9849, clients can only use the server provided `retry_configs` if the |
There was a problem hiding this comment.
Suggested change
| In RFC 9849, clients can only use the server provided `retry_configs` if the | |
| In RFC 9849, clients can only use the server-provided `retry_configs` if the |
| The `/ech` component SHOULD appear after the `/tls` or `/quic-v1` component. | ||
| Servers use this multiaddr to advertise ECH support and their ECHConfigList. | ||
|
|
||
| ## Caller Provided ECHConfigList |
There was a problem hiding this comment.
Suggested change
| ## Caller Provided ECHConfigList | |
| ## Caller-Provided ECHConfigList |
|
|
||
| ## Overview | ||
|
|
||
| This document specifies minor changes to the [libp2p TLS Handshake](./tls.md) to |
There was a problem hiding this comment.
For TCP, how would this work? because with TCP the flow is:
1 - TCP connection
2 - Multistream negotiation in plaintext sending /multistream/1.0.0 and /tls/1.0.0
3 - Then the TLS handshake happen
meaning that an observer should be able to recognize libp2p being used. Would using /tls/ech mean that we gotta start TLS handshake directly, and skip the multistream select negotiation? if so, probably worth mentioning in the spec
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This document specifies minor changes to the libp2p TLS Handshake to enable support for RFC 9849: TLS Encrypted Client Hello. The primary benefit is to make identifying libp2p connections harder to passive network observers by hiding the “libp2p” ALPN in the encrypted ClientHelloInner.
Related and prereq PRs:
/echmultiformats/multiaddr#183