Draft: draft-ietf-tls-rfc8446bis

Commentary: While we 're renaming these anyway , exportersecret and resumptionsecret are just as descriptive . 
 exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all . Perhaps exportersecret and resumptionsecret ? For the exporter secret , dropping " main " avoids the acronym collision with the EMS extension , and there are no other secrets associated with exporters , so there 's no use in designating this as the main one . For the resumption secret , there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket ( section { # NSTMessage } ) , but we do n't seem to give the latter a name in the first place so I think that 's fine . This also gives us nice short KDF labels when we 're able to change those : " exporter " and " resumption " . ( Or perhaps even " export " and " resume " if those do n't fit in a hash block . )
Paragraph (version A):
TLS 1.3 was originally specified in RFC8446.  This document is solely
an editorial update.  It contains updated text in areas which were
found to be unclear as well as other editorial improvements.  In
addition, it removes the use of the term "master" as applied to
secrets in favor of the term "main".
Paragraph (version B):
TLS 1.3 was originally specified in RFC8446.  This document is solely
an editorial update.  It contains updated text in areas which were
found to be unclear as well as other editorial improvements.  In
addition, it removes the use of the term "master" as applied to
secrets in favor of the term "main" or shorter names where no term
was neccessary.
Paragraph (version A):
There are no guarantees of non-replay between connections.
Protection against replay for ordinary TLS 1.3 1-RTT data is
provided via the server's Random value, but 0-RTT data does not
depend on the ServerHello and therefore has weaker guarantees.
This is especially relevant if the data is authenticated either
with TLS client authentication or inside the application protocol.
The same warnings apply to any use of the
early_exporter_main_secret.
Paragraph (version B):
There are no guarantees of non-replay between connections.
Protection against replay for ordinary TLS 1.3 1-RTT data is
provided via the server's Random value, but 0-RTT data does not
depend on the ServerHello and therefore has weaker guarantees.
This is especially relevant if the data is authenticated either
with TLS client authentication or inside the application protocol.
The same warnings apply to any use of the early_exporter_secret.
Paragraph (version A):
At any time after the server has received the client Finished
message, it MAY send a NewSessionTicket message.  This message
creates a unique association between the ticket value and a secret
PSK derived from the resumption main secret (see cryptographic-
computations).
Paragraph (version B):
At any time after the server has received the client Finished
message, it MAY send a NewSessionTicket message.  This message
creates a unique association between the ticket value and a secret
PSK derived from the resumption secret (see cryptographic-
computations).
Paragraph (version A):
Note: Although the resumption main secret depends on the client's
second flight, a server which does not request certificate-based
client authentication MAY compute the remainder of the transcript
independently and then send a NewSessionTicket immediately upon
sending its Finished rather than waiting for the client Finished.
This might be appropriate in cases where the client is expected to
open multiple TLS connections in parallel and would benefit from the
reduced overhead of a resumption handshake, for example.
Paragraph (version B):
Note: Although the resumption ecret depends on the client's second
flight, a server which does not request certificate-based client
authentication MAY compute the remainder of the transcript
independently and then send a NewSessionTicket immediately upon
sending its Finished rather than waiting for the client Finished.
This might be appropriate in cases where the client is expected to
open multiple TLS connections in parallel and would benefit from the
reduced overhead of a resumption handshake, for example.
Paragraph (version A):
If a given secret is not available, then the 0-value consisting of a
string of Hash.length bytes set to zeros is used.  Note that this
does not mean skipping rounds, so if PSK is not in use, Early Secret
will still be HKDF-Extract(0, 0).  For the computation of the
binder_key, the label is "ext binder" for external PSKs (those
provisioned outside of TLS) and "res binder" for resumption PSKs
(those provisioned as the resumption main secret of a previous
handshake).  The different labels prevent the substitution of one
type of PSK for the other.
Paragraph (version B):
If a given secret is not available, then the 0-value consisting of a
string of Hash.length bytes set to zeros is used.  Note that this
does not mean skipping rounds, so if PSK is not in use, Early Secret
will still be HKDF-Extract(0, 0).  For the computation of the
binder_key, the label is "ext binder" for external PSKs (those
provisioned outside of TLS) and "res binder" for resumption PSKs
(those provisioned as the resumption secret of a previous handshake).
The different labels prevent the substitution of one type of PSK for
the other.
Paragraph (version A):
Where Secret is either the early_exporter_main_secret or the
exporter_main_secret.  Implementations MUST use the
exporter_main_secret unless explicitly specified by the application.
The early_exporter_main_secret is defined for use in settings where
an exporter is needed for 0-RTT data.  A separate interface for the
early exporter is RECOMMENDED; this avoids the exporter user
accidentally using an early exporter when a regular one is desired or
vice versa.
Paragraph (version B):
Where Secret is either the early_exporter_secret or the
exporter_secret.  Implementations MUST use the exporter_secret unless
explicitly specified by the application.  The early_exporter_secret
is defined for use in settings where an exporter is needed for 0-RTT
data.  A separate interface for the early exporter is RECOMMENDED;
this avoids the exporter user accidentally using an early exporter
when a regular one is desired or vice versa.