Re: [TLS] Remove EncryptedExtensions from 0-RTT

[Ilari Liusvaara <[e-mail]>]

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