Draft: draft-ietf-tls-tls13

Commentary: … s , , . 
 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 ) . 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 .
Paragraph (version A):
For each ticket, the time since the client learned about the
server configuration that it is using, in milliseconds.  This
value is added modulo 2^32 to the "ticket_age_add" value that was
included with the ticket, see NSTMessage.  This addition prevents
passive observers from correlating connections unless tickets are
reused.  Note: because ticket lifetimes are restricted to a week,
32 bits is enough to represent any plausible age, even in
milliseconds.  For identities established externally an
obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore
the value.
Paragraph (version B):
An obfuscated version of the age of the key.  ticket-age describes
how to form this value for identities established via the
NewSessionTicket message.  For identities established externally
an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST
ignore the value.
Paragraph (version B):
The client's view of the age of a ticket is the time since the
receipt of the NewSessionTicket message.  Clients MUST NOT attempt to
use tickets which have ages greater than the "ticket_lifetime" value
which was provided with the ticket.  The "obfuscated_ticket_age"
field of each PskIdentity contains an obfuscated version of the
ticket age formed by taking the age in milliseconds and adding the
"ticket_age_add" value that was included with the ticket, see
NSTMessage modulo 2^32.  This addition prevents passive observers
from correlating connections unless tickets are reused.  Note that
the "ticket_lifetime" field in the NewSessionTicket message is in
seconds but the "obfuscated_ticket_age" is in milliseconds.  Because
ticket lifetimes are restricted to a week, 32 bits is enough to
represent any plausible age, even in milliseconds.
Paragraph (version A):
As noted in zero-rtt-data, TLS provides a limited mechanism for
replay protection for data sent by the client in the first flight.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
The time that the server generated the session ticket and the
estimated round trip time can be added together to form a baseline
time.
Paragraph (version A):
The "ticket_age_add" parameter from the NewSessionTicket is needed
to recover the ticket age from the "obfuscated_ticket_age"
parameter.
Paragraph (version B):
As noted in zero-rtt-data, TLS provides a limited mechanism for
replay protection for data sent by the client in the first flight.
This mechanism is intended to ensure that attackers cannot replay
ClientHello messages at a time substantially after the original
ClientHello was sent.
Paragraph (version B):
The time that the server generated the session ticket.
Paragraph (version B):
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.
Paragraph (version B):
The "ticket_age_add" parameter from the NewSessionTicket message
in which the ticket was established.
Paragraph (version B):
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.
Paragraph (version A):
There are several potential sources of error that make an exact
measurement of time difficult.  Variations in client and server clock
rates are likely to be minimal, though potentially with gross time
corrections.  Network propagation delays are the most likely causes
of a mismatch in legitimate values for elapsed time.  Both the
NewSessionTicket and ClientHello messages might be retransmitted and
therefore delayed, which might be hidden by TCP.
Paragraph (version A):
A small allowance for errors in clocks and variations in measurements
is advisable.  However, any allowance also increases the opportunity
for replay.  In this case, it is better to reject early data and fall
back to a full 1-RTT handshake than to risk greater exposure to
replay attacks.  In common network topologies for browser clients,
small allowances on the order of ten seconds are reasonable.  Clock
skew distributions are not symmetric, so the optimal tradeoff may
involve an asymmetric replay window.
Paragraph (version B):
There are several potential sources of error that make an exact
measurement of time difficult.  Variations in client and server clock
rates are likely to be minimal, though potentially with gross time
corrections.  Network propagation delays are the most likely causes
of a mismatch in legitimate values for elapsed time.  Both the
NewSessionTicket and ClientHello messages might be retransmitted and
therefore delayed, which might be hidden by TCP.  Thus, an an
allowance on the order of ten seconds to account for errors in clocks
and variations in measurements is advisable.  Outside this range, the
server SHOULD reject early data and fall back to a full 1-RTT
handshake.  Clock skew distributions are not symmetric, so the
optimal tradeoff may involve an asymmetric range of permissible
mismatch values.