Draft: draft-ietf-tls-tls13

Commentary: I did not : 1 ) add the " Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it 's already in the [ JSS15 ] reference that 's later in the sentence . 2 ) I also did n't made [ AEAD - LIMITS ] normative .
Paragraph (version A):
This document supersedes and obsoletes previous versions of TLS
including version 1.2 RFC5246.  It also obsoletes the TLS ticket
mechanism defined in RFC5077 and replaces it with the mechanism
defined in resumption-and-psk. negotiated-groups updates RFC4492 by
modifying the protocol attributes used to negotiate Elliptic Curves.
Because TLS 1.3 changes the way keys are derived it updates RFC5705
as described in exporters it also changes how OCSP messages are
carried and therefore updates RFC6066 and obsoletes RFC6961 as
described in section ocsp-and-sct.
Paragraph (version B):
This document supersedes and obsoletes previous versions of TLS
including version 1.2 RFC5246.  It also obsoletes the TLS ticket
mechanism defined in RFC5077 and replaces it with the mechanism
defined in resumption-and-psk. negotiated-groups updates RFC4492 by
modifying the protocol attributes used to negotiate Elliptic Curves.
Because TLS 1.3 changes the way keys are derived, it updates RFC5705
as described in exporters.  It also changes how OCSP messages are
carried and therefore updates RFC6066 and obsoletes RFC6961 as
described in section ocsp-and-sct.
Paragraph (version A):
Elliptic curve algorithms are now in the base spec and includes
new signature algorithms, such as ed25519 and ed448.  TLS 1.3
removed point format negotiation in favor of a single point format
for each curve.
Paragraph (version B):
Elliptic curve algorithms are now in the base spec and new
signature algorithms, such as ed25519 and ed448, are included.
TLS 1.3 removed point format negotiation in favor of a single
point format for each curve.
Paragraph (version A):
All values, here and elsewhere in the specification, are stored in
network byte (big-endian) order; the uint32 represented by the hex
bytes 01 02 03 04 is equivalent to the decimal value 16909060.
Paragraph (version B):
All values, here and elsewhere in the specification, are transmitted
in network byte (big-endian) order; the uint32 represented by the hex
bytes 01 02 03 04 is equivalent to the decimal value 16909060.
Paragraph (version A):
If this extension is present, servers MUST ignore the
ClientHello.legacy_version value and MUST use only the
"supported_versions" extension to determine client preferences.
Servers MUST only select a version of TLS present in that extension
and MUST ignore any unknown versions that are present in that
extension.  Note that this mechanism makes it possible to negotiate a
version prior to TLS 1.2 if one side supports a sparse range.
Implementations of TLS 1.3 which choose to support prior versions of
TLS SHOULD support TLS 1.2.  Servers should be prepared to receive
ClientHellos that include this extension but do not include 0x0304 in
the list of versions.
Paragraph (version B):
If this extension is present, servers MUST ignore the
ClientHello.legacy_version value and MUST use only the
"supported_versions" extension to determine client preferences.
Servers MUST only select a version of TLS present in that extension
and MUST ignore any unknown versions that are present in that
extension.  Note that this mechanism makes it possible to negotiate a
version prior to TLS 1.2 if one side supports a sparse range.
Implementations of TLS 1.3 which choose to support prior versions of
TLS SHOULD support TLS 1.2.  Servers MUST be prepared to receive
ClientHellos that include this extension but do not include 0x0304 in
the list of versions.
Paragraph (version A):
Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask
generation function 1.  The digest used in the mask generation
function and the digest being signed are both the corresponding
hash algorithm as defined in SHS.  The length of the salt MUST be
equal to the length of the digest algorithm.  If the public key is
carried in an X.509 certificate, it MUST use the RSASSA-PSS OID
RFC5756.  When used in certificate signatures, the algorithm
parameters MUST be DER encoded.  If the corresponding public key's
parameters present, then the parameters in the signature MUST be
identical to those in the public key.
Paragraph (version B):
Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask
generation function 1.  The digest used in the mask generation
function and the digest being signed are both the corresponding
hash algorithm as defined in SHS.  The length of the salt MUST be
equal to the length of the digest algorithm.  If the public key is
carried in an X.509 certificate, it MUST use the RSASSA-PSS OID
RFC5756.  When used in certificate signatures, the algorithm
parameters MUST be DER encoded.  If the corresponding public key's
parameters are present, then the parameters in the signature MUST
be identical to those in the public key.
Paragraph (version A):
The "post_handshake_auth" extension is used to indicate that a client
is willing to perform post-handshake authentication post-handshake-
authentication.  Servers MUST NOT send a post-handshake
CertificateRequest to clients which do not offer this extension.
Servers MUST NOT send this extension.
Paragraph (version B):
The "post_handshake_auth" extension is used to indicate that a client
is willing to perform post-handshake authentication (post-handshake-
authentication).  Servers MUST NOT send a post-handshake
CertificateRequest to clients which do not offer this extension.
Servers MUST NOT send this extension.
Paragraph (version A):
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 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):
The context string for a server signature is "TLS 1.3, server
CertificateVerify" and for a client signature is "TLS 1.3, client
CertificateVerify".  It is used to provide separation between
signatures made in different contexts, helping against potential
cross-protocol attacks.
Paragraph (version B):
The context string for a server signature is: "TLS 1.3, server
CertificateVerify" The context string for a client signature is: "TLS
between signatures made in different contexts, helping against
potential cross-protocol attacks.
Paragraph (version A):
For finite field groups, a conventional Diffie-Hellman computation is
performed.  The negotiated key (Z) is converted to a byte string by
encoding in big-endian and padded with zeros up to the size of the
prime.  This byte string is used as the shared secret in the key
schedule as specified above.
Paragraph (version B):
For finite field groups, a conventional Diffie-Hellman computation is
performed.  The negotiated key (Z) is converted to a byte string by
encoding in big-endian and left padded with zeros up to the size of
the prime.  This byte string is used as the shared secret in the key
schedule as specified above.