Re: [TLS] Comments on the session ticket format in TLS 1.3

[David Benjamin <[e-mail]>]

On Sun, Mar 12, 2017 at 8:09 PM Martin Thomson <[e-mail]>
wrote:

> On 13 March 2017 at 10:55, Brian Smith <[e-mail]> wrote:
> >> So, I'd prefer to bring session IDs back, and
> >> to arrange things so that they're always server-generated.
> >
> > Even in earlier versions, session IDs were not required with
> > resumption using tickets. The server sends an empty session ID and the
> > client may (should, IMO) send an empty session ID in the resumption
> > hello.
>
> This is true, but I believe that there are compatibility reasons to
> send the session ID anyway.  I don't know the details, but it probably
> comes down to the load balancing thing that Ivan is asking about.
>
> All told, this was a mess in previous versions.  Now we at least have
> a hope of maintaining unlinkability.
>

Clients send session IDs in TLS 1.2 because that is how the server
indicates a resumption. It echoes the client-sent ID back. Otherwise that
value has no meaning. (Go's implementation will just pick a random value
each time. OpenSSL derivatives hash the ticket.)

RFC 5077 does allow a client to leave it empty, but this is a mistake and
should not have been in the specification. That means a client must peek
ahead for ChangeCipherSpec to determine resumption. This is a huge source
of complexity (handshake/CCS synchronization is tricky as it is) and does
not work with DTLS.

David