Draft: draft-ietf-tls-esni

Commentary: Now that we 've switched to encrypting the entire ClientHello , there 's nothing wrong with cachedinfo in ClientHelloOuter , provided it 's based on the public name rather than the inner name . And , more generally , name - specific extensions take some care . Replace the prohibition with more general guidance in Security Considerations , with cachedinfo merely being an example . This addresses issue . 
 The current draft contains various rules around ECH and resumption . These rules date to before we started encrypting the entire ClientHello and were intended to avoid mixing up session resumptions between the public and private name , since the same presharedkey extension was used for both , and amount to saying implementations must add a boolean to their session state . Now that the public and private names correspond to different ClientHellos altogether , the client can ( and should ) only send inner name tickets in the inner ClientHello and outer name tickets in the outer ClientHello . ( ) I suspect that means we no longer need further ECH special cases here . 
 This seems like a good simplification , but we should probably be careful about the interaction with cross - SNI resumption . 
 I think it just composes as expected ? If you offer a PSK in the outer ClientHello , cross - SNI or no , it means that you are satisfied with it as an alternative to the certificate covering the public name . If you offer a PSK in the inner ClientHello , cross - SNI or no , it means you are satisfied with it as an alternative to the certificate covering the true name . Your ClientHellos should be consistent with this , which means that servers resuming is n't an issue . TBH I forgotten some of the details for why this was here . I found this long comment I wrote , but apparently past me was just unsatisfied that a case ( 4 ) was " weird " . So that was very unhelpful , past me . Regardless , I think the ambiguity is moot now . ( I also expect clients just wo n't offer PSKs in the outer  . It 's unlikely that you 'll get any to offer anyway . And if your API has an external session cache , the caller needs to go out of their way to do two lookups . ) 
 I was thinking about clients that might mistakenly use inner tickets for the outer name when given the cross - SNI signal . ( I agree that it composes naturally . ) A simple note would probably suffice . For outer tickets , I tend to think they should just be discouraged . What 's the benefit of resuming a TLS 1.3 connection you 'd tear down anyway ? 
 I 'm not sure I fully understand the ( historical ) need to distinguish between ECH - PSKs and non - ECH - PSKs . But why would a client offer PSK to a client - facing server at all ? In other words , will it ever be useful to send a PSK extension in the ClientHelloOuter ? It seems to me that this feature is only meaningful to the intended backend server , and so should only appear in the ClientHelloInner . The same question applies to all other extensions . If the client - facing server terminates the connection , then the only action the client will take is to close the connection . Hence , the only functionality we will ever need for the client<-client - facing server connection is to complete a full , server - authenticated handshake . If I were implementing the client , I would restrict the contents of the ClientHelloOuter to only those extensions that are necessary to implement this functionality . I wonder if it makes sense to enforce this in the spec . Something like : " When offering the ' ech ' extension , the client MAY include the following extensions in the ClientHelloOuter : ' supportedversions ' , ' servername ' . ' keyshares ' , ' signaturealgorithms ' , [ and so on ] . It MUST NOT include any other extension . " What are the downsides to doing something like this ? I think the upside is that it simplifies the problem of deciding what to put in the ClientHelloInner versus the ClientHelloOuter . I suppose one downside is that it potentially sticks out a bit . 
 Based on this week 's interim , we decided it was fine to prohibit PSKs in the outer CH for ECH connections , so the current draft text prohibits " presharedkey " extensions in the outer CH . A connection using GREASE may , however , decide to resume its connection to the outer name . This gives a passive adversary a pretty easy distinguisher between GREASE and non - GREASE : if there 's a ticket present , the connection is definitely GREASE . It seems that if we want to maintain our current indistinguishability properties , there always needs to be some ticket . So perhaps that means : ECH ( non - GREASE ) clients would generate a bogus ( GREASEd ) ticket GREASE clients that do n't have a ticket would generate a bogus ticket GREASE clients that have a ticket would use it penny for your thoughts ? 
 I mostly figure there wo n't be a ticket in the initial connection to a server , or any connections made after long time , so intolerance to ticket - less ClientHellos will likely be noticed quickly . Though it is true that probably a lot of connections offer tickets . There may be something to be said for allowing clients to send bogus tickets if they want , but it 's worth noting an active attacker can tell if the ticket is ( most likely ) bogus by simply trying to resume it . ( A tangent : we actually saw a very old TLS 1.0 server implementation that broke with TLS 1.3 because it would take the client 's session IDs and unconditionally echo it back . I 'm not sure what was going on there . It did n't actually switch to a resumption handshake or implement resumption at all . It just echoed back the session ID for some reason . Only reason this did n't break before was that it never issued session IDs , so this codepath had never been tested before . ) 
 True , but that 's already the case for active attackers . What I 'm concerned about are passive attackers . 
 I think this gets at a larger " do n't stick out " problem currently only addressed in bits and pieces . Just as dummy ( i.e. , greased ) ECH is used to provide covertext for real ECH , real - ECH connections also need to provide covertext for the real extensions offered in dummy - ECH connections . In particular , the spec should provide guidance on how to generate dummy extensions in the ClientHelloOuter . 
 Section 7.1 provides a bit of guidance on how ECH might interact with other extensions : " servername " extension . The ClientHelloOuter MUST NOT contain a " cached_info " extension { { ! RFC7924 } } with a CachedObject entry whose CachedInformationType is " cert " , since this indication would divulge the true server name . The remaining contents of the ClientHelloOuter MAY be identical to those in ClientHelloInner but MAY also differ . I think it 's worth expanding on this in " Security Considerations " . There may be other ways that private CH extensions get leaked , now or in the future . 
 Now that we 've switched to encrypting an entire ClientHello , I think the text wants to say something else anyway : if you want ECH + cached info , you simply include the cachedinfo extension in the ClientHelloInner , not the ClientHelloOuter . There would n't be much point in sending a true name cachedinfo in ClientHelloOuter since the true server would ignore it . Sending a public name cached_info in ClientHelloOuter is also plausible and also need n't be forbidden ( it reveals information about the public name , which is public ) . It 's also probably not that useful since it 's just a recovery mechanism , but maybe to avoid sticking out , for clients that normally send it ? More generally , anything dependent on the inner name goes in ClientHelloInner and not ClientHelloOuter . 
 I took a stab at replacement text in Thoughts ? 
 I 'm happy with it .
