Draft: draft-ietf-tls-esni

Commentary: cc 
 ( Filing this as a separate ticket so I do n't forget to propose new text . ) 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 is n'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 do n't know which previous connection it was , and you do n'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 ( 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 I do n't think most applications would consider ECH vs non - ECH a correlation boundary w.r.t . the server itself . ) 
 The original text does n'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 do n'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 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 do n't let you link connections , only , as you say , whether or not resumption occurred . That single boolean does n'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 do n'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 !
Paragraph (version A):
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.
Paragraph (version B):
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.  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.