TLS Encrypted Client Hello
draft-ietf-tls-esni-25
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2025-07-11
|
25 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2025-07-09
|
25 | (System) | RFC Editor state changed to EDIT |
2025-07-09
|
25 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2025-07-09
|
25 | (System) | Announcement was received by RFC Editor |
2025-07-09
|
25 | (System) | IANA Action state changed to In Progress |
2025-07-09
|
25 | Morgan Condie | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2025-07-09
|
25 | Morgan Condie | IESG has approved the document |
2025-07-09
|
25 | Morgan Condie | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2025-07-09
|
25 | Morgan Condie | IESG has approved the document |
2025-07-09
|
25 | Morgan Condie | Closed "Approve" ballot |
2025-07-09
|
25 | Morgan Condie | Ballot approval text was generated |
2025-07-09
|
25 | Paul Wouters | all done |
2025-07-09
|
25 | Paul Wouters | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2025-06-16
|
25 | (System) | Removed all action holders (IESG state changed) |
2025-06-16
|
25 | Paul Wouters | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup |
2025-06-14
|
25 | (System) | Changed action holders to Paul Wouters (IESG state changed) |
2025-06-14
|
25 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2025-06-14
|
25 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2025-06-14
|
25 | Christopher Wood | New version available: draft-ietf-tls-esni-25.txt |
2025-06-14
|
25 | (System) | New version approved |
2025-06-14
|
25 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Eric Rescorla , Kazuho Oku , Nick Sullivan |
2025-06-14
|
25 | Christopher Wood | Uploaded new revision |
2025-05-16
|
24 | Mohamed Boucadair | [Ballot comment] Hi Eric, Kazuho, Nick, and Christopher, Thank you for the effort put into this specification. Also, thanks to Giuseppe Fioccola for the OPSDIR … [Ballot 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 |
2025-05-16
|
24 | Mohamed Boucadair | [Ballot Position Update] Position for Mohamed Boucadair has been changed to No Objection from Discuss |
2025-05-07
|
24 | Mike Bishop | [Ballot comment] I've previously reviewed this document and have very few additional comments; these comments can be incorporated or ignored at the authors' and responsible … [Ballot comment] I've previously reviewed this document and have very few additional comments; these comments can be incorporated or ignored at the authors' and responsible AD's discretion. 6.1.8: "has been forced to change" imputes external events that aren't relevant to the protocol. The server's configuration may have changed since the client received the retry configs; the client doesn't need to speculate on why. 10.9 notes that there's no collision between ECH acceptance (in 1.3) and downgrade protection (in <1.3) because of the version scoping. It's worth noting, however, that this forecloses using the same approach to guard against downgrades to 1.3 from future TLS versions. |
2025-05-07
|
24 | Mike Bishop | [Ballot Position Update] New position, No Objection, has been recorded for Mike Bishop |
2025-05-06
|
24 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2025-05-06
|
24 | Mohamed Boucadair | [Ballot discuss] Hi Eric, Kazuho, Nick, and Christopher, Thank you for the effort put into this specification. Also, thanks to Giuseppe Fioccola for the OPSDIR … [Ballot 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. |
2025-05-06
|
24 | Mohamed Boucadair | [Ballot comment] # Section 1 ## Newer versions CURRENT: ECH is supported in TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], and … [Ballot 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 |
2025-05-06
|
24 | Mohamed Boucadair | [Ballot Position Update] New position, Discuss, has been recorded for Mohamed Boucadair |
2025-05-05
|
24 | Erik Kline | [Ballot comment] # Internet AD comments for draft-ietf-tls-esni-24 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments … [Ballot comment] # Internet AD comments for draft-ietf-tls-esni-24 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S3.1 * Please stick with RFC 5952 S4.3 (lowercase the [a-f] characters in IPv6 addresses). |
2025-05-05
|
24 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2025-05-05
|
24 | Orie Steele | [Ballot comment] Thank you to Carsten Bormann for the ARTART review, and to EKR for addressing his comments. |
2025-05-05
|
24 | Orie Steele | [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele |
2025-05-05
|
24 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2025-05-05
|
24 | Deb Cooley | [Ballot comment] Thanks to Adam Montville for their secdir review. |
2025-05-05
|
24 | Deb Cooley | [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley |
2025-05-02
|
24 | Roman Danyliw | [Ballot comment] Thank you to Pete Resnick for the GENART review. ** Section 8.2. Recommend explicitly documenting that the WG considered the impact of ECH’s … [Ballot comment] Thank you to Pete Resnick for the GENART review. ** Section 8.2. Recommend explicitly documenting that the WG considered the impact of ECH’s design to current operational security practices. There was feedback after the publication of TLS v1.3 that such practices were not considered (even though they were). OLD Some use cases which depend on information ECH encrypts may break with the deployment of ECH. NEW (roughly) Some use cases which depend on information ECH encrypt may break with the deployment of ECH. This includes operational security practices in the enterprise that depend on the SNI for policy enforcement, audit or network visibility. ** From idnits: ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Should RFC9525 be used instead of RFC6125 in Section 6.1.7? Not, why not? |
2025-05-02
|
24 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2025-05-01
|
24 | David Dong | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2025-04-29
|
24 | Gunter Van de Velde | [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde |
2025-04-28
|
24 | (System) | Changed action holders to Eric Rescorla, Kazuho Oku, Christopher Wood, Nick Sullivan (IESG state changed) |
2025-04-28
|
24 | Paul Wouters | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2025-04-25
|
24 | Gorry Fairhurst | [Ballot comment] Thank you for preparing this I-D. Thanks also for the TSV-ART review provided by Tommy Pauly. I agree with that review conclusion: this … [Ballot comment] Thank you for preparing this I-D. Thanks also for the TSV-ART review provided by Tommy Pauly. I agree with that review conclusion: this protocol extension is defined to work with various transport cases (TLS over TCP, DTLS over UDP, QUIC, etc), and otherwise does not fundamentally change their properties. The following comments are not blocking, but I would really appreciate feedback to help understand what is intended: 1) In section 6.1 what is required for interop? On Offering ECH I see a list of seven requirements and I thought I saw at least some of these 7 requirements were necessary for correct operation of the remaining algorithm. (e.g., For me, Rule 1 suggests a need for TLS 1.3 or higher and if not supplied, a later rule says this results in a server reject for ECH, etc). However, I found this sentence after the list: “Note that these rules may change in the presence of an application profile specifying otherwise.” - I am trying to understand if any of these requirements are actually required for correct operation: Does that additional sentence simply mean these are a default and all these requirements can be changed ? or something else? 2) A similar phrase follows the seven requirements in section 6.2. What is intended to happen here? === The following are editorial comments, please consider for the next revision: 1) The appendix contains a normative requirement which seems odd to position this requirement in an appendix: “Any future information or hints that influence ClientHelloOuter SHOULD be specified as ECHConfig extensions. “ 2) It would have been nice for me if the acronym KEM was expanded on first use. 3) I would appreciate a forward reference for the first mention of “GREASE ECH” in the text of 6.1 that says “and sends GREASE ECH otherwise.” referencing the text of section 6.3 - I did guess!!! 4) I would appreciate a single sentence or so simply explaining what GREASE ECH was seeking to achieve in the currently empty text of section 6.2. (A note saying “see also section 10.10.4” would be super helpful) 5) Please clarify address: “Clients can implement a new transport connection in a way that best suits their deployment. For example, clients can reuse the same IP address when establishing the new transport connection or they can choose to use a different IP address if provided with options from DNS. “ - I think this means destination IP address (because of the mention of DNS), but maybe not, because a client can also use alternative valid source addresses. I would appreciate just a little more clarity - perhaps even just something like: “Clients can reuse the same IP addresses when establishing the new transport connection or they can choose to use a different pair of IP addresses (e.g., if provided with options from DNS).” - if that was what was intended? 6) To me it is really odd to require a server to be careful!!! See: “The server MUST be careful not to unnecessarily reject connections if the same ECHConfig id or keypair is used in multiple ECHConfigs with distinct public names.” - This seems to me to require some rewording to communicate the requirement and I assume the care is needed when configuring the server, and the server MUST NOT unnecessarily reject connections … 7) See: “The design of ECH as specified in this document necessarily requires changes to client, client-facing server, and backend server.” - would it read better with the “the” or “a” before client? 8) See: “unencrypted.This means differences” - missing space before period. 9) See: “Notes: Any notes associated with the entry” missing final period. 10) Please check use of “which” below and update as needed: One rule I’ve heard is that uf the details are crucial to the sentence, use that. If they aren’t crucial, use which: “Section 11.3 describes a set of Reserved extensions which will never be registered.” /which/that/? “Some use cases which depend on information ECH encrypts may break with the deployment of ECH.” - /which/that/ ? “Depending on implementation details and deployment settings, use cases which depend on “ - /which/that/ ? “Values which are independent of the true server name, or other information the client wishes to protect, MAY be included in ClientHelloOuter.” - /which/that/ ? “Values which depend on the contents of ClientHelloInner, such as the true server name, can influence how client-facing servers process this message.” - /which/that/ ? “A malicious attacker may craft a packet which takes excessive resources to decompress” - /which/that/ ? “These requirements prevent an attacker from performing a packet amplification attack, by crafting a ClientHelloOuter which decompresses to a much larger ClientHelloInner.” - /which/that/ ? Thanks again for this detailed and useful specification. Gorry |
2025-04-25
|
24 | Gorry Fairhurst | Ballot comment text updated for Gorry Fairhurst |
2025-04-22
|
24 | Andy Newton | [Ballot Position Update] New position, No Objection, has been recorded for Andy Newton |
2025-04-22
|
24 | Gorry Fairhurst | [Ballot comment] Thank you for preparing this I-D. Thanks also for the TSV-ART review provided by Tommy Pauly. I agree with that review conclusion: this … [Ballot comment] Thank you for preparing this I-D. Thanks also for the TSV-ART review provided by Tommy Pauly. I agree with that review conclusion: this protocol extension is defined to work with various transport cases (TLS over TCP, DTLS over UDP, QUIC, etc), and otherwise does not fundamentally change their properties. The following comments ia not blocking, but I would really appreciate feedback to help understand what is intended: * In section 6.1 and 6.2, what is required for interop? In section 6.1, on Offering ECH I see a list of seven requirements. I thought I saw at least some of these 7 requirements were necessary for correct operation of the remaining algorithm. (e.g., For me, Rule 1 suggests a need for TLS 1.3 or higher and if not supplied, a later rule says this results in a server reject for ECH, etc). However, I found this sentence after the list: “Note that these rules may change in the presence of an application profile specifying otherwise.” - I am trying to understand if any of these requirements are actually required for correct operation: Does that additional sentence simply mean these are a default and all these requirements can be changed ? or something else? A similar phrase follows the seven requirements in section 6.2. What is intended to happen here? === The following are editorial comments, please consider for the next revision: 1) The appendix contains a normative requirement which seems odd to position this requirement in an appendix: “Any future information or hints that influence ClientHelloOuter SHOULD be specified as ECHConfig extensions. “ 2) It would have been nice for me if the acronym KEM was expanded on first use. 3) I would appreciate a forward reference for the first mention of “GREASE ECH” in the text of 6.1 that says “and sends GREASE ECH otherwise.” referencing the text of section 6.3 - I did guess!!! 4) I would appreciate a single sentence or so simply explaining what GREASE ECH was seeking to achieve in the currently empty text of section 6.2. (A note saying “see also section 10.10.4” would be super helpful) 5) Please clarify address: “Clients can implement a new transport connection in a way that best suits their deployment. For example, clients can reuse the same IP address when establishing the new transport connection or they can choose to use a different IP address if provided with options from DNS. “ - I think this means destination IP address (because of the mention of DNS), but maybe not, because a client can also use alternative valid source addresses. I would appreciate just a little more clarity - perhaps even just something like: “Clients can reuse the same IP addresses when establishing the new transport connection or they can choose to use a different pair of IP addresses (e.g., if provided with options from DNS).” - if that was what was intended? 6) To me it is really odd to require a server to be careful!!! See: “The server MUST be careful not to unnecessarily reject connections if the same ECHConfig id or keypair is used in multiple ECHConfigs with distinct public names.” - This seems to me to require some rewording to communicate the requirement and I assume the care is needed when configuring the server, and the server MUST NOT unnecessarily reject connections … 7) See: “The design of ECH as specified in this document necessarily requires changes to client, client-facing server, and backend server.” - would it read better with the “the” or “a” before client? 8) See: “unencrypted.This means differences” - missing space before period. 9) See: “Notes: Any notes associated with the entry” missing final period. 10) Please check use of “which” below and update as needed: One rule I’ve heard is that uf the details are crucial to the sentence, use that. If they aren’t crucial, use which: “Section 11.3 describes a set of Reserved extensions which will never be registered.” /which/that/? “Some use cases which depend on information ECH encrypts may break with the deployment of ECH.” - /which/that/ ? “Depending on implementation details and deployment settings, use cases which depend on “ - /which/that/ ? “Values which are independent of the true server name, or other information the client wishes to protect, MAY be included in ClientHelloOuter.” - /which/that/ ? “Values which depend on the contents of ClientHelloInner, such as the true server name, can influence how client-facing servers process this message.” - /which/that/ ? “A malicious attacker may craft a packet which takes excessive resources to decompress” - /which/that/ ? “These requirements prevent an attacker from performing a packet amplification attack, by crafting a ClientHelloOuter which decompresses to a much larger ClientHelloInner.” - /which/that/ ? Thanks again for this detailed and useful specification. Gorry |
2025-04-22
|
24 | Gorry Fairhurst | Ballot comment text updated for Gorry Fairhurst |
2025-04-22
|
24 | Gorry Fairhurst | [Ballot comment] Thank you for preparing this I-D. Thanks also for the TSV-ART review provided by Tommy Pauly. I agree with that review conclusion: this … [Ballot comment] Thank you for preparing this I-D. Thanks also for the TSV-ART review provided by Tommy Pauly. I agree with that review conclusion: this protocol extension is defined to work with various transport cases (TLS over TCP, DTLS over UDP, QUIC, etc), and otherwise does not fundamentally change their properties. The following comments ia not blocking, but I would really appreciate feedback to help understand what is intended: * In section 6.1 and 6.2, what is required for interop? In section 6.1, on Offering ECH I see a list of seven requirements. I thought I saw at least some of these 7 requirements were necessary for correct operation of the remaining algorithm. (e.g., For me, Rule 1 suggests a need for TLS 1.3 or higher and if not supplied, a later rule says this results in a server reject for ECH, etc). However, I found this sentence after the list: “Note that these rules may change in the presence of an application profile specifying otherwise.” - I am trying to understand if any of these requirements are actually required for correct operation: Does that additional sentence simply mean these are a default and all these requirements can be changed ? or something else? A similar phrase follows the seven requirements in section 6.2. What is intended to happen here? === The following are editorial comments, please consider for the next revision: 1) The appendix contains a normative requirement which seems odd to position this requirement in an appendix: “Any future information or hints that influence ClientHelloOuter SHOULD be specified as ECHConfig extensions. “ 2) It would have been nice for me if the acronym KEM was expanded on first use. 3) I would appreciate a forward reference for the first mention of “GREASE ECH” in the text of 6.1 that says “and sends GREASE ECH otherwise.” referencing the text of section 6.3 - I did guess!!! 4) I would appreciate a single sentence or so simply explaining what GREASE ECH was seeking to achieve in the currently empty text of section 6.2. (A note saying “see also section 10.10.4” would be super helpful) 5) Please clarify address: “Clients can implement a new transport connection in a way that best suits their deployment. For example, clients can reuse the same IP address when establishing the new transport connection or they can choose to use a different IP address if provided with options from DNS. “ - I think this means destination IP address (because of the mention of DNS), but maybe not, because a client can also use alternative valid source addresses. I would appreciate just a little more clarity - perhaps even just something like: “Clients can reuse the same IP addresses when establishing the new transport connection or they can choose to use a different pair of IP addresses (e.g., if provided with options from DNS).” - if that was what was intended? 6) To me it is really odd to require a server to be careful!!! See: “The server MUST be careful not to unnecessarily reject connections if the same ECHConfig id or keypair is used in multiple ECHConfigs with distinct public names.” - This seems to me to require some rewording to communicate the requirement and I assume the care is needed when configuring the server, and the server MUST NOT unnecessarily reject connections … 7) See: “The design of ECH as specified in this document necessarily requires changes to client, client-facing server, and backend server.” - would it read better with the “the” or “a” before client? 8) See: “unencrypted.This means differences” - missing space before period. 8) See: “Notes: Any notes associated with the entry” missing final period. 9) Please check use of “which” below and update as needed: One rule I’ve heard is that uf the details are crucial to the sentence, use that. If they aren’t crucial, use which: “Section 11.3 describes a set of Reserved extensions which will never be registered.” /which/that/? “Some use cases which depend on information ECH encrypts may break with the deployment of ECH.” - /which/that/ ? “Depending on implementation details and deployment settings, use cases which depend on “ - /which/that/ ? “Values which are independent of the true server name, or other information the client wishes to protect, MAY be included in ClientHelloOuter.” - /which/that/ ? “Values which depend on the contents of ClientHelloInner, such as the true server name, can influence how client-facing servers process this message.” - /which/that/ ? “A malicious attacker may craft a packet which takes excessive resources to decompress” - /which/that/ ? “These requirements prevent an attacker from performing a packet amplification attack, by crafting a ClientHelloOuter which decompresses to a much larger ClientHelloInner.” - /which/that/ ? Thanks again for this detailed and useful specification. Gorry |
2025-04-22
|
24 | Gorry Fairhurst | [Ballot Position Update] New position, No Objection, has been recorded for Gorry Fairhurst |
2025-04-18
|
24 | Tommy Pauly | Request for Telechat review by INTDIR Completed: Ready. Reviewer: Tommy Pauly. Sent review to list. |
2025-04-03
|
24 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Tommy Pauly |
2025-04-03
|
24 | Éric Vyncke | Requested Telechat review by INTDIR |
2025-04-02
|
24 | R. Gieben | Request for Telechat review by DNSDIR Completed: Ready. Reviewer: R. Gieben. Sent review to list. |
2025-03-27
|
24 | Geoff Huston | Request for Telechat review by DNSDIR is assigned to R. Gieben |
2025-03-27
|
24 | Cindy Morgan | Placed on agenda for telechat - 2025-05-08 |
2025-03-25
|
24 | Giuseppe Fioccola | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Giuseppe Fioccola. Sent review to list. |
2025-03-23
|
24 | Paul Wouters | Ballot has been issued |
2025-03-23
|
24 | Paul Wouters | [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters |
2025-03-23
|
24 | Paul Wouters | Created "Approve" ballot |
2025-03-23
|
24 | Paul Wouters | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2025-03-23
|
24 | Paul Wouters | Ballot writeup was changed |
2025-03-20
|
24 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2025-03-20
|
24 | Eric Rescorla | New version available: draft-ietf-tls-esni-24.txt |
2025-03-20
|
24 | (System) | New version approved |
2025-03-20
|
24 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Eric Rescorla , Kazuho Oku , Nick Sullivan |
2025-03-20
|
24 | Eric Rescorla | Uploaded new revision |
2025-03-18
|
23 | Stewart Bryant | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Stewart Bryant. Sent review to list. |
2025-03-17
|
23 | Sean Turner | Added to session: IETF-122: tls Thu-0230 |
2025-03-14
|
23 | Carsten Bormann | Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Carsten Bormann. Sent review to list. |
2025-03-13
|
23 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2025-03-12
|
23 | Carlos Pignataro | Request for Last Call review by OPSDIR is assigned to Giuseppe Fioccola |
2025-03-12
|
23 | Mohamed Boucadair | Requested Last Call review by OPSDIR |
2025-03-07
|
23 | R. Gieben | Request for Last Call review by DNSDIR Completed: Ready with Nits. Reviewer: R. Gieben. Sent review to list. |
2025-03-05
|
23 | Adam Montville | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Adam Montville. Sent review to list. |
2025-03-05
|
23 | Tommy Pauly | Request for Last Call review by TSVART Completed: Ready. Reviewer: Tommy Pauly. Sent review to list. |
2025-03-04
|
23 | David Dong | IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-tls-esni-23. If any part of this review is inaccurate, please let us know. IANA has a question … IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-tls-esni-23. If any part of this review is inaccurate, please let us know. IANA has a question about one of the actions requested in the IANA Considerations section of this document. IANA understands that, upon approval of this document, there are four actions which we must complete. First, in the TLS ExtensionType Values registry in the Transport Layer Security (TLS) Extensions registry group located at: https://www.iana.org/assignments/tls-extensiontype-values/ two new ExtensionType Values are to be registered as follows: Value: [ TBD-at-Registration ] Extension Name: encrypted_client_hello(0xfe0d) TLS 1.3: CH, HRR, EE DTLS-Only: N Recommended: Yes Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Extension Name: ech_outer_extensions(0xfd00) TLS 1.3: CH DTLS-Only: N Recommended: Yes Reference: [ RFC-to-be ] IANA Question -> Section 11.1 of the current draft requests that "the "Comment" column set to "Only appears in inner CH." However, there is no comment field in the current registry. What further action should IANA take? As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, in the TLS Alerts registry in the Transport Layer Security (TLS) Parameters registry group located at: https://www.iana.org/assignments/tls-parameters/ the temporary registration for the following alert will be made permanent and its reference changed to [ RFC-to-be ] as follows Value: 121 Description: ech_required DTLS-OK: Y Reference: [ RFC-to-be ] Comment: Third, a new registry group called TLS Encrypted Client Hello (ECH) Configuration Extensions will be created on the IANA Matrix located at: https://www.iana.org/protocols Fourth, a new registry is to be created called the ECHConfig Extension registry. The new registry will be located on the newly created TLS Encrypted Client Hello (ECH) Configuration Extensions registry group (IANA Action three above). The new registry will be managed via Specification Required as defined in [RFC8126]. The new registry will have a reference of [ RFC-to-be ] and a note at the top of the registry as follows: "Note: The role of the designated expert is described in RFC 8447. The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in depth reviews, but their approval should not be taken as an endorsement of the extension." There are initial registrations in the new registry as follows: Value Extension Name Recommended Reference Notes -------+--------------------+-----------+----------------------------+-------------- 0x0000 RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0x1A1A RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0x2A2A RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0x3A3A RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0x4A4A RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0x5A5A RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0x6A6A RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0x7A7A RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0x8A8A RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0x9A9A RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0xAAAA RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0xBABA RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0xCACA RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0xDADA RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0xEAEA RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry 0xFAFA RESERVED Y [ RFC-to-be; Section 6.2.2 ] Grease entry We understand that these are the only actions required to be completed upon approval of this document. NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2025-03-04
|
23 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2025-02-26
|
23 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2025-02-25
|
23 | David Dong | IANA Experts State changed to Reviews assigned |
2025-02-25
|
23 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Tommy Pauly |
2025-02-25
|
23 | Joseph Touch | Assignment of request for Last Call review by TSVART to Joseph Touch was rejected |
2025-02-24
|
23 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Joseph Touch |
2025-02-23
|
23 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Adam Montville |
2025-02-21
|
23 | Barry Leiba | Request for Last Call review by ARTART is assigned to Carsten Bormann |
2025-02-20
|
23 | Geoff Huston | Request for Last Call review by DNSDIR is assigned to R. Gieben |
2025-02-20
|
23 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2025-02-20
|
23 | Cindy Morgan | The following Last Call announcement was sent out (ends 2025-03-13): From: The IESG To: IETF-Announce CC: draft-ietf-tls-esni@ietf.org, jsalowey@gmail.com, paul.wouters@aiven.io, tls-chairs@ietf.org, tls@ietf.org … The following Last Call announcement was sent out (ends 2025-03-13): From: The IESG To: IETF-Announce CC: draft-ietf-tls-esni@ietf.org, jsalowey@gmail.com, paul.wouters@aiven.io, tls-chairs@ietf.org, tls@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (TLS Encrypted Client Hello) to Proposed Standard The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'TLS Encrypted Client Hello' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2025-03-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ No IPR declarations have been submitted directly on this I-D. |
2025-02-20
|
23 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2025-02-20
|
23 | Paul Wouters | Last call was requested |
2025-02-20
|
23 | Paul Wouters | Ballot approval text was generated |
2025-02-20
|
23 | Paul Wouters | Ballot writeup was generated |
2025-02-20
|
23 | Paul Wouters | IESG state changed to Last Call Requested from AD Evaluation |
2025-02-20
|
23 | Paul Wouters | Last call announcement was changed |
2025-02-20
|
23 | Paul Wouters | IESG state changed to AD Evaluation from AD Evaluation::AD Followup |
2025-02-19
|
23 | (System) | Changed action holders to Paul Wouters (IESG state changed) |
2025-02-19
|
23 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2025-02-19
|
23 | Eric Rescorla | New version available: draft-ietf-tls-esni-23.txt |
2025-02-19
|
23 | (System) | New version approved |
2025-02-19
|
23 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Eric Rescorla , Kazuho Oku , Nick Sullivan |
2025-02-19
|
23 | Eric Rescorla | Uploaded new revision |
2024-10-17
|
22 | (System) | Changed action holders to Eric Rescorla, Paul Wouters, Kazuho Oku, Christopher Wood, Nick Sullivan (IESG state changed) |
2024-10-17
|
22 | Paul Wouters | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2024-09-23
|
22 | Joseph Salowey | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? This document has broad consensus within the TLS working group. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? The consensus around the document is good, there has been plenty of discussion and debate about the approach taken. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? Draft versions of this protocol have been deployed and tested at scale. A number of vendors have implemented this protocol and tested interoperability. Some of the implementers include: Server Side - Google, Cloudflare Client Side - Firefox, Chrome There is code available several libraries including OpenSSL, BoringSSL and rustls ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. NA 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The protocols in this document have undergone security analysis as documented in https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? NA 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. NA ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? The document is clearly written and ready to be handed off. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? Known issues have been addressed in this document. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The document is a standards track document and is clearly marked as such. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, there are no IPR disclosures. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. All authors have shown their willingness to be listed as such. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) No Known remaining nits 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. References have been checked for normative an informative status. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? Normative references are freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. This document makes a downref to RFC7918 TLS Falsestart which is informational. This deference is already included in the downref registry associated with RFC 9132 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? This document has a normative reference to draft-ietf-tls-svcb-ech-03. It should be ready to progress in a few weeks of this document. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. This document does not change the status of an RFCs 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The shepherd has reviewed the IANA considerations section and has confirmed that IANA registries are clearly identified and new registries have contents, names and procedures defined. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. The new registry is " ECHConfig Extension". The instructions for the designated experts is specification required as in RFC8126. The designated experts should be the TLS designated experts. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://wiki.ietf.org/group/ops/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://wiki.ietf.org/group/iesg/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-09-23
|
22 | Joseph Salowey | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2024-09-23
|
22 | Joseph Salowey | IESG state changed to Publication Requested from I-D Exists |
2024-09-23
|
22 | (System) | Changed action holders to Paul Wouters (IESG state changed) |
2024-09-23
|
22 | Joseph Salowey | Responsible AD changed to Paul Wouters |
2024-09-23
|
22 | Joseph Salowey | Document is now in IESG state Publication Requested |
2024-09-23
|
22 | Joseph Salowey | Tags Doc Shepherd Follow-up Underway, Revised I-D Needed - Issue raised by WGLC cleared. |
2024-09-15
|
22 | Eric Rescorla | New version available: draft-ietf-tls-esni-22.txt |
2024-09-15
|
22 | (System) | New version approved |
2024-09-15
|
22 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Eric Rescorla , Kazuho Oku , Nick Sullivan |
2024-09-15
|
22 | Eric Rescorla | Uploaded new revision |
2024-09-14
|
21 | Eric Rescorla | New version available: draft-ietf-tls-esni-21.txt |
2024-09-14
|
21 | (System) | New version approved |
2024-09-14
|
21 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Eric Rescorla , Kazuho Oku , Nick Sullivan |
2024-09-14
|
21 | Eric Rescorla | Uploaded new revision |
2024-09-10
|
20 | Joseph Salowey | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? This document has broad consensus within the TLS working group. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? The consensus around the document is good, there has been plenty of discussion and debate about the approach taken. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? Draft versions of this protocol have been deployed and tested at scale. A number of vendors have implemented this protocol and tested interoperability. Some of the implementers include: Server Side - Google, Cloudflare Client Side - Firefox, Chrome There is code available several libraries including OpenSSL, BoringSSL and rustls ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. NA 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The protocols in this document have undergone security analysis as documented in https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? NA 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. NA ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? The document is clearly written and ready to be handed off. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? Known issues have been addressed in this document. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The document is a standards track document and is clearly marked as such. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, there are no IPR disclosures. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. All authors have shown their willingness to be listed as such. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) No Known remaining nits 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. References have been checked for normative an informative status. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? Normative references are freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. This document makes a downref to RFC7918 TLS Falsestart which is informational. This deference is already included in the downref registry associated with RFC 9132 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? This document has a normative reference to draft-ietf-tls-svcb-ech-03. It should be ready to progress in a few weeks of this document. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. This document does not change the status of an RFCs 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The shepherd has reviewed the IANA considerations section and has confirmed that IANA registries are clearly identified and new registries have contents, names and procedures defined. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. The new registry is " ECHConfig Extension". The instructions for the designated experts is specification required as in RFC8126. The designated experts should be the TLS designated experts. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://wiki.ietf.org/group/ops/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://wiki.ietf.org/group/iesg/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-09-04
|
20 | Joseph Salowey | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? This document has broad consensus within the TLS working group. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? The consensus around the document is good, there has been plenty of discussion and debate about the approach taken. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? Draft versions of this protocol have been deployed and tested at scale. A number of vendors have implemented this protocol and tested interoperability. Some of the implementers include: Server Side - Google, Cloudflare Client Side - Firefox, Chrome There is code available several libraries including OpenSSL and rustls ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. NA 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The protocols in this document have undergone security analysis as documented in https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? NA 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. NA ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? The document is clearly written and ready to be handed off. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? Known issues have been addressed in this document. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The document is a standards track document and is clearly marked as such. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, there are no IPR disclosures. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. All authors have shown their willingness to be listed as such. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) No Known remaining nits 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. References have been checked for normative an informative status. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? Normative references are freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. This document makes a downref to RFC7918 TLS Falsestart which is informational. This deference is already included in the downref registry associated with RFC 9132 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? This document has a normative reference to draft-ietf-tls-svcb-ech-03. It should be ready to progress in a few weeks of this document. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. This document does not change the status of an RFCs 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The shepherd has reviewed the IANA considerations section and has confirmed that IANA registries are clearly identified and new registries have contents, names and procedures defined. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. The new registry is " ECHConfig Extension". The instructions for the designated experts is specification required as in RFC8126. The designated experts should be the TLS designated experts. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://wiki.ietf.org/group/ops/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://wiki.ietf.org/group/iesg/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-08-24
|
20 | Joseph Salowey | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? This document has broad consensus within the TLS working group. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? The consensus around the document is good, there has been plenty of discussion and debate about the approach taken. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? Draft versions of this protocol have been deployed and tested at scale. A number of vendors have implemented this protocol and tested interoperability. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. NA 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The protocols in this document have undergone security analysis as documented in https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? NA 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. NA ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? The document is clearly written and ready to be handed off. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? Known issues have been addressed in this document. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The document is a standards track document and is clearly marked as such. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, there are no IPR disclosures. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. All authors have shown their willingness to be listed as such. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) No Known remaining nits 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. References have been checked for normative an informative status. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? Normative references are freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. This document makes a downref to RFC7918 TLS Falsestart which is informational. This deference is already included in the downref registry associated with RFC 9132 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? This document has a normative reference to draft-ietf-tls-svcb-ech-03. It should be ready to progress in a few weeks of this document. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. This document does not change the status of an RFCs 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The shepherd has reviewed the IANA considerations section and has confirmed that IANA registries are clearly identified and new registries have contents, names and procedures defined. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. The new registry is " ECHConfig Extension". The instructions for the designated experts is specification required as in RFC8126. The designated experts should be the TLS designated experts. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://wiki.ietf.org/group/ops/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://wiki.ietf.org/group/iesg/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-08-12
|
20 | Joseph Salowey | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? This document has broad consensus within the TLS working group. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Initially there was some controversy around the general concept of encrypted client hello. This discussion was resolved and there is general support for this work in the working group. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? A number of vendors have implemented this protocol and tested interoperability. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. NA 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. NA 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? NA 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. NA ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? The document is clearly written and ready to be handed off. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The document is a standards track document and is clearly marked as such. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, there are no IPR disclosures. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. All authors have shown their willingness to be listed as such. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? Normative references are freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. This document does not change the status of an RFCs 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. The instructions for the designated experts is specification required as in RFC8126. The designated experts should be the TLS designated experts. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://wiki.ietf.org/group/ops/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://wiki.ietf.org/group/iesg/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-08-11
|
20 | Joseph Salowey | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? This document has broad consensus within the TLS working group. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Initially there was some controversy around the general concept of encrypted client hello, which has been resolved. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? A number of vendors have implemented this protocol and tested interoperability. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. NA 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. NA 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? NA 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. NA ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? The document is clearly written and ready to be handed off. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The document is a standards track document and is clearly marked as such. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, there are no IPR disclosures. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. One author has not responded to queries about authorship. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. This document does not change the status of an RFCs 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. The instructions for the designated experts is specification required as in RFC8126. The designated experts should be the TLS designated experts. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://wiki.ietf.org/group/ops/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://wiki.ietf.org/group/iesg/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-08-04
|
20 | Eric Rescorla | New version available: draft-ietf-tls-esni-20.txt |
2024-08-04
|
20 | (System) | New version approved |
2024-08-04
|
20 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Eric Rescorla , Kazuho Oku , Nick Sullivan |
2024-08-04
|
20 | Eric Rescorla | Uploaded new revision |
2024-08-04
|
19 | Eric Rescorla | New version available: draft-ietf-tls-esni-19.txt |
2024-08-04
|
19 | (System) | New version approved |
2024-08-04
|
19 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Eric Rescorla , Kazuho Oku , Nick Sullivan |
2024-08-04
|
19 | Eric Rescorla | Uploaded new revision |
2024-04-02
|
18 | Joseph Salowey | Changed consensus to Yes from Unknown |
2024-04-02
|
18 | Joseph Salowey | Intended Status changed to Proposed Standard from None |
2024-04-01
|
18 | Joseph Salowey | Notification list changed to jsalowey@gmail.com because the document shepherd was set |
2024-04-01
|
18 | Joseph Salowey | Document shepherd changed to Joseph A. Salowey |
2024-04-01
|
18 | Joseph Salowey | Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway set. |
2024-04-01
|
18 | Joseph Salowey | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2024-03-12
|
18 | Sean Turner | IETF WG state changed to In WG Last Call from WG Document |
2024-03-04
|
18 | Eric Rescorla | New version available: draft-ietf-tls-esni-18.txt |
2024-03-04
|
18 | Eric Rescorla | New version accepted (logged-in submitter: Eric Rescorla) |
2024-03-04
|
18 | Eric Rescorla | Uploaded new revision |
2023-11-05
|
17 | Sean Turner | Added to session: IETF-118: tls Mon-0830 |
2023-10-09
|
17 | Christopher Wood | New version available: draft-ietf-tls-esni-17.txt |
2023-10-09
|
17 | Christopher Wood | New version approved |
2023-10-09
|
17 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Eric Rescorla , Kazuho Oku , Nick Sullivan |
2023-10-09
|
17 | Christopher Wood | Uploaded new revision |
2023-10-08
|
16 | (System) | Document has expired |
2023-04-06
|
16 | Christopher Wood | New version available: draft-ietf-tls-esni-16.txt |
2023-04-06
|
16 | Christopher Wood | New version approved |
2023-04-06
|
16 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Eric Rescorla , Kazuho Oku , Nick Sullivan |
2023-04-06
|
16 | Christopher Wood | Uploaded new revision |
2023-04-06
|
15 | (System) | Document has expired |
2022-10-03
|
15 | Christopher Wood | New version available: draft-ietf-tls-esni-15.txt |
2022-10-03
|
15 | (System) | New version approved |
2022-10-03
|
15 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Eric Rescorla , Kazuho Oku , Nick Sullivan |
2022-10-03
|
15 | Christopher Wood | Uploaded new revision |
2022-08-17
|
14 | (System) | Document has expired |
2022-03-13
|
14 | Sean Turner | Added to session: IETF-113: tls Wed-1000 |
2022-02-13
|
14 | Christopher Wood | New version available: draft-ietf-tls-esni-14.txt |
2022-02-13
|
14 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2022-02-13
|
14 | Christopher Wood | Uploaded new revision |
2022-02-13
|
13 | (System) | Document has expired |
2021-11-05
|
13 | Christopher Wood | Added to session: IETF-112: tls Tue-1600 |
2021-08-12
|
13 | Christopher Wood | New version available: draft-ietf-tls-esni-13.txt |
2021-08-12
|
13 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2021-08-12
|
13 | Christopher Wood | Uploaded new revision |
2021-07-07
|
12 | Christopher Wood | New version available: draft-ietf-tls-esni-12.txt |
2021-07-07
|
12 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2021-07-07
|
12 | Christopher Wood | Uploaded new revision |
2021-06-14
|
11 | Christopher Wood | New version available: draft-ietf-tls-esni-11.txt |
2021-06-14
|
11 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2021-06-14
|
11 | Christopher Wood | Uploaded new revision |
2021-03-08
|
10 | Christopher Wood | New version available: draft-ietf-tls-esni-10.txt |
2021-03-08
|
10 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2021-03-08
|
10 | Christopher Wood | Uploaded new revision |
2021-03-03
|
09 | Joseph Salowey | Added to session: IETF-110: tls Mon-1700 |
2020-12-16
|
09 | Christopher Wood | New version available: draft-ietf-tls-esni-09.txt |
2020-12-16
|
09 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2020-12-16
|
09 | Christopher Wood | Uploaded new revision |
2020-11-16
|
08 | Sean Turner | Added to session: IETF-109: tls Tue-1430 |
2020-10-16
|
08 | Christopher Wood | New version available: draft-ietf-tls-esni-08.txt |
2020-10-16
|
08 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2020-10-16
|
08 | Christopher Wood | Uploaded new revision |
2020-06-01
|
07 | Christopher Wood | New version available: draft-ietf-tls-esni-07.txt |
2020-06-01
|
07 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2020-06-01
|
07 | Christopher Wood | Uploaded new revision |
2020-04-27
|
06 | Joseph Salowey | Added to session: interim-2020-tls-01 |
2020-03-09
|
06 | Christopher Wood | New version available: draft-ietf-tls-esni-06.txt |
2020-03-09
|
06 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2020-03-09
|
06 | Christopher Wood | Uploaded new revision |
2019-11-04
|
05 | Christopher Wood | New version available: draft-ietf-tls-esni-05.txt |
2019-11-04
|
05 | (System) | New version accepted (logged-in submitter: Christopher Wood) |
2019-11-04
|
05 | Christopher Wood | Uploaded new revision |
2019-11-04
|
04 | Sean Turner | Changed document URLs from: [] to: repository https://github.com/tlswg/draft-ietf-tls-esni |
2019-07-08
|
04 | Christopher Wood | New version available: draft-ietf-tls-esni-04.txt |
2019-07-08
|
04 | (System) | New version approved |
2019-07-08
|
04 | (System) | Request for posting confirmation emailed to previous authors: Kazuho Oku , Eric Rescorla , Christopher Wood , Nick Sullivan |
2019-07-08
|
04 | Christopher Wood | Uploaded new revision |
2019-03-11
|
03 | Christopher Wood | New version available: draft-ietf-tls-esni-03.txt |
2019-03-11
|
03 | (System) | New version approved |
2019-03-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: Kazuho Oku , Eric Rescorla , Christopher Wood , Nick Sullivan |
2019-03-11
|
03 | Christopher Wood | Uploaded new revision |
2018-10-31
|
02 | Sean Turner | Added to session: IETF-103: tls Mon-1350 |
2018-10-22
|
02 | Christopher Wood | New version available: draft-ietf-tls-esni-02.txt |
2018-10-22
|
02 | (System) | New version approved |
2018-10-22
|
02 | (System) | Request for posting confirmation emailed to previous authors: Kazuho Oku , Eric Rescorla , Christopher Wood , Nick Sullivan |
2018-10-22
|
02 | Christopher Wood | Uploaded new revision |
2018-10-22
|
02 | (System) | Request for posting confirmation emailed to previous authors: Kazuho Oku , Eric Rescorla , Christopher Wood , Nick Sullivan |
2018-10-22
|
02 | Christopher Wood | Uploaded new revision |
2018-09-18
|
01 | Eric Rescorla | New version available: draft-ietf-tls-esni-01.txt |
2018-09-18
|
01 | (System) | New version approved |
2018-09-18
|
01 | (System) | Request for posting confirmation emailed to previous authors: Kazuho Oku , Eric Rescorla , Christopher Wood , Nick Sullivan |
2018-09-18
|
01 | Eric Rescorla | Uploaded new revision |
2018-09-12
|
00 | Sean Turner | This document now replaces draft-rescorla-tls-esni instead of None |
2018-09-12
|
00 | Christopher Wood | New version available: draft-ietf-tls-esni-00.txt |
2018-09-12
|
00 | (System) | New version approved |
2018-09-12
|
00 | Christopher Wood | Request for posting confirmation emailed to submitter and authors: Kazuho Oku , Eric Rescorla , Christopher Wood , Nick Sullivan |
2018-09-12
|
00 | Christopher Wood | Uploaded new revision |