Mohamed Boucadair has entered the following ballot position for draft-ietf-tls-esni-24: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Eric, Kazuho, Nick, and Christopher, Thank you for the effort put into this specification. Also, thanks to Giuseppe Fioccola for the OPSDIR review. The document is well-written with a good discussion on deployment considerations and impacts on some existing use of SNI (network management, attack detection, etc.). Thanks for the clarification provided in follow-up discussion. I trust the authors are tracking the changes. ===OLD BALLOT=== Please find below some few DISCUSS points and a set of comments. # Require or not require DNS/9460+ECH-IN-DNS ## Recommendation? CURRENT: This document defines the ECH configuration's format, but delegates DNS publication details to [RFC9460]. 9460/ECH-IN-DNS are cited as normative. This "seems" to assume that making use of ECH requires this specific discovery. If that is a recommended deployment approach, then the text should say so explicitly. Such recommendation does not prevent use of ECH independent of the ECH-IN-DNS. Existing text is clear on this matter, Section 3.2: Other delivery mechanisms are also possible. For example, the client may have the ECH configuration preconfigured. ## ECH use with Encrypted DNS Server Note also that other mechanisms such as DNR (RFC9463) can be used to learn ECH service parameter to connect to a DoH server itself. This is not possible directly with 9460 for the connection with an encrypted DNS resolver. # Per-server configuration The spec defines a generic ECH Config structure that can be used by clients. However, there is no discussion how this can be indexed locally and bind it to a server. IMO, this should be independent of the ech discovery mechanism. # (apparent) Inconsistency vs ECH-IN-DNS? ECH spec says the following in Section 8.1 Thus server operators SHOULD ensure servers understand a given set of ECH keys before advertising them. ECH-IN-DNS says the following in Section 4: When publishing a record containing an "ech" parameter, the publisher MUST ensure that all IP addresses of TargetName correspond to servers that have access to the corresponding private key or are authoritative for the public name Avoiding failures is the main motivation for both “ensure” behaviors. Is there a reason why one spec uses SHOULD while the other uses a MUST? Please check. Thanks. # Section 1 ## Newer versions CURRENT: ECH is supported in TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], and newer versions of the TLS and DTLS protocols. Do we mean that future versions must support this? # Section 5.1 ## Contiguous CURRENT: The values MUST be ordered contiguously in ClientHelloInner, and the Unless I missed it, I didn’t see any check on this at the receiver side? Should we have one? ## Substitute CURRENT: the client MAY substitute extensions which it knows will be duplicated in ClientHelloOuter. Is this substitution triggered by configuration? Can a client make an autonomous decision here? If no, please explicit that this is based on an instruction/configuration. # Mysterious “network attacker” There are some few uses of such mention in the spec. For example, Section 5.2 has the following: To prevent a network attacker from modifying the ClientHelloOuter while keeping the same encrypted ClientHelloInner Also, Section 8.1.1 says: Unless ECH is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to using unencrypted ClientHellos, as this allows a network attacker to disclose the contents of this ClientHello, including the SNI. What is a “network attacker”? Attacks can be even from within the infrastructure that hosts the client-facing server/backend server! Not sure if your use of “network attacker” covers that case as well. Please reword for clarity. # Section 6.1.7 ## An obsolete RFC CURRENT: In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity [RFC6125]. Any reason why RFC9125 is not used here? ## Layer CURRENT: Clients that enforce this by checking ECHConfig.contents.public_name do not need to repeat the check at this layer. Which layer? ## Reasoning CURRENT: Prior to attempting a connection, a client SHOULD validate the ECHConfig. Clients SHOULD ignore any ECHConfig structure with a public_name that is not a valid host name in preferred name syntax (see Section 2 of [DNS-TERMS]). Any reason why invalid configuration are not unconditionally ignored? # How to retrieve the value used by an implementation for the following? CURRENT: Clients SHOULD impose the same lifetime and scope restrictions that they apply to other server-based tracking vectors such as PSKs. This may be used for troubleshooting/diagnostic. # On Middleboxes in Section 8.1.2 Any impact to record for load-balancers that used to rely in SNI to distribute requests? # Legitimate use of SNI may break CURRENT: Some use cases which depend on information ECH encrypts may break with the deployment of ECH. We may cite RFC9065 here. # Do we have record for the “common scenario” claim in Section 10.2? CURRENT: This means that any attacker which can inject DNS responses or poison DNS caches, which is a common scenario in client access networks, # What is meant by “transit mechanisms” in Section 10.2? CURRENT: Moreover, as noted in the introduction, SNI encryption is less useful without encryption of DNS queries in transit mechanisms. # Section 10.10.5: Regularly CURRENT: This design does not provide forward secrecy for the inner ClientHello because the server's ECH key is static. However, the window of exposure is bound by the key lifetime. It is RECOMMENDED that servers rotate keys regularly. Any guidance on how frequent key rotation should be done to avoid impact service stability and ensure service continuity? Any pointer to cite on such matters? Adam raised a more general comment: “If it is possible (possibly not in this drat) to offer more detailed operational guidance on key rotation, that would be helpful. There are some points in the document that might allude to implementation-specific configuration choices. Implementations would ideally expose these choices to operators so they can make the best possible choices for their needs.” Some words on these matters would be helpful. Thanks. # Section 10.11: Redundant padding requirement with the SHOULDs in 6.1.3 OLD: Variations in the length of the ClientHelloInner ciphertext could leak information about the corresponding plaintext. Section 6.1.3 describes a RECOMMENDED padding mechanism for clients aimed at reducing potential information leakage. NEW: Variations in the length of the ClientHelloInner ciphertext could leak information about the corresponding plaintext. Section 6.1.3 describes a recommended padding mechanism for clients aimed at reducing potential information leakage. # Any reason why this text is not included in the main body? CURRENT: Appendix A. ECHConfig Extension Guidance Cheers, Med _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
