[TLS] Remove signature algorithms from cipher suites in 1.3

Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr> Tue, 23 December 2014 03:05 UTC

Return-Path: <antoine@delignat-lavaud.fr>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 957FA1ACD56 for <tls@ietfa.amsl.com>; Mon, 22 Dec 2014 19:05:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XeBuFBRfrOvs for <tls@ietfa.amsl.com>; Mon, 22 Dec 2014 19:05:11 -0800 (PST)
Received: from argon.maxg.info (argon.maxg.info []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08FB11ACD57 for <tls@ietf.org>; Mon, 22 Dec 2014 19:05:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=cF4n4zjs5yS3bmnq7eTwdJtEdTphExMLoHeEy7y/Xe0=; b=QUEdFL1nvEmCDuNTP0+4yikBTfhv9CmR4xD1Gfn9NOCOC/hgAuCklb91I7sQNkfnsZY+g6aOX1SzHpT5jnWo3bl/YjTuxNkbkctElPstkBF+wFAKkXEMcvcGCqOXtRqZ;
Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (envelope-from <antoine@delignat-lavaud.fr>) id 1Y3FmS-000621-Rm ; Tue, 23 Dec 2014 04:05:04 +0100
Message-ID: <5498DBCE.1070909@delignat-lavaud.fr>
Date: Tue, 23 Dec 2014 04:04:46 +0100
From: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VN9ZZMxH1OGDv2HOtJ_ij-rqEe4
Cc: Karthik Bhargavan <karthik.bhargavan@gmail.com>, Alfredo Pironti <alfredo@pironti.eu>
Subject: [TLS] Remove signature algorithms from cipher suites in 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Dec 2014 03:05:13 -0000

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 

"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.