Draft: draft-ietf-tls-esni

Commentary: This should probably land after . cc 
 I do n't know the answer to this question , but , from the TLS 1.3 RFC : I noticed this while testing with a pre - baked ClientHello that had both extensions . The ECH draft clearly required that the extension be removed , but I wondered about . 
 Given , , and , I 'd say quite the opposite . 
 Ah , I see text has been saying it must appear in the ClientHelloOuter . Thanks for the references . I was working from draft-10 . 
 Here 's a fun case . Suppose the client talks to a 0 - RTT - capable , ECH - capable server . It 'll send earlydata + presharedkey in ClientHelloInner , wrap that in some ClientHelloOuter , and follow it up with early data records . Now the server rejects ECH and handshakes with the ClientHelloOuter . But the client has already sent early data , so the server needs to know to skip past it . I believe this means we need to require the client mirror ClientHelloInner.earlydata in ClientHelloOuter , even though it 's not actually offering to resume anything . Sending earlydata without presharedkey is slightly weird ( if tolerated at all ) , so we might even want to recommend a fake outer presharedkey . We almost _ do n't care about this : the client may as well stop the handshake at server Finished and skip the client Finished flight anyway , for purposes of the recovery flow . However : What 's not what the draft currently says If the server rejects ECH , handshakes with ClientHelloOuter , and sends HelloRetryRequest , we do care about the client 's second flight getting through . That second case is extra fun because the client - facing server must look for the second ClientHello too . 
 Was n't this already the outcome from ? ( That is , if the inner CH has a PSK , then the outer one ought have a dummy PSK , too . ) As for mirroring earlydata , why can the server not just ignore the application data ( as if it received earlydata and decided to ignore it ) ? Taking a quick look back at RFC8446 , the server behavior where clients send application data without earlydata is not defined , so are you concerned about that , or something else ? 
 Well , I think we only got as far as MAY in , but yeah I think this is another reason . Regarding ignoring application data , our server implementation only skips early data if there was an early_data extension that we rejected . I believe that matches RFC8446 since it does n't say to skip application data in general , just that case . And , yeah , that 's the concern . 
 Since this is behavior for the client - facing server , which supports ECH , ca n't we specify the desired behavior in this spec ? That is , we might say that a client - facing server which rejects ECH MUST ignore any early data sent by the server , or something . Would that work ? 
 We could , but then it 'd break the nice property that a plain RFC8446 server will handshake ClientHelloOuter without any fuss . This property is great for rollback safety . ( Otherwise any ECH server deployment needs to be two - stage , and introduces a lower bound that you can not rollback beyond . ) And elsewhere we 've tried to avoid contradicting RFC8446 . Yet another option would be to tell the client to retry on certain kinds of errors if it offered 0 - RTT in ClientHelloInner , but that 's a bit more fuss since retries are often outside the TLS stack . ( Besides , the fact that you offer 0 - RTT in ClientHelloInner is all but public anyway . While we do n't have a cleartext 0 - RTT marker [ ] , it 's pretty obvious from timing that some post - ClientHello record came before ServerHello . ) [ ] In TCP ... I want to say QUIC does , but I could be misremembering . 
 True ! This is fun . :-) 
 I 'm not sure why ignoring stuff is fuss . What 's the alternative ? To terminate the handshake if the server receives early data ? Would n't that be more fuss ? If RFC8446 does n't specify what to do in this situation , I 'm not sure why specifying it is in contradiction to RFC8446 ( as opposed to expanding on it ) . 
 I think RFC8446 does say what to do in this situation . Section 5.2 says at the bottom : The default for the record layer is that decryption errors are fatal ( as it should be ) . Early data skipping is an exception to this described in section 4.2.10 , and the exception only applies when the server declines an earlydata extension . Oh no , the goal is to ignore stuff . That 's what makes the recovery flow work . The issue is that , in RFC8446 , servers only ignore the early data if there was an earlydata extension in ClientHello which they declined . Otherwise , it 's just a fatal decryption error . In order to meet that condition , ClientHelloOuter needs the early_data extension whenever ClientHelloInner does . 
 ACK -- thanks for closing the loop !
Paragraph (version B):
When the client offers the "early_data" extension in
ClientHelloInner, it MUST also include the "early_data" extension
in ClientHelloOuter.  This allows servers that reject ECH and use
ClientHelloOuter to safely ignore any early data sent by the
client per RFC8446, Section 4.2.10.