On Sun, Mar 12, 2017 at 8:09 PM Martin Thomson <martin.thom...@gmail.com> wrote:
> On 13 March 2017 at 10:55, Brian Smith <br...@briansmith.org> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
