[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [94.23.252.34]) (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 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
- [TLS] Remove signature algorithms from cipher sui… Antoine Delignat-Lavaud
- Re: [TLS] Remove signature algorithms from cipher… Brian Smith
- Re: [TLS] Remove signature algorithms from cipher… Hanno Böck
- Re: [TLS] Remove signature algorithms from cipher… Antoine Delignat-Lavaud
- Re: [TLS] Remove signature algorithms from cipher… Antoine Delignat-Lavaud
- Re: [TLS] Remove signature algorithms from cipher… Brian Smith
- Re: [TLS] Remove signature algorithms from cipher… Hanno Böck
- Re: [TLS] Remove signature algorithms from cipher… Russ Housley