On Sun, Jul 03, 2016 at 06:00:25PM -0700, Eric Rescorla wrote: > I believe that this is the right design. > > The primary proposed use for EncryptedExtensions in the 0-RTT flight is for > EncryptedSNI. However, I don't believe that they are actually that useful in > this case because the design constraints for EncryptedSNI are intended to > allow the client to encrypt the SNI to a gateway but encrypt the traffic to > the hidden server, which means that you want the SNI to be protected with > gateway keys, not the terminal traffic keys. > > This design still allows two fairly elegant EncryptedSNI designs: > > - Stuff a self-encrypted value of the SNI into the ticket label (due to > Cedric Fournet).
Just beware of replay on the server side (figured out recently why encrypted SNI is actually so nontrivial...) > - Establish a ticket to the gateway server and then encrypt the ClientHello > that is destined for the hidden server in the 0-RTT early data flight to > the > gateway, which deciphers it and passes it to the hidden server, which > responds with the ServerHello (due to Martin Thomson) > > Both of these are more flexible than SNI in EE. This seems to assume that the final server supports TLS 1.3 + that TLS 1.3 has hidden record types... At least if one wants to avoid double encrypt/ decrypt. Extending to case where the final server is TLS 1.2 (or if TLS 1.3 removes hidden record types) and not doing full second encryption/decryption seems at least a bit harder.. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
