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 |
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
2 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