Re: [TLS] Remove EncryptedExtensions from 0-RTT

[Eric Rescorla <[e-mail]>]

On Mon, Jul 4, 2016 at 5:51 AM, Ilari Liusvaara <[e-mail]>
wrote:

> 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.
>

Yes.


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..


Agreed. I am happy to punt the first case, and I don't sense enthusiasm for
removing the second case.

-Ekr


>
>
>
> -Ilari
>