Ivan Ristic <ivan.ris...@gmail.com> 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/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
