Change:
ServerHello, rather than waiting for the client's EndOfEarlyData message. <del> 4.2.10.3. </del> <ins> 4.2.10.4. </ins> As noted in zero-rtt-data, TLS provides a limited mechanism for replay protection for data sent by the client in the first flight. <del> The "obfuscated_ticket_age" parameter in the client's "pre_shared_key" extension SHOULD be used by servers to limit the time over which the first flight might be replayed.  A server can store the time at which it sends a ticket to the client, or encode the time in the ticket.  Then, each time it receives an "pre_shared_key" extension, it can un-obfuscate the ticket age and compare it to the difference between the current time and the ticket creation time, to see if the value for the time elapsed sent by the client is consistent with the time since the ticket was issued. The ticket age (the value with "ticket_age_add" subtracted) provided by the client will be shorter than the actual time elapsed on the server by a single round trip time.  This difference is comprised of the delay in sending the NewSessionTicket message to the client, plus the time taken to send the ClientHello to the server.  For this reason, a server SHOULD measure the round trip time prior to sending the NewSessionTicket message and account for that in the value it saves. To properly validate the ticket age, a server needs to save at least two items: The time that the server generated the session ticket and the estimated round trip time can be added together to form a baseline time. The "ticket_age_add" parameter from the NewSessionTicket is needed to recover the ticket age from the "obfuscated_ticket_age" parameter. </del> <ins> This mechanism is intended to ensure that attackers cannot replay ClientHello messages at a time substantially after the original ClientHello was sent. To properly validate the ticket age, a server needs to store the following values, either locally or by encoding them in the ticket: The time that the server generated the session ticket. The estimated round trip time between the client and server; this can be estimated by measuring the time between sending the Finished message and receiving the first message in the client's second flight, or potentially using information from the operating system. The "ticket_age_add" parameter from the NewSessionTicket message in which the ticket was established. The server can determine the client's view of the age of the ticket by subtracting the ticket's "ticket_age_add value" from the "obfuscated_ticket_age" parameter in the client's "pre_shared_key" extension.  The server can independently determine its view of the age of the ticket by subtracting the the time the ticket was issued from the curren time.  If the client and server clocks were running at the same rate, the client's view of would be shorter than the actual time elapsed on the server by a single round trip time.  This difference is comprised of the delay in sending the NewSessionTicket message to the client, plus the time taken to send the ClientHello to the server. The mismatch between the client's and server's views of age is thus given by: </ins> There are several potential sources of error that make an exact measurement of time difficult.  Variations in client and server clock

Discussion:
…s , , .
NAME if you want to propose some revised text, I will TAL.
From Nikos's comment:
This is relating to . I will try to resolve both issues.
It is hard to understand the current text of Section 4.2.9.3 (Replay Properties). NAME explained me that a server should check: The server can tell: serverrecvtime == now serversendtime == one parameter in the ticket clientsendtime - clientrecvtime == ticketage == obfuscatedticketage + ticketage_add If this understanding is correct, I would suggest to add more explanation to the section.
Yes, that's correct. PRs welcome
I made a tweak to avoid referring to the "base value", in , though more changes may still be helpful.