Hi Eric, Thanks for the follow-up.
Please see inline. Cheers, Med De : Eric Rescorla <[email protected]> Envoyé : mardi 6 mai 2025 23:37 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-tls-esni-24: (with DISCUSS and COMMENT) 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. [Med] Can you please indicate “some of the mechanisms” you are referring to? Thanks. > 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. [Med] ACK. I don’t understand why ECH-IN-DNS is normative then, especially that we don’t recommend it + ECH can be used with ECH-IN-DNS as exemplified in the item right after. > ## 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. [Med] Glad we agree on this. This is actually to exemplify that we can use ECH independent of DNS. > # 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. [Med] Do you mean that the connection handling will be dependent of each discovery channel? My initial comment is that we don’t say anywhere in the doc that the config is bound to a server. > # (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. [Med] Will check there. 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? No. We are saying that we expect it will work in future versions but not older versions. [Med] OK. English is only my 4th language, so my brain bugged with “**is** supported … in newer versions”, which do not exist yet. > # 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. [Med] Thanks for the clarification. > ## 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. [Med] It isn’t clear to me based on which knowledge the client can make that substitution. > # 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. [Med] I’m familiar with 3552, thanks. There is no notion of “network attacker”. Please consider changing or defining that term. Thanks. > 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. [Med] Not sure to follow this as the document has two modes. > Please reword for clarity. I believe this is sufficiently clear and matches our normal conventions. [Med] by “our”, I guess you meant “TLS WG”. I care about those who will deploy, hence my comment. The use of “network attacker” is not clear to me, even. > # 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. [Med] OK, but better to clean what we can, though. > ## 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. [Med] This is indeed better. Thanks. > ## 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. [Med] Thanks for the background. Not sure to agree with you interop comment. It is not clear when the client can simply proceed with any validation of the ECHConfig. > # 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. [Med] The comment is about retrieving what lifetime is used by an implementation. This can be useful for diagnostic in managed networks. 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. [Med] Thank you. > # 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. [Med] Hmm. Not sure which issues to cite a document with due IETF consensus. That doc includes an inventory of cases discussed in this section. This has the merit to have something concrete and be explicit about is being discussion. > # 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. [Med] Maybe, but this is not characteristic for “access networks”, which has a specific meaning in operations. > # What is meant by “transit mechanisms” in Section 10.2? DoT, DoH, etc. [Med] Aaah, I see. The wording below is better. > CURRENT: > Moreover, as noted in the introduction, SNI encryption is less useful > without encryption of DNS queries in transit mechanisms. Changed to "in transport". [Med] Thanks. > # 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? [Med] Seems this one was missed. > > 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. [Med] Is there any public pointer to that discussion? 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. I believe RECOMMENDED makes it clearer in this case. It's not uncommon to have redundant 2119 language. [Med] This makes it like a distinct/new requirement. It is cleaner to keep one such statement. > # 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. [Med] Thanks. -Ekr On Tue, May 6, 2025 at 7:09 AM Mohamed Boucadair via Datatracker <[email protected]<mailto:[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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
