[TLS] Remove signature algorithms from cipher suites in 1.3

[Antoine Delignat-Lavaud <[e-mail]>]

Dear WG,

This topic has been brought up in previous discussions but, following 
private discussion with ekr, I would like to bring it up again.

The current draft of TLS 1.3 relies exclusively on signatures to prove 
ownership of private keys in certificates, dropping support for static 
DH shares in certificates. Furthermore, it mandates support of a 
dedicated negotiation mechanism for signature algorithms. This 
negotiation is a bit asymmetric, since the client sends its supported 
pairs of algorithm and hash function in the "signature_algorithms" 
extension while the server uses the "supported_signature_algorithms" 
field of the CertificateRequest message (I won't elaborate any more on 
this topic but it may be worth thinking about).

In this design, keeping the legacy of including the signature algorithm 
to be used in the ServerCertificateVerify message within the selected 
cipher suite name can be a burden to the modularity and extensibility of 
the protocol, since adding support for new signature algorithms comes at 
the cost of an exponential increase in the length of the list of cipher 
suites sent by the client, even though the security guarantees of the 
handshake are now fully modular w.r.t authentication goals achieved by 
certificate and signatures.

The tensions between cipher suite and signature algorithm negotiation 
already existed in 1.2 and it led to oddities in the protocol, such as 
the inability to use FF-DHE authenticated by ECDSA, even though there 
isn't anything inherently wrong with this combination. The following 
paragraph, taken from the current 1.3 draft, is another instance of this 
awkwardness:

"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 offer DHE_DSS key exchange but omit any 
DSA pairs 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."

Hence, I am proposing to create a pull request that includes the 
following changes:

- Any new cipher suite introduced from version 1.3 onwards MUST NOT 
contain any signature algorithm name (e.g. 
ECDHE_CHACHA20_POLY1305_SHA256). Keeping a hash algorithm even for AEAD 
ciphers remains necessary to determine the PRF to use;
- For compatibility with previous protocol versions, existing cipher 
suite names are preserved; however, servers MUST NOT select any cipher 
suite that includes a signature algorithm other than RSA in a 1.3 handshake;
- The server must use one of the client's supported signature algorithms 
in its CertificateVerify message. The precise algorithm used may depend 
on the client's indicated preferences and on the server's policy (in the 
spirit of current cipher suite negotiation). All certificates in a chain 
MUST also be signed with signature algorithms supported by the client. 
The same requirements apply even if a pre-1.3 cipher suite (such as 
ECDHE_RSA_AES256_GCM_SHA384) was selected: the algorithm in the cipher 
suite name is ignored.

Do note that there are several possible alternatives to the propositions 
above, and I am not set on any particular choice. For instance, it may 
be easier to forbid all pre-1.3 cipher suites and create a fresh list.

Even though these changes should be straightforward to understand, it 
appears that they would require significant edits to many parts of the 
current draft, which is why I would like to see if a consensus could 
emerge on this question before proceeding with the necessary work on a 
pull request.

The main motivation for proposing these changes is to introduce support 
for PSS signatures in TLS and in certificates. You may have heard about 
the Bleichenbacher-like universal forgery attack in NSS that I recently 
discovered with Brian this summer (also known as "BERserk", name by 
Intel): such bugs should remind us that PKCS#1v1.5 is a fragile 
signature algorithm ([EC]DSA can also be hazardous in its randomized 
variant, as shown by Sony hack and recent bitcoin thefts), and the fact 
that TLS not only mandates its use, but also explicitly prohibits better 
alternatives ("a certificate with RSASSA-PSS signature key cannot be 
used because TLS defines no corresponding signature algorithm") is 
hardly acceptable.

Hence, I propose to include with this change the introduction of a new 
SignatureAlgorithm value rsa-pss(4) that denotes PKCS#1v2.2 RSASSA-PSS 
signatures with default parameters (mgf1SHA1 for mask generation and the 
length of the message digest function output as salt length). It may 
take time before this change impacts PKIX and CAs, but it is at least a 
necessary first step.

Best,

Antoine