(Insert ARTART boilerplate here.) Thank you for this draft, it is in very good shape. The document is explicit about the different configurations the protocol can be run in, the participants, their roles, the security and privacy objectives that can be achieved as well as the security considerations, and it discusses (and addresses!) deployment considerations. This specification is ready with nits. A few editorial observations and a few nits below. ## Editorial 10.1 »Security and Privacy Goals« starts with definitions (active/passive) that aren’t really Security/Privacy goals. Since “passive” is then used distinguishingly in only three places, it is not clear that this passage is particularly useful. It is also puzzling to sort filtering middleboxes under “passive”. 10.1: I cannot find a discussion of a “threat model” under this name in RFC 8446. 10.1: This section starts using the term “host” as a noun with a distinguishing quality that in this document is probably related to server_name, but not explained (“host” as a noun does not occur in RFC 8446). 10.2 appears to address integrity only, where the heading might suggest some discussion about confidentiality. I don’t understand the last sentence of 10.3 (“servers with high load”…). 11.3: After »A "Y" or "N" value indicating if the extension is TLS WG recommends that the extension be supported.« — can’t parse »Adding a value with a value of "Y" requires Standards Action .« -- s/value/registration/ ? 10.11: I would have expected a brief discussion on how granularizing the padding to 32 byte steps cannot be used by an attacker to extract information beyond that granularity (by causing the client to vary the size before padding, straddling a step). ## Nits Please do a pass of replacing “which” with “that” where a restrictive clause is intended (usually easy to find by the lack of a comma, about two dozen occurrences) Thank you for the many section references; two more could be used in »
Note that, if the cookie includes a key name, analogous to Section 4 of« and »
RFC8446]) when ECH is negotiated.« There are at least 17 occurrences of ‘bytes’ for counting lengths in bytes and 3 of ‘octet’/‘octets’. Please expand HRR on first use. Please define “ECH key” (8 occurrences) and “ECH record” (5 occurrences). Please define “application profile” and “application profile standard” (10.4 uses “application using (D)TLS” — is that the same?) 1: »the SNI remains the primary explicit signal used to determine the server's identity.« -- used by whom? Figure 2 uses private.example.com in the second variant where private.example.org is used in the first; may want to use .org here as well 5: it is slightly surprising that the definition list explaining config_id and cipher_suite does this in an order different from the TPL in the figure above 5.1: The first figure has a cliff-hanger (length_of_padding); maybe add a reference to 6.1.3. 5.2: »This value does not include Handshake structure's four-byte header in TLS,« 6.1.1: »Including ClientHelloOuterAAD as the HPKE AAD binds the ClientHelloOuter to the ClientHelloInner, this preventing attackers« s/this/thus/ ? 6.1.3: »through -their length« 6.1.3: »that have sensitive-length fields« (hyphen ➔ space) 6.1.6 »yield a tracking vector« — for whom? ➔ supply the server with a tracking vector? 6.1.7: »reference identity« -- define? 6.1.7: »(e.g. [RFC3986], Section 7.4 and [WHATWG-IPV4])« The "and" does not work here 6.2.2: »Correctly-implemented client will ignore those extensions.« 10.9: could use superscript in place of 2^64 (This of course only applies to usage in text, which seems to be the only one here.) 10.10.4: »out-of-scope. including, « I assume “page” in 11.3 is what is now called “registry group”?