There is an ongoing discussion on the QUIC issue tracker that might benefit from some attention here.
https://github.com/quicwg/base-drafts/issues/1834 Of most interest here is that there is no mechanism by which a TLS endpoint can limit the size of handshake messages. This wasn't a problem prior to TLS 1.3, renegotiation notwithstanding, but if an endpoint needs to buffer a 16Mb message it will probably be unhappy. And many TLS implementations buffer. Knowing where short of 16Mb is safe to send is tricky. Right now, all we do is rely on the natural pressure to keep tickets small and the fact that tickets are pure overhead to keep things under control, but it's a hole that is a little irritating to leave unpatched. Of secondary concern for QUIC and DTLS, but not TLS, is the total amount of data that can be sent in handshake messages. If that data arrives out of order, it would be nice to bound the amount of memory that is apportioned for receiving and reassembling handshake messages. I mention this only because the same solution might be used to fix both problems. (I was motivated to post this after reading the ticket requests draft from Chris, which we should publish. That draft doesn't run really cause this problem, but it made me think that 255 tickets might make a bit of a mess if sent all at once.) _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
