Draft: draft-ietf-tls-tls13

Commentary: This is a lot of editorial work . Specifically : Removing redundant text Reordering things so that the handshake appears first and making the handshake and alert section A heds Harmonize a bunch of text Remove the obsolete Security Analysis text in preparation for providing a real Security Analysis section . This is my first cut and I will make another pass later today to catch mistakes / things that still need to be updated . you may want to take a look at this pre - merge . 
 There 's a lot of good restructuring here ( and I wish git handled changes like this far better ) . In particular , moving the handshake overview up to first position feels like a very good move . The only part here that I 'm really not sure of is having the subprotocols all moved so far away from eachother . They 're not really in any obvious order anymore . In the current draft , we have things ordered : record , alert , handshake , computations , MTI , application . In this changeset , we now have : handshake , computations , record , alert , MTI , application . ( there 's also the trivially fixable issue of ProtocolVersion being defined after being first used , now ) I think a more logical flow would be to put computations first and have the subprotocols in order of use : computations , record , handshake , alert , application , MTI . This would have a reader going through the document linearly go through steadily up through the layers ( more or less ) . One thing I think could also do with a change is to banish the full Presentation Language section to an appendix and link to it with a very short summary to the end of the Conventions and Terminology section . Whilst vector length declaration confuses everyone from implementers to the NSA , the other 90 % of that section is straightforward . There is nobody capable of understanding this document that needs this stuff up top like this , and it easily obscures the few parts of it that are absolutely crucial . The only things I think need to be in a summary are : explain vector notation in one or two sentences , note that everything is big - endian , and define " opaque " in one sentence . If we can get this bit of required knowledge up front , the rest is merely paperwork and can safely be stuck in the appendix . Seeing as we are aware of how frequently the vector notation is misunderstood , focusing on that up front feels like a needed improvement . 
  , thanks for your comments . Responses below . ,   wrote : Yeah . FWIW opendiff does an OK job here . That 's what I used for sanity checking . Thanks . This I can fix . Given this discussion , I think I 'm going to do : Presentation language Handshake Record layer Application Data ( though this is goofily short ) . Alerts Cryptographic computations MTI One thing I think could also do with a change is to banish the full 
 I could see splitting the presentation language out into a separate document , otherwise put the full description before it is first used . 
 On Saturday , July 09 , 2016 02:11:24 pm ekr wrote : I 'm not . I 'm just saying that in the list of sections , the ones that are for subprotocols ( handshake & alert ) are no longer in the same vicinity , as there 's other sections in between now . I think that 's an improvement . I 'd put alerts before application , though , as application data is generally the end steady - state of things and thus makes sense to be last . Whether or not it turns out to be worth doing will probably hinge on if we can put together a short summary that is sufficient . An alternative would be to rewrite it to be overall more concise , focus on the potentially misunderstood parts , and not going into as much verbosity on standard stuff like enums . The whole section also feels over - subsectioned a bit ( lots of tiny parts ) . 
 Actually , just cutting the Application Data Protocol section and sticking those lines in the Record Layer section might be better . It 's not really large or significant enough to be a section on its own . 
 ... including extensions , and messages . These are a really common thing to want to find . A flatter structure would fix this ; as would a deeper TOC , though my preference is for the former . 
 After looking at it for a little bit , I think the subsections in the current Handshake Protocol section ( 6.3 ) can be pulled up a tier to be part of a standalone section just called Messages , and the remaining text that starts the current Handshake Protocol section ( 6.3 ) would be better placed closer to Handshake Protocol Overview ( 6.2 ) . Current layout : Possible new layout : with 6.2 in the new absorbing a bit of the root of the previous 6.3 . I think this would be sufficient to get all the important stuff in the TOC and abolish the mild insanity of the 5 number subsection IDs .
