>Of secondary concern for QUIC and DTLS, but not TLS, is the total amount of >data that can be sent in handshake messages.
The total amount of data sent in the TLS handshake is quite a big concern when TLS is used in EAP-TLS. Many authenticator (access point) implementations will drop the EAP session if it hasn't finished after 40 - 50 packets or approximately 60 kB. 255 tickets would make many EAP-TLS session to fail, but the suggested mechanism where the client indicates the desired number of tickets seems good. Cheers, John -----Original Message----- From: TLS <[email protected]> on behalf of Martin Thomson <[email protected]> Date: Tuesday, 30 October 2018 at 05:50 To: "[email protected]" <[email protected]> Subject: [TLS] TLS message limits 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 _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
