Original text:
Attacks that rely on non-ECH traffic to infer server identity in an ECH connection are out of scope for this document.  For example, a client that connects to a particular host prior to ECH deployment may <del> later resume a connection to that same host after ECH deployment, thereby linking the resulting ECH connection to the original non-ECH connection. </del>  10.7.

Reviewer comments:
cc NAME
(Filing this as a separate ticket so I don't forget to propose new text.) added this text: I think this statement is a bit strong and overstates the issue. It reads as if resuming connections across ECH and non-ECH links the two connections. If we're talking about someone other than the server, this isn't true. Tickets are issued encrypted and, in ECH, even sent encrypted. Even if they were sent in the clear, TLS 1.3's protects against such correlations. Rather, the correlation in is a much weaker one: based on either the size of the ClientHello or whether the server accepted the ticket, you learn a single bit for whether it was some previous connection made by that client. You don't know which previous connection it was, and you don't know if it was an ECH connection or a non-ECH connection. In fact what you learn... more-or-less aligns with the anonymity set. See URL (If we're talking about the server, yes, resuming allows the server to link the two connections. That's fundamental to resumption and is in the purview of URL I don't think most applications would consider ECH vs non-ECH a correlation boundary w.r.t. the server itself.)
The original text doesn't necessarily imply that on-the-wire tickets are the linking factor. Rather that the shape of the handshake, time it takes to complete, etc, can be a proxy for whether or not resumption occurred. I don't think we need to change anything here. (But I also would not object to someone else sending a PR!)
(This came up in a discussion between me and NAME So, the current text says "For example, a client that [does X] may [do Y], thereby linking the resulting ECH connection to the original non-ECH connection". That implies that doing X and Y allows linking the two connections together. You're right that tickets may not be the only linking factor, but the other channels don't let you link connections, only, as you say, whether or not resumption occurred. That single boolean doesn't tell you which non-ECH connection corresponded to the ECH connection, or what the name was. It only tells you that it's the same name as some previous connection to the anonymity set. It might be a non-ECH one (but you don't know which) or it might be an ECH one.
Feel free to suggest text to reword this. I think the example was meant to be general enough to suggest that side channels exist. I definitely do not feel strongly about the exact wording here.
I agree that the text as-is overstates the issue.
Thanks!LGTM -- thanks!

Revised text:
Attacks that rely on non-ECH traffic to infer server identity in an ECH connection are out of scope for this document.  For example, a client that connects to a particular host prior to ECH deployment may  <ins> later resume a connection to that same host after ECH deployment.  An adversary that observes this can deduce that the ECH-enabled connection was made to a host that the client previously connected to and which is within the same anonymity set. </ins> 10.7.