Draft: draft-ietf-tls-esni

Commentary: Addresses 
 Done . Thanks ! 
 ( 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 . 
 Martin pointed out a potential SNI leak via resumption under the following conditions : client connects to server " A " without ECH , and receives a session ticket . client later resumes the connection to server " A " using ECH . An observer can see that a PSK was accepted ( via SH containing presharedkey ) . 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 does n'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   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 has n't expanded the anonymity sent . In fact , they did n'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 does n't guarantee it . Maybe I 've found a new site in the anonymity set that I like . ) I do n'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 does n't need to consider the sites the user never visited . ) As soon as you involve non - ECH in a session , the security guarantees just do n'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 , 
 This LGTM . I have a slight rephrasing , but feel free to reject !
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,
thereby linking the resulting ECH connection to the original non-ECH
connection.