Med, Thank you for your comments. Responses below.
> 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. No, I don't think that's correct. It's normative because some of the mechanisms in this document -- whether mandatory or not -- depend on that specification. > If that is a recommended deployment > approach, then the text should say so explicitly. It's the only current at-scale deployment approach. However, I don't think we need to take a position either way. This specification tells you how to do it, but doesn't need to require or even recommend any specific mechanism. > ## 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. Yes, this is true, but I don't believe any action is required here. > # 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. I don't believe this is indicated. Different delivery mechanisms might have different properties, for instance because the DNS mechanism applies only to specific IPs. Even in this specification, you have to handle retry and non-retry ECHConfigs differently. > # (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. See Ben's response. These requirements apply to different keys. > # 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? No. We are saying that we expect it will work in future versions but not older versions. > # 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? It's enforced automatically, because it's a compression/decompression transformation and otherwise it will not be reversible. > ## 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. I don't understand the question. This is just something the client is permitted to do, just as with any other point of variation in the protocol. We don't take a position on whether clients should do it or not or on what basis they should decide. > # 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”? This is referring to the Internet Threat Model from S 3. of RFC 3552. > 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. >From the perspective of this document they are a single unit, even if they are actually distributed. > Please reword for clarity. I believe this is sufficiently clear and matches our normal conventions. > # 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? Version skew. This will get fixed in RPC processing. > ## Layer > > CURRENT: > Clients that enforce this by checking ECHConfig.contents.public_name > do not need to repeat the check at this layer. > > Which layer? During the ECH rejection flow. I have updated the text to make this slightly clearer. See https://github.com/tlswg/draft-ietf-tls-esni/pull/653 for this and other changes. > ## 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? This was extensively debated in the WG and there were some situations where people wanted flexibility here. It does not create interoperability problems to have it be a SHOULD. > # 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. I don't understand what you're asking for here. We don't generally specify how to introspect into the behavior of a client's TLS stack, though of course it's often possible. > # On Middleboxes in Section 8.1.2 > > Any impact to record for load-balancers that used to rely in SNI to distribute > requests? They'll need to terminate ECH. I added some text. > # 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. I'd rather not get into it here, because thus turnes out to be a controversial topic. > # 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, I believe that captive portals are sufficiently well known to as be common knowledge. > # What is meant by “transit mechanisms” in Section 10.2? DoT, DoH, etc. > CURRENT: > Moreover, as noted in the introduction, SNI encryption is less useful > without encryption of DNS queries in transit mechanisms. Changed to "in transport". > # 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. The WG discussed this extensively and concluded that we had said what could be said. > # 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. I believe RECOMMENDED makes it clearer in this case. It's not uncommon to have redundant 2119 language. > # Any reason why this text is not included in the main body? > > CURRENT: > Appendix A. ECHConfig Extension Guidance This has already been moved in the editor's copy. -Ekr On Tue, May 6, 2025 at 7:09 AM Mohamed Boucadair via Datatracker < [email protected]> wrote: > Mohamed Boucadair has entered the following ballot position for > draft-ietf-tls-esni-24: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 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.). There are parts where more operational guidance > would > be helpful as highlighted in Adam Montville’s secdir review. > > 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. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # 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 -- [email protected] To unsubscribe send an email to [email protected]
