Draft: draft-ietf-tls-tls13

Commentary: This is an update of AGL 's PR
Paragraph (version B):
Update format of signatures with context.
Paragraph (version B):
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 B):
Following that padding is a NUL-terminated context string in order to
disambiguate signatures for different purposes.  The context string
will be specified whenever a digitally-signed element is used.
Paragraph (version A):
The contents of the inner struct (field3 and field4) are used as
input for the signature/hash algorithm.  The length of the structure,
in bytes, would be equal to two bytes for field1 and field2, plus two
bytes for the signature and hash 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 B):
followed by the encoding of the inner struct (field3 and field4).
Paragraph (version B):
The length of the structure, in bytes, would be equal to two bytes
for field1 and field2, plus two bytes for the signature and hash
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):
Here handshake_messages refers to all handshake messages sent or
received, starting at client hello and up to, but not including,
this message, including the type and length fields of the
handshake messages.  This is the concatenation of all the
Handshake structures (as defined in handshake-protocol) exchanged
thus far.  Note that this requires both sides to either buffer the
messages or compute running hashes for all potential hash
algorithms up to the time of the CertificateVerify computation.
Servers can minimize this computation cost by offering a
restricted set of digest algorithms in the CertificateRequest
message.
Paragraph (version B):
Here handshake_messages_hash is a digest of all handshake messages
sent or received, starting at ClientHello and up to, but not
including, this message, including the type and length fields of
the handshake messages.  This is a digest of the concatenation of
all the Handshake structures (as defined in handshake-protocol)
exchanged thus far.  For the PRF defined in Section 5, the digest
MUST be the Hash used as the basis for the PRF.  Any cipher suite
which defines a different PRF MUST also define the Hash to use in
this computation.  Note that this is the same running hash that is
used in the Finished message server-finished.
Paragraph (version B):
The context string for the signature is "TLS 1.3, server
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.