On Thu, Jan 11, 2024, at 11:07, Christian Huitema wrote: > One first problem with this code is that implementations may or may not > have an estimate of the RTT when they are issuing the ticket. In theory > the server could measure the RTT by comparing the send time of the > server first flight and the arrival time of the client's second flight, > but that's extra complexity and implementations may well skip that test.
This seems like a pretty easy thing to measure. It's what I implemented for NSS. I don't think that you should assume that people won't do that. > In theory, the client could compensate the clients_ticket_age to include > the RTT, but that's risky. If the client is connecting to a server > implementation that does adjust the ticket creation time, the adjusted > client time will be found larger than the current time at the server. > Servers may well test for that, reject the ticket and fall back to 1RTT. Compensating for the RTT estimate is possible (again, I can attest to this being easy to implement), but the problem is that you also need to account for a larger RTT variance when RTT increases. For that, it is not so easy as the more obvious mechanisms for tracking anti-replay need to be globally configured, not driven by per-connection parameters. If you have clients with 1s RTTs coexisting with those that have RTTs measured in minutes, the configuration needs to be different. See https://searchfox.org/mozilla-central/rev/b1a029fadaaabb333d8139f9ec3924a20c0c941f/security/nss/lib/ssl/sslexp.h#187-194 (which doesn't talk about RTT variance, but it should). If you know about a population of clients with high variance, you can build allowances in, but I don't have a general solution. However, allowing for that variance comes with a cost in terms of state space, especially if you have to allow for high connection rates. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
