TLS Encrypted Client Hello
draft-ietf-tls-esni-25

[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

[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.

[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.

[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

[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).

[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?

[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

[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

[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

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

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.

# 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/

# 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/

# 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/

# 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/

# 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/

# 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/