Original text:
SHOULD take steps to minimize or protect such requests during certificate validation.  10.7. To signal acceptance, the backend server overwrites 8 bytes of its

Reviewer comments:
Addresses
Done. Thanks!
(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.
Martin pointed out a potential SNI leak via resumption under the following conditions: A client connects to server "A" without ECH, and receives a session ticket. The client later resumes the connection to server "A" using ECH. An observer can see that a PSK was accepted (via SH containing presharedkey). If any of the hosts previously visited by the client are known, an attacker can do a lookup of each for a config_id matching the resumed session. This effectively reduces the size of the anonymity set for a particular client/victim. While it's true that the hostname is already leaked by the first connection without ECH, this seems to violate the security goals as they are written. We used to require separation between non-ECH and ECH PSKs, but it was removed in .
Ah fun. I agree that observing a resumption does increase the probability the connection was one of the previous non-ECH connections the client made, when server just deployed ECH. (Though the client could also be visiting someone else in the anonymity set for a second time.) I'm not sure I follow what's going on in (3) though. Is that just checking if one of the previously-visited hosts shares a client-facing server with the connection under attack? That seems like something the attacker can regardless. (With or without resumption, one would expect a client's visited sites pre-ECH-deployment to somewhat predict with the ones post-ECH-deployment.) As an aside, even if SH.presharedkey was hidden, the observer can infer resumption based on whether the server responded with a lot of data (it sent a certificate in there), or very little data (it sent no certificate in there). Unless the server adds some truly wasteful padding on resumption connections.
(3) just provides additional evidence that the SNI guess is correct (by further constraining set of possible hostnames).
To mitigate this, it ought to be sufficient to have the client track whether a given PSK was established ruing a ECH handshake or a non-ECH handshake. It seems like this would be a lot more involved for a server to manage.
Is it actually additional evidence? It doesn't seem to narrow the usual ECH anonymity set, just identifies it. If I understand you correctly, (3) is: The attacker observes a connection from the client with some configid and some secret SNI A. The attacker queries DNS or the recovery flow[] for the cleartext SNIs that the client previously visited and sees if one of them, B, has an ECHConfig with matching configid. If there is a match, the attacker learns that B was in the same anonymity set as A. The attacker learns this whether or not the connection resumes. The attacker also hasn't expanded the anonymity sent. In fact, they didn't even need to query sites the client previously visited. They could just as easily query the top N sites or a list of popular hosting providers known to support ECH. I think this information is part of the baseline for our security goals. It is true that a client which, before ECH, leaked that it visited A many times is more likely to visit A again in the future. That seems fundamental. I think the interesting thing is that (2) tells the observer that it is some repeat visit, which increases the chance it's A. (But doesn't guarantee it. Maybe I've found a new site in the anonymity set that I like.) I don't think PSK separation even mitigates this. Repeat post-ECH visits still reveal whether resumption happened in ServerHello. And even if we fixed that, depending on how much padding the client is willing to add, the ClientHello size will reveal whether the client had a ticket to offer. I think the only thing PSK separation mitigates is that immediately after the client/server pair deploys ECH, you get to reset the repeat visit counter. But once you count to 2 again, you've got the same signal as before. [*] Although there's no actual requirement that the recovery flow use the same ECHConfig as the long-lived DNS config...
Well no, but since they have that information, they can further reduce the anonymity set. (The attacker doesn't need to consider the sites the user never visited.) As soon as you involve non-ECH in a session, the security guarantees just don't hold. I'm fine with just being explicit about that in the draft.
That's probably the best way to resolve this, given the impracticality and constraints (to time of deployment or enablement). I'll have a PR up by the end of the week.
That works for me. Thanks, NAME
This LGTM. I have a slight rephrasing, but feel free to reject!

Revised text:
SHOULD take steps to minimize or protect such requests during certificate validation. <ins> 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 later resume a connection to that same host after ECH deployment, thereby linking the resulting ECH connection to the original non-ECH connection. </ins> 10.7. To signal acceptance, the backend server overwrites 8 bytes of its