Draft: draft-ietf-tls-tls13

Commentary: Re - pushed to squash commits ... 
 Aside from the one noted change , lots of good typo fixes here . 
 Good to go .
Paragraph (version A):
Provide a list of the PSK cipher sutes.
Paragraph (version B):
Provide a list of the PSK cipher suites.
Paragraph (version A):
The outer opaque_type field of a TLSCiphertext record is always
set to the value 23 (application_data) for outward compatibility
with middleboxes used to parsing previous versions of TLS.  The
actual content type of the record is found in fragment.type after
decryption.
Paragraph (version B):
The outer opaque_type field of a TLSCiphertext record is always
set to the value 23 (application_data) for outward compatibility
with middleboxes accustomed to parsing previous versions of TLS.
The actual content type of the record is found in fragment.type
after decryption.
Paragraph (version A):
At this point, the handshake is complete, and the client and server
may exchange application layer data.  Application data MUST NOT be
sent prior to sending the Finished message.  Note that while the
server may send application data prior to receiving the client's
Authentication messages, any data sent at that point is of course
being sent to an unauthenticated peer.
Paragraph (version B):
At this point, the handshake is complete, and the client and server
may exchange application layer data.  Application data MUST NOT be
sent prior to sending the Finished message.  Note that while the
server may send application data prior to receiving the client's
Authentication messages, any data sent at that point is, of course,
being sent to an unauthenticated peer.
Paragraph (version A):
TLS 1.3 supports a "0-RTT" mode in which the client can both
authenticate and send application on its first flight, thus reducing
handshake latency.  In order to enable this functionality, the server
provides a ServerConfiguration message containing a long-term (EC)DH
share.  On future connections to the same server, the client can use
that share to protect the first-flight data.
Paragraph (version B):
TLS 1.3 supports a "0-RTT" mode in which the client can both
authenticate and send application data on its first flight, thus
reducing handshake latency.  In order to enable this functionality,
the server provides a ServerConfiguration message containing a long-
term (EC)DH share.  On future connections to the same server, the
client can use that share to protect the first-flight data.
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 B):
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):
a "illegal_parameter" alert.
Paragraph (version B):
an "illegal_parameter" alert.
Paragraph (version A):
If server supplies an empty Certificate message, the client MUST
terminate the handshake with a fatal "decode_error" alert.
Paragraph (version B):
If the server supplies an empty Certificate message, the client MUST
terminate the handshake with a fatal "decode_error" alert.
Paragraph (version A):
Note that a certificate containing a key for one signature algorithm
MAY be signed using a different signature algorithm (for instance, an
RSA key signed with a ECDSA key).
Paragraph (version B):
Note that a certificate containing a key for one signature algorithm
MAY be signed using a different signature algorithm (for instance, an
RSA key signed with an ECDSA key).
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 need only maintain one running hash per hash type
for CertificateVerify, Finished and other messages.
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".  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):
TLS also allows other messages to be sent after the main handshake.
These message use a handshake content type and are encrypted under
the application traffic key.
Paragraph (version B):
TLS also allows other messages to be sent after the main handshake.
These messages use a handshake content type and are encrypted under
the application traffic key.