Subject: [TLS] Remove EncryptedExtensions from 0-RTT

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Jun 2016 13:37:14 +1000

When implementing 0-RTT, an in particular the ticket_age extension, we
discovered that this greatly increases the complexity of the server
state machine.  The problem is that the server is making decisions
about what to send in the ServerHello based on the content of messages
that appear after the ClientHello.  Worse, this means that the server
is making decisions based on material that is not hashed into the
session transcript [1].

David Benjamin rather flippantly described a solution to this problem:
XOR the ticket age value with something that is either derived from
the old session keys or was included in the NewSessionTicket message.

I propose we take David's solution.  After all, simple is better:

  https://github.com/tlswg/tls13-spec/pull/503

To be clear, this means we lose the generality provided by having
encrypted extensions in the client's first flight.  I can't find a
reason to be sad about that; the only other possible use for this was
encrypted SNI, but I think we can find better ways to solve that
particular problem.

[1] This lead to ugly patches like what
https://github.com/tlswg/tls13-spec/issues/501 suggests.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Jun 2016 13:35:46 +0300

On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote:
> state machine. 

I don't see a warning that reusing a ticket with that scheme causes
the "masking" to break (the classic "multiple time pad" broken scheme).

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Thu, 23 Jun 2016 14:39:22 +0000

> the "masking" to break (the classic "multiple time pad" broken scheme).

Probably worth expanding on in the text, but the assumption here is that
EncryptedExtensions' only purpose in life was to defeat correlation. That
is, if we didn't care about that, we'd put it in the clear like other
ClientHello fields. (Which means integrity is provided by handshake
transcript, as with other ClientHello fields.)

To that end, if you were reusing a ticket, you've already leaked a more fun
correlator (the ticket) and must not have cared about leaking the
ticket_age either.

If something more heavyweight is wanted, probably better to derive some
extra key off the session key material + stuff (ought to include
client_random if worried about ticket reuse) and toss it into the cipher's
AEAD or something. It didn't seem we needed any of it, so I "flippantly"
proposed the dumbest possible thing that might work. :-)

David

---

From: David Benjamin <[email-masked]>
Date: Thu, 23 Jun 2016 15:05:54 +0000

On Thu, Jun 23, 2016 at 6:35 AM David Benjamin <[email-masked]>
wrote:

> To that end, if you were reusing a ticket, you've already leaked a more
> fun correlator (the ticket) and must not have cared about leaking the
> ticket_age either.
>

I suppose there is a slight difference from ticket reuse in that ticket
reuse correlates the resumption connections together but not the connection
which minted the ticket. The ticket age helps you correlate that initial
connection too.

I don't think this matters. Just don't reuse tickets. But, if we cared, per
the "dumbest possible thing that might work" school of thought, we can
replace XOR with addition modulo 2^32. Now ticket reuse leaks the delta
between two ClientHellos, which, precision aside, was already public
information from the receive time (with ticket as correlator). The
timestamp of the ticket-minting connection is as secret as before.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Jun 2016 06:59:28 +1000

On 24 June 2016 at 01:05, David Benjamin <[email-masked]> wrote:
> information from the receive time (with ticket as correlator). The timestamp
> of the ticket-minting connection is as secret as before.

That sounds like fine reasoning to me.  XOR or addition are both easy
enough to specify.

---

From: Subodh Iyengar <[email-masked]>
Date: Sun, 26 Jun 2016 05:34:04 +0000

Was there a compelling reason to not just put the ticket age in the clear in the CHLO field as @davidben alluded to before. It seems to make it much simpler in general.

With support for multiple tickets the server could issue multiple tickets at different times to make time correlation more difficult. The ticket seems to be a more definitive identifier of the user than the time.

Subodh
________________________________________
From: TLS [[email-masked]] on behalf of Martin Thomson [[email-masked]]
Sent: Thursday, June 23, 2016 1:59 PM
To: David Benjamin
Cc: [email-masked]
Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=ryrz7HkNEVNbEb9yKsanQ1ZrOyiVdYuv8BDMJOF55s0&s=ftTVBbImgxjUem3AV87OqX3q_RKQKE1SJ7SGePOhWyc&e=

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 26 Jun 2016 19:34:16 +0300

On Sun, Jun 26, 2016 at 05:34:04AM +0000, Subodh Iyengar wrote:
> Was there a compelling reason to not just put the ticket age in the
> clear in the CHLO field as @davidben alluded to before. It seems to
> make it much simpler in general.

Unfortunately, just putting it in plain allows correlating sessions.

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.

> With support for multiple tickets the server could issue multiple
> tickets at different times to make time correlation more difficult.
> The ticket seems to be a more definitive identifier of the user
> than the time.

There is already support for that. But without fudging the times,
correlation is still possible.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Jun 2016 11:33:06 +1000

> nasty privacy-wise) in case of ticket reuse.

Let's not make that probably.  I've updated the PR.