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

[Ivan Ristic <[e-mail]>]

The "ticket" field in NewSessionTicket is opaque and can hold an identifier
or an actual encrypted ticket. I think this is problematic, for a couple of
reasons:

- Field and meaning overloading/reuse is a bad practice in general and
leads to programming errors. I feel that protocol design should encourage
good practices, not the other way round. Implementations that decide to
support both behaviours (IDs and tickets) will have to use an indicator to
differentiate between the two. In that light, I think it would be less
error prone to provide more detail at the protocol level.

- The opaque nature of this field also makes connection auditing more
difficult. For example, I'd like to know if session tickets are used to
resume for a particular connection. Perhaps more importantly, it would be
useful to identify specific ticket keys (to track their usage, rotation,
etc), age, encryption algorithm, and their strength.

- As a matter of approach, I think the protocol shouldn't leave design
decisions to implementors. These decisions (session ID/ticket usage, ticket
keys, ticket formats, and so on) will need to be made, and I think it's
better to make them part of the protocol, where they can be audited, etc.

- Finally, I feel that the effective removal of (visible) session IDs is a
regression. Being able to track sessions and resumption is useful to
understand traffic patterns. So, I'd prefer to bring session IDs back, and
to arrange things so that they're always server-generated.

I know these are not big problems (especially given the improvements made
to session tickets), but whatever is specified now will be used for a very
long time, and it would be a shame to leave these around.

-- 
Ivan