Paragraph (version A):
This document specifies Version 1.3 of the Transport Layer Security
(TLS) protocol.  The TLS protocol allows client/server applications
to communicate over the Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery.
Paragraph (version B):
This document specifies Version 1.3 of the Transport Layer Security
(TLS) protocol.  TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery.
Paragraph (version A):
The connection is private.  Symmetric cryptography is used for
data encryption (e.g., AES AES).  The keys for this symmetric
encryption are generated uniquely for each connection and are
based on a secret negotiated by another the TLS Handshake
Protocol.
Paragraph (version A):
The connection is reliable.  Messages include an authentication
tag which protects them against modification.
Paragraph (version A):
The peer's identity can be authenticated using asymmetric (public
key) cryptography (e.g., RSA RSA, ECDSA ECDSA) or a pre-shared
symmetric key.  The TLS server is always authenticated; client
authentication is optional.
Paragraph (version A):
The negotiation of a shared secret is secure: the negotiated
secret is unavailable to eavesdroppers, and for any authenticated
connection the secret cannot be obtained, even by an attacker who
can place himself in the middle of the connection.
Paragraph (version A):
The negotiation is reliable: no attacker can modify the
negotiation communication without being detected by the parties to
the communication.
Paragraph (version A):
One advantage of TLS is that it is application protocol independent.
Higher-level protocols can layer on top of the TLS protocol
transparently.  The TLS standard, however, does not specify how
protocols add security with TLS; the decisions on how to initiate TLS
handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS.
Paragraph (version B):
The primary goal of TLS is to provide a secure channel between two
communicating peers.  Specifically, the channel should provide the
following properties.
Paragraph (version B):
Authentication: The server side of the channel is always
authenticated; the client side is optionally authenticated.
Authentication can happen via asymmetric cryptography (e.g., RSA
RSA, ECDSA ECDSA) or a pre-shared symmetric key.
Paragraph (version B):
Confidentiality: Data sent over the channel is not visible to
attackers.
Paragraph (version B):
Integrity: Data sent over the channel cannot be modified by
attackers.
Paragraph (version B):
These properties should be true even in the face of an attacker who
controls the channel, as described in RFC3552.  See Section [TODO]
for a more formal statement of the relevant security properties.
Paragraph (version B):
A handshake protocol which authenticates the communicating
parties, negotiates cryptographic modes and parameters, and
establishes shared keying material.  The handshake protocol is
designed to resist tampering; an active attacker should not be
able to force the peers to negotiate different parameters than
they would if the connection were not under attack.
Paragraph (version B):
A record protocol which uses the parameters established by the
handshake protocol to protect traffic between the communicating
peers.  The record protocol divides traffic up into a series of
records, each of which is independently protected using the
traffic keys.
Paragraph (version B):
One advantage of TLS is that it is application protocol independent.
Higher-level protocols can layer on top of TLS transparently.  The
TLS standard, however, does not specify how protocols add security
with TLS; the decisions on how to initiate TLS handshaking and how to
interpret the authentication certificates exchanged are left to the
judgment of the designers and implementors of protocols that run on
top of TLS.
Paragraph (version A):
Cryptographic security: TLS should be used to establish a secure
connection between two parties.
Paragraph (version A):
Interoperability: Independent programmers should be able to
develop applications utilizing TLS that can successfully exchange
cryptographic parameters without knowledge of one another's code.
Paragraph (version A):
Extensibility: TLS seeks to provide a framework into which new
public key and record protection methods can be incorporated as
necessary.  This will also accomplish two sub-goals: preventing
the need to create a new protocol (and risking the introduction of
possible new weaknesses) and avoiding the need to implement an
entire new security library.
Paragraph (version A):
Relative efficiency: Cryptographic operations tend to be highly
CPU intensive, particularly public key operations.  For this
reason, the TLS protocol has incorporated an optional session
caching scheme to reduce the number of connections that need to be
established from scratch.  Additionally, care has been taken to
reduce network activity.
Paragraph (version B):
The cryptographic parameters of the session state are produced by the
TLS handshake protocol.  When a TLS client and server first start
communicating, they agree on a protocol version, select cryptographic
algorithms, optionally authenticate each other, and establish shared
secret keying material.  Once the handshake is complete, the peers
may use the established keys to protect application layer traffic.
Paragraph (version B):
Although TLS PSKs can be established out of band, PSKs can also be
established in a previous session and then reused ("session
resumption").  Once a handshake has completed, the server can send
the client a PSK identity which corresponds to a key derived from the
initial handshake (See NewSessionTicket).  The client can then use
that PSK identity in future handshakes to negotiate use of the PSK;
if the server accepts it, then the security context of the new
connection is tied to the original connection.  In TLS 1.2 and below,
this functionality was provided by "session resumption" and "session
tickets" RFC5077.  Both mechanisms are obsoleted in TLS 1.3.
Paragraph (version B):
The remainder of this document provides a detailed description of
TLS.
Paragraph (version A):
The two cryptographic operations -- digital signing, and
authenticated encryption with additional data (AEAD) -- are
designated digitally-signed, and aead-ciphered, respectively.  A
field's cryptographic processing is specified by prepending an
appropriate key word designation before the field's type
specification.
Paragraph (version A):
The algorithm field specifies the algorithm used (see signature-
algorithms for the definition of this field).  The signature is a
digital signature using those algorithms over the contents of the
element.  The contents themselves do not appear on the wire but are
simply calculated.  The length of the signature is specified by the
signing algorithm and key.
Paragraph (version A):
In previous versions of TLS, the ServerKeyExchange format meant that
attackers can obtain a signature of a message with a chosen, 32-byte
prefix.  Because TLS 1.3 servers are likely to also implement prior
versions, the contents of the element always start with 64 bytes of
octet 32 in order to clear that chosen-prefix.
Paragraph (version A):
Following that padding is a context string used to disambiguate
signatures for different purposes.  The context string will be
specified whenever a digitally-signed element is used.  A single 0
byte is appended to the context to act as a separator.
Paragraph (version A):
The combined input is then fed into the corresponding signature
algorithm to produce the signature value on the wire.  See signature-
algorithms for algorithms defined in this specification.
Paragraph (version A):
followed by the encoding of the inner struct (field3 and field4).
Paragraph (version A):
The length of the structure, in bytes, would be equal to two bytes
for field1 and field2, plus two bytes for the signature algorithm,
plus two bytes for the length of the signature, plus the length of
the output of the signing algorithm.  The length of the signature is
known because the algorithm and key used for the signing are known
prior to encoding or decoding this structure.
Paragraph (version A):
In AEAD encryption, the plaintext is simultaneously encrypted and
integrity protected.  The input may be of any length, and aead-
ciphered output is generally larger than the input in order to
accommodate the integrity check value.
Paragraph (version A):
Three protocols that use the TLS Record Protocol are described in
this document: the TLS Handshake Protocol, the Alert Protocol, and
the application data protocol.  In order to allow extension of the
TLS protocol, additional record content types can be supported by the
TLS Record Protocol.  New record content type values are assigned by
IANA in the TLS Content Type Registry as described in iana-
considerations.
Paragraph (version A):
Implementations MUST NOT send record types not defined in this
document unless negotiated by some extension.  If a TLS
implementation receives an unexpected record type, it MUST send an
"unexpected_message" alert.
Paragraph (version A):
Any protocol designed for use over TLS must be carefully designed to
deal with all possible attacks against it.  As a practical matter,
this means that the protocol designer must be aware of what security
properties TLS does and does not provide and cannot safely rely on
the latter.
Paragraph (version A):
Note in particular that the length of a record or absence of traffic
itself is not protected by encryption unless the sender uses the
supplied padding mechanism - see record-padding for more details.
Paragraph (version A):
The application data.  This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol
specified by the type field.
Paragraph (version A):
The record protection functions translate a TLSPlaintext structure
into a TLSCiphertext.  The deprotection functions reverse the
process.  In TLS 1.3 as opposed to previous versions of TLS, all
ciphers are modeled as "Authenticated Encryption with Additional
Data" (AEAD) RFC5116.  AEAD functions provide a unified encryption
and authentication operation which turns plaintext into authenticated
ciphertext and back again.
Paragraph (version A):
The length (in bytes) of the following TLSCiphertext.fragment.
The length MUST NOT exceed 2^14 + 256.  An endpoint that receives
a record that exceeds this length MUST generate a fatal
"record_overflow" alert.
Paragraph (version A):
The actual content type of the record.
Paragraph (version A):
The AEAD encrypted form of TLSPlaintext.fragment +
TLSPlaintext.type + zeros, where "+" denotes concatenation.
Paragraph (version A):
AEAD ciphers take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as
described in Section 2.1 of RFC5116.  The key is either the
client_write_key or the server_write_key, the nonce is derived from
the a sequence number (see nonce) and the client_write_iv or
server_write_iv, and the additional data input is empty (zero
length).  Derivation of traffic keys is defined in traffic-key-
calculation.
Paragraph (version A):
TLS has two subprotocols that are used to allow peers to agree upon
security parameters for the record layer, to authenticate themselves,
to instantiate negotiated security parameters, and to report error
conditions to each other.
Paragraph (version A):
X509v3 RFC5280 certificate of the peer.  This element of the state
may be null.
Paragraph (version A):
a secret shared between the client and server that can be used as
a pre-shared symmetric key (PSK) in future connections.
Paragraph (version A):
These items are then used to create security parameters for use by
the record layer when protecting application data.  Many connections
can be instantiated using the same session using a PSK established in
an initial handshake.
Paragraph (version A):
The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS record
layer.  When a TLS client and server first start communicating, they
agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and establish shared secret
keying material.
Paragraph (version A):
Although TLS PSKs can be established out of band, PSKs can also be
established in a previous session and then reused ("session
resumption").  Once a handshake has completed, the server can send
the client a PSK identity which corresponds to a key derived from the
initial handshake (See NewSessionTicket).  The client can then use
that PSK identity in future handshakes to negotiate use of the PSK;
if the server accepts it, then the security context of the original
connection is tied to the new connection.  In TLS 1.2 and below, this
functionality was provided by "session resumption" and "session
tickets" RFC5077.  Both mechanisms are obsoleted in TLS 1.3.
Paragraph (version A):
The contents and significance of each message will be presented in
detail in the following sections.
Paragraph (version A):
When a client first connects to a server, it is required to send
the ClientHello as its first message.  The client will also send a
ClientHello when the server has responded to its ClientHello with
a ServerHello that selects cryptographic parameters that don't
match the client's "key_share" extension.  In that case, the
client MUST send the same ClientHello (without modification)
except including a new KeyShareEntry as the lowest priority share
(i.e., appended to the list of shares in the "key_share"
extension).  If a server receives a ClientHello at any other time,
it MUST send a fatal "unexpected_message" alert and close the
connection.
Paragraph (version A):
The server_version, cipher_suite, and extensions fields have the same
meanings as their corresponding values in the ServerHello.  The
server SHOULD send only the extensions necessary for the client to
generate a correct ClientHello pair.  As with ServerHello, a
HelloRetryRequest MUST NOT contain any extensions that were not first
offered by the client in its ClientHello.
Paragraph (version A):
Finally, note that extensions can be sent both when starting a new
session and when requesting session resumption or 0-RTT mode.
Indeed, a client that requests session resumption does not in general
know whether the server will accept this request, and therefore it
SHOULD send the same extensions as it would send if it were not
attempting resumption.
Paragraph (version A):
It would be technically possible to use extensions to change major
aspects of the design of TLS; for example, the design of cipher
suite negotiation.  This is not recommended; it would be more
appropriate to define a new version of TLS -- particularly since
the TLS handshake algorithms have specific protection against
version rollback attacks based on the version number, and the
possibility of version rollback should be a significant
consideration in any major design change.
Paragraph (version A):
Indicates a signature algorithm using RSASSA-PKCS1-v1_5 RFC3447
with the corresponding hash algorithm as defined in SHS.  These
values refer solely to signatures which appear in certificates
(see server-certificate-selection) and are not defined for use in
signed TLS handshake messages (see digital-signing).
Paragraph (version A):
Indicates a signature algorithm using RSASSA-PSS RFC3447 with
MGF1.  The digest used in the mask generation function and the
digest being signed are both the corresponding hash algorithm as
defined in SHS.  When used in signed TLS handshake messages (see
digital-signing), the length of the salt MUST be equal to the
length of the digest output.
Paragraph (version A):
Servers offer exactly one KeyShareEntry value, which corresponds to
the key exchange used for the negotiated cipher suite.
Paragraph (version A):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
FFDHE groups.  The key_exchange values for each KeyShareEntry MUST by
generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same group.  Clients and servers MUST
NOT offer any KeyShareEntry values for groups not listed in the
client's "supported_groups" extension.  Servers MUST NOT offer a
KeyShareEntry value for a group not offered by the client in its
corresponding KeyShare.  Implementations MAY check for violations of
these rules and and MAY abort the connection with a fatal
"illegal_parameter" alert if one is violated.
Paragraph (version A):
Note that although 0-RTT data is encrypted with the first PSK
identity, the server may fall back to 1-RTT and select a different
PSK identity if multiple are offered.
Paragraph (version A):
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 A):
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.
Paragraph (version A):
As discussed in handshake-protocol-overview, TLS uses a common set of
messages for authentication, key confirmation, and handshake
integrity: Certificate, CertificateVerify, and Finished.  These
messages are always sent as the last messages in their handshake
flight.  The Certificate and CertificateVerify messages are only sent
under certain circumstances, as defined below.  The Finished message
is always sent as part of the Authentication block.
Paragraph (version A):
The certificate MUST be appropriate for the negotiated cipher
suite's key exchange algorithm and any negotiated extensions.
Paragraph (version A):
If this message is in response to a CertificateRequest, the value
of certificate_request_context in that message.  Otherwise, in the
case of server authentication or client authentication in 0-RTT,
this field SHALL be zero length.
Paragraph (version A):
The server's end-entity certificate's public key (and associated
restrictions) MUST be compatible with the selected key exchange
algorithm.
Paragraph (version A):
The certificates MUST be signed using an acceptable hash/
signature algorithm pair, as described in certificate-request.
Note that this relaxes the constraints on certificate-signing
algorithms found in prior versions of TLS.
Paragraph (version A):
Any endpoint receiving any certificate signed using any signature
algorithm using an MD5 hash MUST send a "bad_certificate" alert
message and close the connection.
Paragraph (version A):
SHA-1 is deprecated and therefore NOT RECOMMENDED.  Endpoints that
reject certification paths due to use of a deprecated hash MUST send
a fatal "bad_certificate" alert message before closing the
connection.  All endpoints are RECOMMENDED to transition to SHA-256
or better as soon as possible to maintain interoperability with
implementations currently in the process of phasing out SHA-1
support.
Paragraph (version A):
The context string for a server signature is "TLS 1.3, server
CertificateVerify" and for a client signature is "TLS 1.3, client
CertificateVerify".  A hash of the handshake messages is signed
rather than the messages themselves because the digitally-signed
format requires padding and context bytes at the beginning of the
input.  Thus, by signing a digest of the messages, an
implementation only needs to maintain a single running hash per
hash type for CertificateVerify, Finished and other messages.
Paragraph (version A):
If sent by a server, the signature algorithm MUST be one offered
in the client's "signature_algorithms" extension unless no valid
certificate chain can be produced without unsupported algorithms
(see signature-algorithms).  Note that there is a possibility for
inconsistencies here.  For instance, the client might offer
ECDHE_ECDSA key exchange but omit any ECDSA and EdDSA values from
its "signature_algorithms" extension.  In order to negotiate
correctly, the server MUST check any candidate cipher suites
against the "signature_algorithms" extension before selecting
them.  This is somewhat inelegant but is a compromise designed to
minimize changes to the original cipher suite design.
Paragraph (version A):
In addition, the signature algorithm MUST be compatible with the
key in the sender's end-entity certificate.  RSA signatures MUST
use an RSASSA-PSS algorithm, regardless of whether RSASSA-
PKCS1-v1_5 algorithms appear in "signature_algorithms".  SHA-1
MUST NOT be used in any signatures in CertificateVerify.  All
SHA-1 signature algorithms in this specification are defined
solely for use in legacy certificates, and are not valid for
CertificateVerify signatures.
Paragraph (version A):
A randomly 32-bit value that is used to obscure the age of the
ticket that the client includes in the "early_data" extension.
The actual ticket age is added to this value modulo 2^32 to obtain
the value that is transmitted by the client.
Paragraph (version B):
Including a new KeyShareEntry as the lowest priority share (i.e.,
appended to the list of shares in the "key_share" extension).
Paragraph (version B):
Removing the EarlyDataIndication early-data-indication extension
if one was present.  Early data is not permitted after
HelloRetryRequest.
Paragraph (version B):
If a server receives a ClientHello at any other time, it MUST send a
fatal "unexpected_message" alert and close the connection.
Paragraph (version B):
The server_version, cipher_suite, and extensions fields have the same
meanings as their corresponding values in the ServerHello.  The
server SHOULD send only the extensions necessary for the client to
generate a correct ClientHello pair (currently no such extensions
exist.)  As with ServerHello, a HelloRetryRequest MUST NOT contain
any extensions that were not first offered by the client in its
ClientHello.
Paragraph (version B):
Finally, note that extensions can be sent both when starting a new
session and when in resumption-PSK mode.  Indeed, a client that
requests session resumption does not in general know whether the
server will accept this request, and therefore it SHOULD send the
same extensions as it would send normally.
Paragraph (version B):
Indicates a signature algorithm using RSASSA-PKCS1-v1_5 RFC3447
with the corresponding hash algorithm as defined in SHS.  These
values refer solely to signatures which appear in certificates
(see server-certificate-selection) and are not defined for use in
signed TLS handshake messages.
Paragraph (version B):
Indicates a signature algorithm using RSASSA-PSS RFC3447 with
MGF1.  The digest used in the mask generation function and the
digest being signed are both the corresponding hash algorithm as
defined in SHS.  When used in signed TLS handshake messages, the
length of the salt MUST be equal to the length of the digest
output.
Paragraph (version B):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
FFDHE groups.  The key_exchange values for each KeyShareEntry MUST by
generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same group.  Clients and MUST NOT offer
any KeyShareEntry values for groups not listed in the client's
"supported_groups" extension.
Paragraph (version B):
Servers offer exactly one KeyShareEntry value, which corresponds to
the key exchange used for the negotiated cipher suite.  Servers MUST
NOT offer a KeyShareEntry value for a group not offered by the client
in its corresponding KeyShare or "supported_groups" extension.
Paragraph (version B):
Implementations MAY check for violations of these rules and and MAY
abort the connection with a fatal "illegal_parameter" alert if one is
violated.
Paragraph (version B):
Peers SHOULD validate each other's public key Y by ensuring that 1 <
Y < p-1.  This check ensures that the remote peer is properly behaved
and isn't forcing the local system into a small subgroup.
Paragraph (version B):
Note that although 0-RTT data is encrypted with the first PSK
identity, the server may fall back to 1-RTT and select a different
PSK identity if multiple identities are offered.
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.
Paragraph (version B):
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 B):
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 discussed in protocol-overview, TLS uses a common set of messages
for authentication, key confirmation, and handshake integrity:
Certificate, CertificateVerify, and Finished.  These messages are
always sent as the last messages in their handshake flight.  The
Certificate and CertificateVerify messages are only sent under
certain circumstances, as defined below.  The Finished message is
always sent as part of the Authentication block.
Paragraph (version B):
The certificate MUST be appropriate for the negotiated cipher
suite's authentication algorithm and any negotiated extensions.
Paragraph (version B):
If this message is in response to a CertificateRequest, the value
of certificate_request_context in that message.  Otherwise, in the
case of server authentication this field SHALL be zero length.
Paragraph (version B):
The server's end-entity certificate's public key (and associated
restrictions) MUST be compatible with the selected authentication
algorithm (currently RSA or ECDSA).
Paragraph (version B):
The certificates MUST be signed using an acceptable signature
algorithm, as described in certificate-request.  Note that this
relaxes the constraints on certificate-signing algorithms found in
prior versions of TLS.
Paragraph (version B):
Any endpoint receiving any certificate signed using any signature
algorithm using an MD5 hash MUST send a "bad_certificate" alert
message and close the connection.  SHA-1 is deprecated and therefore
NOT RECOMMENDED.  All endpoints are RECOMMENDED to transition to
SHA-256 or better as soon as possible to maintain interoperability
with implementations currently in the process of phasing out SHA-1
support.
Paragraph (version B):
Endpoints that reject certification paths due to use of a deprecated
hash MUST send a fatal "bad_certificate" alert message before closing
the connection.
Paragraph (version B):
This structure is intended to prevent an attack on previous versions
of previous versions of TLS in which the ServerKeyExchange format
meant that attackers could obtain a signature of a message with a
chosen, 32-byte prefix.  The initial 64 byte pad clears that prefix.
Paragraph (version B):
The context string for a server signature is "TLS 1.3, server
CertificateVerify" and for a client signature is "TLS 1.3, client
CertificateVerify".
Paragraph (version B):
If sent by a server, the signature algorithm MUST be one offered in
the client's "signature_algorithms" extension unless no valid
certificate chain can be produced without unsupported algorithms (see
signature-algorithms).  Note that there is a possibility for
inconsistencies here.  For instance, the client might offer an
ECDHE_ECDSA cipher suite but omit any ECDSA and EdDSA values from its
"signature_algorithms" extension.  In order to negotiate correctly,
the server MUST check any candidate cipher suites against the
"signature_algorithms" extension before selecting them.  This is
somewhat inelegant but is a compromise designed to minimize changes
to the original cipher suite design.
Paragraph (version B):
In addition, the signature algorithm MUST be compatible with the key
in the sender's end-entity certificate.  RSA signatures MUST use an
RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5
algorithms appear in "signature_algorithms".  SHA-1 MUST NOT be used
in any signatures in CertificateVerify.  All SHA-1 signature
algorithms in this specification are defined solely for use in legacy
certificates, and are not valid for CertificateVerify signatures.
Paragraph (version B):
A randomly generated 32-bit value that is used to obscure the age
of the ticket that the client includes in the "early_data"
extension.  The actual ticket age is added to this value modulo
2^32 to obtain the value that is transmitted by the client.
Paragraph (version B):
TLS records are typed, which allows multiple higher level protocols
to be multiplexed over the same record layer.  This document
specifies three content types: handshake, application data, and
alert.  Implementations MUST NOT send record types not defined in
this document unless negotiated by some extension.  If a TLS
implementation receives an unexpected record type, it MUST send an
"unexpected_message" alert.  New record content type values are
assigned by IANA in the TLS Content Type Registry as described in
iana-considerations.
Paragraph (version B):
Application data messages are carried by the record layer and are
fragmented and encrypted as described below.  The messages are
treated as transparent data to the record layer.
Paragraph (version B):
The data being transmitted.  This value transparent and treated as
an independent block to be dealt with by the higher-level protocol
specified by the type field.
Paragraph (version B):
The record protection functions translate a TLSPlaintext structure
into a TLSCiphertext.  The deprotection functions reverse the
process.  In TLS 1.3 as opposed to previous versions of TLS, all
ciphers are modeled as "Authenticated Encryption with Additional
Data" (AEAD) RFC5116.  AEAD functions provide a unified encryption
and authentication operation which turns plaintext into authenticated
ciphertext and back again.  Each encrypted record consists of a
plaintext header followed by an encrypted body, which itself contains
a type and optional padding.
Paragraph (version B):
The content type of the record.
Paragraph (version B):
The length (in bytes) of the following TLSCiphertext.fragment,
which is the sum of the lengths of the content and the padding,
plus one for the inner content type.  The length MUST NOT exceed
2^14 + 256.  An endpoint that receives a record that exceeds this
length MUST generate a fatal "record_overflow" alert.
Paragraph (version B):
The AEAD encrypted form of the serialized TLSInnerPlaintext
structure.
Paragraph (version B):
AEAD ciphers take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as
described in Section 2.1 of RFC5116.  The key is either the
client_write_key or the server_write_key, the nonce is derived from
the sequence number (see nonce) and the client_write_iv or
server_write_iv, and the additional data input is empty (zero
length).  Derivation of traffic keys is defined in traffic-key-
calculation.
Paragraph (version A):
Application data messages are carried by the record layer and are
fragmented and encrypted based on the current connection state.  The
messages are treated as transparent data to the record layer.