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

[Brian Smith <[e-mail]>]

Ivan Ristic <[e-mail]> wrote:
> - The opaque nature of this field also makes connection auditing more
> difficult.

This is intentional.

> 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.

The server knows this information. if it wants you to know it, then it
can share it with you. If it doesn't, then you shouldn't be able to
know it, ideally.

> - 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.

This is an attack on the client and server, which the protocol ideally
should prevent. In fact, I know at least one implementation is doing
extra work specifically to frustrate this kind of attack. Also the
charter says "Develop a mode that encrypts as much of the handshake as
is possible to reduce the amount of observable data to both passive
and active attackers."

> 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.

> 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.

This I agree with, except I think it's worth spending extra effort to
standardize the methods for preventing the thing you are asking for.

BTW, I understand you are asking for this for diagnostic reasons, not
for malicious reasons.

Cheers,
Brian
-- 
https://briansmith.org/