There is interest in using TLS 1.3 and QUIC for communication in space
-- partly for reason such as "reusing off the shelf components". But
this is not the typical Internet environment. The transmission delays
can be very long: a few seconds between Earth and Moon, from a few
minutes to tens of minutes between Earth and Mars. 0RTT is a great fit
for these scenarios -- one really wants to not wait another RTT before
sending data. But we do have a problem, because of the ways
implementations implement anti-replay of resumption tickets using the
"freshness tests" defined in section 8.3 of RFC8446.
The code is described as:
adjusted_creation_time = creation_time + estimated_RTT
expected_arrival_time = adjusted_creation_time + clients_ticket_age
If the expected_arrival_time is too far back in time, the session may be
resumed, but 0RTT should be disabled. The recommended value for the that
test "for clients on the Internet" is "on the order of ten seconds".
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.
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.
There is a secondary issue when delays are not just long but also
variable. That could happen if the session is resumed on a different
path, which could well be minutes shorter or longer than the original
path over which the ticket was received. If the delays are shorter and
the server adjusted for the longer delays, the expected_arrival_time
will be before the current time at the server, and the sanity check will
reject the ticket. If the delays are longer, the freshness test will fail.
I am wondering what the proper fix should be.
-- Christian Huitema
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
