I more or less concur with Brian and Martin. I do think it would be worthwhile for someone to document a ticket construction that's more modern than the one in RFC 5705, but I don't think implementations should be required to implement any particular format.
-Ekr On Sun, Mar 12, 2017 at 4:55 PM, Brian Smith <br...@briansmith.org> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
