Specify padding and context strings for signatures

The TLS 1.2 ServerKeyExchange signature never included enough context
and it was possible to lift a signature for one ciphersuite into a
handshake for a different one. TLS 1.2 only avoided signature
repurposing attacks because of luck[1].

Additionally, TLS 1.2 allows an attacker to obtain a signature of a
message with a chosen, 32-byte prefix.

Because of this, this change causes TLS 1.3 to include 64 bytes of
padding at the begining of signed messages in order to easily clear the
chosen-prefix and also context strings to ensure that signatures cannot
be repurposed.

For more context, see
https://www.ietf.org/mail-archive/web/tls/current/msg14734.html

[1] https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf

Author: agl

draft-ietf-tls-tls13.md

@@ -322,6 +322,8 @@ draft-04
 
 - Remove renegotiation.
 
+- Update format of signatures with context.
+
 draft-03
 
 - Remove GMT time.
@@ -623,6 +625,20 @@ 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.
 
+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.
+
+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.
+
+Finally, the specified contents of the digitally-signed structure follow the
+NUL at the end of the context string. (See the example at the end of this
+section.)
+
 In RSA signing, the opaque vector contains the signature generated using the
 RSASSA-PKCS1-v1_5 signature scheme defined in {{RFC3447}}. As discussed in
 {{RFC3447}}, the DigestInfo MUST be DER-encoded {{X680}} {{X690}}. For hash
@@ -679,8 +695,16 @@ In the following example
            };
        } UserType;
 
-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
+Assume that the context string for the signature was specified as "Example".
+The input for the signature/hash algorithm would be:
+
+       2020202020202020202020202020202020202020202020202020202020202020
+       2020202020202020202020202020202020202020202020202020202020202020
+       4578616d706c6500
+
+followed by the encoding of the inner struct (field3 and field4).
+
+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
@@ -2569,6 +2593,8 @@ time of the CertificateVerify computation. Servers can minimize this
 computation cost by offering a restricted set of digest algorithms in the
 CertificateRequest message.
 
+The context string for the signature is "TLS 1.3, server CertificateVerify".
+
 >If the client has offered the "signature_algorithms" extension, the signature
 algorithm and hash algorithm MUST be a pair listed in that extension. Note that
 there is a possibility for inconsistencies here. For instance, the client might
@@ -3124,6 +3150,8 @@ This section describes protocol types and constants.
          }
     } CertificateVerify;
 
+The context string for the signature is "TLS 1.3, client CertificateVerify".
+
 ### Handshake Finalization Message
 
     struct {