2
$\begingroup$

In RFC, I only find such description:

This addition prevents passive observers from correlating connections unless tickets are reused

ticket_age_addis generated randomly and obfuscated_ticket_ageis computed by adding obfuscated_ticket_age to aging time of ticket.

In my opinion, cause the PSK is sent in plaintext and it need contain the aging time which is also in plaintext, man-in-middle may know the aging time of this ticket, so we need use obfuscated_ticket_age not the aging time directly.

Question1:
If we don't want the man-in-middle know the aging time,we can remove the obfuscated_ticket_age simply, right? Why the server need this information ?Just using it to check the ticket's real lifetime ?

Question2:
If the client using the ticket's real aging time not the obfuscated_ticket_age, what is the harm for endpoints if a man-in-middle knows the the ticket's aging time ?

$\endgroup$
3
$\begingroup$

The point of these parameters is to encode the time since the ticket was issued. This time is necessary so that a server can bound its risk of 0-RTT replay to a moderately narrow window. The main problem with 0-RTT is the potential for a ClientHello and subsequent 0-RTT data to be captured and replayed.

If a client's 0-RTT ClientHello is replayed, having the time since the ticket was issued allows the server to reject 0-RTT quickly when the time is too far different from its own expectations. This limits the time over which a ClientHello can be replayed, making other anti-replay techniques more feasible. For instance, a server might remember every ClientHello it receives over a short interval, though more efficient mechanisms are definitely possible.

When a server receives a ClientHello with 0-RTT it can use the obfuscated_ticket_age to determine how old the ticket is from the client perspective. The server compares this with its own view of the ticket age - it remembers the time it issued the ticket and the value of ticket_age_add and can use those values to recover both its own view of elapsed time and that of the client. (A server might also remember an estimate of the round trip time between it and a client to allow for transit delays in its assessment.)

If the two times differ by too much, the server can reject 0-RTT quickly and efficiently. The server needs to allow a little slack for things like relative clock drift, errors in its estimation of the round trip time, and retransmission delays from the transport protocol. Values like 5 to 10 seconds either side are expected.

The ticket_age_add field is a simple form of encryption, equivalent to a one time pad. ticket_age_add is a random value (or hard-to-guess pseudorandom value) that is added to the elapsed time from the client. This encryption ensures that the client doesn't expose the time since the ticket was issued to anyone but the server. If this wasn't obscured in some way, passive observers might use the time to link this connection attempt with a previous connection. This value is added to the actual time that has elapsed (modulo 232) to get obfuscated_ticket_age.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.