Draft: draft-ietf-tls-tls13

Commentary: WIP , not ready to land . PTAL
Paragraph (version B):
In addition, it MUST validate that the ticket_age is within a small
tolerance of the time since the ticket was issued (see replay-time).
Paragraph (version A):
If the server chooses to accept the "early_data" extension, then it
MUST comply with the same error handling requirements specified for
all records when processing early data records.  Specifically,
decryption failure of any 0-RTT record following an accepted
"early_data" extension MUST produce a fatal "bad_record_mac" alert as
per record-payload-protection.
Paragraph (version A):
As noted in zero-rtt-data, TLS does not provide any inter-connection
mechanism for replay protection for data sent by the client in the
first flight.  As a special case, implementations where the server
configuration, is delivered out of band (as has been proposed for
DTLS-SRTP RFC5763), MAY use a unique server configuration identifier
for each connection, thus preventing replay.  Implementations are
responsible for ensuring uniqueness of the identifier in this case.
Paragraph (version B):
If the server chooses to accept the "early_data" extension, then it
MUST comply with the same error handling requirements specified for
all records when processing early data records.  Specifically,
decryption failure of any 0-RTT record following an accepted
"early_data" extension MUST produce a fatal "bad_record_mac" alert as
per record-payload-protection.  Implementations SHOULD determine the
security parameters for the 1-RTT phase of the connection entirely
before processing the EncryptedExtensions and Finished, using those
values solely to determine whether to accept or reject 0-RTT data.
Paragraph (version B):
Clients are permitted to "stream" 0-RTT data until they receive the
server's Finished, only then sending the "end_of_early_data" alert.
In order to avoid deadlock, when accepting "early_data", servers MUST
process the client's Finished and then immediately send the
ServerHello, rather than waiting for the client's "end_of_early_data"
alert.
Paragraph (version B):
As noted in zero-rtt-data, TLS provides only a limited inter-
connection mechanism for replay protection for data sent by the
client in the first flight.
Paragraph (version B):
The "ticket_age" extension sent by the client 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 server
configuration to a client, or encode the time in a ticket.  Then,
each time it receives an early_data extension, it can check to see if
the value used by the client matches its expectations.
Paragraph (version B):
The "ticket_age" value 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 B):
There are several potential sources of error that make an exact
measurement of time difficult.  Variations in client and server
clocks are likely to be minimal, outside of gross time corrections.
Network propagation delays are 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 B):
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 than to
risk greater exposure to replay attacks.
Paragraph (version B):
When the client sends the "early_data" extension, it MUST also send a
"ticket_age" extension in its EncryptedExtensions block.  This value
contains the time elapsed since the client learned about the server
configuration that it is using, in milliseconds.  This value can be
used by the server to limit the time over which early data can be
replayed.  Note: because ticket lifetimes are restricted to a week,
32 bits is enough to represent any plausible age, even in
milliseconds.
Paragraph (version A):
The EncryptedExtensions message MUST be sent immediately after the
ServerHello message.  This is the first message that is encrypted
under keys derived from ES.
Paragraph (version A):
The EncryptedExtensions message simply contains any extensions
which should be protected, i.e., any which are not needed to
establish the cryptographic context.  The same extension types
MUST NOT appear in both the ServerHello and EncryptedExtensions.
If the same extension appears in both locations, the client MUST
rely only on the value in the EncryptedExtensions block.  All
server-sent extensions other than those explicitly listed in
server-hello or designated in the IANA registry MUST only appear
in EncryptedExtensions.  Extensions which are designated to appear
in ServerHello MUST NOT appear in EncryptedExtensions.  Clients
MUST check EncryptedExtensions for the presence of any forbidden
extensions and if any are found MUST terminate the handshake with
an "illegal_parameter" alert.
Paragraph (version B):
In all handshakes, the server MUST send the EncryptedExtensions
message MUST be sent immediately after the ServerHello message.
This is the first message that is encrypted under keys derived
from ES.  If the client indicates "early_data" in its ClientHello,
it MUST also send EncryptedExtensions immediately following the
ClientHello and immediately prior to the Finished.
Paragraph (version B):
The EncryptedExtensions message contains any extensions which
should be protected, i.e., any which are not needed to establish
the cryptographic context.
Paragraph (version B):
The same extension types MUST NOT appear in both the ServerHello and
EncryptedExtensions.  If the same extension appears in both
locations, the client MUST rely only on the value in the
EncryptedExtensions block.  All server-sent extensions other than
those explicitly listed in server-hello or designated in the IANA
registry MUST only appear in EncryptedExtensions.  Extensions which
are designated to appear in ServerHello MUST NOT appear in
EncryptedExtensions.  Clients MUST check EncryptedExtensions for the
presence of any forbidden extensions and if any are found MUST
terminate the handshake with an "illegal_parameter" alert.
Paragraph (version B):
The client's EncryptedExtensions apply only to the early data with
which they appear.  Servers MUST NOT use them to negotiate the rest
of the handshake.  Only those extensions explicitly designated as
being included in 0-RTT Encrypted Extensions in the IANA registry can
be sent in the client's EncryptedExtensions.
Paragraph (version A):
IANA [shall update/has updated] this registry to include a "TLS
that the server shall not send them.  "Clear", indicating that
they shall be in the ServerHello.  "Encrypted", indicating that
they shall be in the EncryptedExtensions block, and "No"
indicating that they are not used in TLS 1.3.  This column [shall
be/has been] initially populated with the values in this document.
IANA [shall update/has updated] this registry to add a
"Recommended" column.  IANA [shall/has] initially populated this
column with the values in the table below.  This table has been
generated by marking Standards Track RFCs as "Yes" and all others
as "No".
Paragraph (version B):
IANA [shall update/has updated] this registry to include a "TLS
that the server shall not send them.  "Clear", indicating that
they shall be in the ServerHello.  "Encrypted", indicating that
they shall be in the EncryptedExtensions block, "Early",
indicating that they shall be only in the client's 0-RTT
EncryptedExtensions block, and "No" indicating that they are not
used in TLS 1.3.  This column [shall be/has been] initially
populated with the values in this document.  IANA [shall update/
has updated] this registry to add a "Recommended" column.  IANA
[shall/has] initially populated this column with the values in the
table below.  This table has been generated by marking Standards
Track RFCs as "Yes" and all others as "No".