On Mon, Jul 4, 2016 at 5:51 AM, Ilari Liusvaara <ilariliusva...@welho.com> 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
