Change:
There are many sorts of TLS middleboxes (CDN, decrypting proxy, local antivirus, actual attack, etc), with acceptabilities ranging from reasonable to extremely questionable to a terrible idea. (Categorization is left as an exercise to the reader.) They also have very different security considerations. Fundamentally, TLS secures a connection between two endpoints. As such, we have something to say about the endpoint-to-endpoint connections that make up such a system, but we shouldn't imply this section is sufficient, merely necessary. Adjust the text accordingly. I wrote "intermediary" in the original PR, predictively based on PR . Since the spec seems to have settled on "middlebox", align the terminology. (I don't really care what is used, just that it is consistent.)
Ah yeah. Fixed. I used "implementations" for this one because there is an "(also known as ossification)" parenthetical and, in the general case, endpoints can cause ossification too. Even here, I dunno, maybe a sufficiently confused endpoint will do something silly there. :-)
Should the legacysessionid description, which also mentions intermediaries, also be tweaked?Thanks!

Discussion:
In compatibility mode (see middlebox) this field MUST be non- empty, so a client not offering a pre-TLS 1.3 session MUST generate a new 32-byte value.  This value need not be random but <del> SHOULD be unpredictable to avoid but SHOULD be unpredictable to avoid intermediaries fixating on a specific value (also known as ossification).  Otherwise, it MUST be set as a zero length vector (i.e., a single zero byte length field). </del> <ins> SHOULD be unpredictable to avoid implementations fixating on a specific value (also known as ossification).  Otherwise, it MUST be set as a zero length vector (i.e., a single zero byte length field). </ins> This is a list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including

9.3. <del> This section describes invariants that TLS endpoints and intermediaries MUST follow.  It also applies to earlier versions, which assumed these rules but did not document them. </del> <ins> This section describes invariants that TLS endpoints and middleboxes MUST follow.  It also applies to earlier versions, which assumed these rules but did not document them. </ins> TLS is designed to be securely and compatibly extensible.  Newer clients or servers, when communicating with newer peers, SHOULD negotiate the most preferred common parameters.  The TLS handshake <del> provides downgrade protection: Intermediaries passing traffic between a newer client and newer server without terminating TLS should be </del> <ins> provides downgrade protection: Middleboxes passing traffic between a newer client and newer server without terminating TLS should be </ins> unable to influence the handshake (see security-handshake).  At the same time, deployments update at different rates, so a newer client or server MAY continue to support older parameters, which would allow

1.3, a client receiving a CertificateRequest or NewSessionTicket MUST also ignore all unrecognized extensions. <del> An intermediary which terminates a TLS connection MUST behave as a </del> <ins> A middlebox which terminates a TLS connection MUST behave as a </ins> compliant TLS server (to the original client), including having a certificate which the client is willing to accept, and as a compliant TLS client (to the original server), including verifying

understands, and it MUST generate a fresh ServerHello random value, rather than forwarding the endpoint's value. <del> In this scenario, the intermediary is a pair of TLS endpoints for purposes of protocol requirements and security analysis. </del> <ins> Note that TLS's protocol requirements and security analysis only apply to the two connections separately.  Safely deploying a TLS terminator requires additional security considerations which are beyond the scope of this document. </ins> <del> An intermediary which forwards ClientHello parameters it does not </del> <ins> An middlebox which forwards ClientHello parameters it does not </ins> understand MUST NOT process any messages beyond that ClientHello. It MUST forward all subsequent traffic unmodified.  Otherwise, it may fail to interoperate with newer clients and servers. Forwarded ClientHellos may contain advertisements for features not <del> supported by the intermediary, so the response may include future TLS additions the intermediary does not recognize.  These additions MAY change any message beyond the ClientHello arbitrarily.  In particular, the values sent in the ServerHello might change, the ServerHello format might change, and the TLSCiphertext format might change. </del> <ins> supported by the middlebox, so the response may include future TLS additions the middlebox does not recognize.  These additions MAY change any message beyond the ClientHello arbitrarily.  In particular, the values sent in the ServerHello might change, the ServerHello format might change, and the TLSCiphertext format might change. </ins> The design of TLS 1.3 was constrained by widely-deployed non- <del> compliant TLS intermediaries (see middlebox), however it does not relax the invariants.  Those intermediaries continue to be non- compliant. </del> <ins> compliant TLS middleboxes (see middlebox), however it does not relax the invariants.  Those middleboxes continue to be non-compliant. </ins> 10.