+ TLS WG On Fri, Feb 19, 2016 at 8:46 AM, Eric Rescorla <[email protected]> wrote:
> > On Fri, Feb 19, 2016 at 8:01 AM, Salz, Rich <[email protected]> wrote: > >> I greatly prefer one way to do things. (Python not perl, if you will :) >> >> On the other hand, there is an elegance about using a single >> well-understood mechanism even if it has operational burdens. We all know >> how to secure PSK material, though, right? :) But what dose this do about >> encrypted-SNI? >> > > Funny you should mention that. There's actually a very elegant way to do > encrypted > SNI here (due to Cedric Fourney). The basic idea is that you initially > contact the hidden > server and do a TLS handshake establishing a ticket. That ticket actually > has two parts: > > - The ordinary ticket > - The identity of the hidden cipher enciphered for the gateway > > Then when you connect to the gateway, you do an apparent PSK+(ECDHE) > handshake with it and provide the ticket. It unwraps the identity of the > hidden > server and then forwards the ClientHello to the hidden server for > processing > and the rest of the handshake just completes as normal, but with the hidden > server [0]. And because each handshake provides a new ticket, this > is unlinkable. > > The major drawback of this design is that the first ticket establishment > requires > contacting the hidden server, but you can either do this directly (as we > have > been assuming) or just tunnel through the gateway the first time with > TLS-in-TLS. > > -Ekr > > [0] I originally thought this might need a change to the ticket signaling > mechanism, but I'm less sure that that's true. In any case, that should > be minor. > > >> -- >> Senior Architect, Akamai Technologies >> IM: [email protected] Twitter: RichSalz >> >> >> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
