Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Jul 2016 18:00:25 -0700

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 <[email-masked]>
wrote:

> On 27 June 2016 at 02:34, Ilari Liusvaara <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 4 Jul 2016 15:51:28 +0300

On Sun, Jul 03, 2016 at 06:00:25PM -0700, Eric Rescorla wrote:
> Cedric Fournet).

Just beware of replay on the server side (figured out recently why
encrypted SNI is actually so nontrivial...)

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Jul 2016 06:30:09 -0700

> has hidden record types... At least if one wants to avoid double encrypt/

Yes.

> hidden record types) and not doing full second encryption/decryption seems

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

-Ekr