Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

improve text regarding ECH #463

Merged
merged 2 commits into from
Jul 22, 2022
Merged

improve text regarding ECH #463

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
83c0af5
improve text regarding ECH
stpeter Jul 18, 2022
aa8717c
Update BCP195bis/draft-ietf-uta-rfc7525bis.md
stpeter Jul 19, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 3 additions & 3 deletions BCP195bis/draft-ietf-uta-rfc7525bis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -549,15 +549,15 @@ Renegotiation in TLS 1.2 was (partially) replaced in TLS 1.3 by separate post-ha
## Server Name Indication (SNI)
{: #sni}

TLS implementations MUST support the Server Name Indication (SNI) extension defined in {{Section 3 of RFC6066}} for those higher-level protocols that would benefit from it, including HTTPS. However, the actual use of SNI in particular circumstances is a matter of local policy. Implementers are strongly encouraged to support TLS Encrypted Client Hello once {{?I-D.ietf-tls-esni}} has been standardized.
TLS implementations MUST support the Server Name Indication (SNI) extension defined in {{Section 3 of RFC6066}} for those higher-level protocols that would benefit from it, including HTTPS. However, the actual use of SNI in particular circumstances is a matter of local policy. At the time of writing, a technology for encrypting the SNI (called Encrypted Client Hello) is being worked on in the TLS Working Group {{?I-D.ietf-tls-esni}}. Once that method has been standardized and widely implemented, it will likely be appropriate to recommend its usage in a future version of this BCP.



Rationale: SNI supports deployment of multiple TLS-protected virtual servers on a single
address, and therefore enables fine-grained security for these virtual servers,
by allowing each one to have its own certificate. However, SNI also leaks the
target domain for a given connection; this information leak is closed by
use of TLS Encrypted Client Hello.
target domain for a given connection; this information leak will be closed by
use of TLS Encrypted Client Hello once that method has been standardized.

In order to prevent the attacks described in {{ALPACA}}, a server that does not
recognize the presented server name SHOULD NOT continue the handshake and
Expand Down