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). - 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. Absent strong objections, I intend to merge this PR on Wednesday. -Ekr On Sun, Jun 26, 2016 at 6:33 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 27 June 2016 at 02:34, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > That's the reason it is XOR'd currently, but the XOR probably will > > be changed to ADD32 to break correlation-to-parent (which is really > > nasty privacy-wise) in case of ticket reuse. > > Let's not make that probably. I've updated the PR. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