Paragraph (version A):
The client MUST place the value of "ECHConfig.public_name" in the
ClientHelloOuter "server_name" extension.  The ClientHelloOuter MUST
NOT contain a "cached_info" extension RFC7924 with a CachedObject
entry whose CachedInformationType is "cert", since this indication
would divulge the true server name.  The remaining contents of the
ClientHelloOuter MAY be identical to those in ClientHelloInner but
MAY also differ.
Paragraph (version B):
The client MUST place the value of "ECHConfig.public_name" in the
ClientHelloOuter "server_name" extension.  See outer-clienthello for
additional discussion of ClientHelloOuter values.
Paragraph (version B):
Any information that the client includes in the ClientHelloOuter is
visible to passive observers.  The client SHOULD NOT send values in
the ClientHelloOuter which would reveal a sensitive ClientHelloInner
property, such as the true server name.  It MAY send values
associated with the public name in the ClientHelloOuter.
Paragraph (version B):
In particular, some extensions require the client send a server-name-
specific value in the ClientHello.  These values may reveal
information about the true server name.  For example, the
"cached_info" ClientHello extension RFC7924 can contain the hash of a
previously observed server certificate.  The client SHOULD NOT send
values associated with the true server name in the ClientHelloOuter.
It MAY send such values in the ClientHelloInner.
Paragraph (version B):
Values which are independent of the true server name, or other
information the client wishes to protect, MAY be included in
ClientHelloOuter and compressed as described in outer-extensions.