Re: [TLS] Remove signature algorithms from cipher suites in 1.3

Antoine Delignat-Lavaud <> Tue, 23 December 2014 11:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4253C1ACDB5 for <>; Tue, 23 Dec 2014 03:26:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.402
X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S9RvUY8KK5gM for <>; Tue, 23 Dec 2014 03:26:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D9331ACDA9 for <>; Tue, 23 Dec 2014 03:26:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=bUGsN1dFPokCDdaMriQl9qfO9GCjz99e9EFAajYsXOI=; b=ia/7Wk5qgq7CJoh+vII+PE+VLGjsM+M3qbCRR7eIFv/7GhfnINZi51NzujkEgQ4Vkjq3DpflNNkGDgODdXfKdZpVaunxNK5kSIYlNq1uM+LSZlNOT+yTHu0ZZ7rvEmnB;
Received: from localhost (authenticated.user.IP.removed [::1]) by with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (envelope-from <>) id 1Y3Nc2-00084T-54 ; Tue, 23 Dec 2014 12:26:50 +0100
Message-ID: <>
Date: Tue, 23 Dec 2014 12:26:27 +0100
From: Antoine Delignat-Lavaud <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Hanno Böck <>,
References: <> <20141223102635.3bda9ed2@pc>
In-Reply-To: <20141223102635.3bda9ed2@pc>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] Remove signature algorithms from cipher suites in 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Dec 2014 11:26:56 -0000


Le 12/23/2014 10:26 AM, Hanno Böck a écrit :
> Do I understand your proposal right that it'd result in:
> a) If we use the normal RSA certificates we have today TLS 1.3 would
> continue using RSA-PKCS#1v1.5
> b) If the user gets a designated RSA-PSS key/certificate it'd use PSS?
> I think this would result in a near-zero-adoption for PSS probably for
> a very long time because you'd depend on the CA to do anything.

No, in my proposal, the algorithm used in CertificateVerify messages is 
negotiated based on advertised support in the "signature algorithms" 
extension (and supported_signature_algorithms field in 
CertificateRequest). Clients are encouraged to prioritize rsa-pss/sha256 
over rsa/sha256 or rsa/sha1, and supporting servers may pick PSS even if 
their certificate chain only contains rsa/sha256 and rsa/sha1.

> (Please note that the algorithm identifier for PSS already exists for
> X509, it's RFC 4055. It allows Keys with an algorithm identifier
> restricting to PSS, but that's no requirement - you can use the old
> keys for PSS as well, as technically they're no different.)

If anything, my own concern is the opposite. Allowing the same RSA key 
to be used to sign with both PSS and PKCS#1v1.5 is considered 
cryptographic malpractice, as the composition of secure and weak 
signatures may very well be broken. However, servers have the ability to 
avoid this risk by sending a different certificate depending on whether 
the client advertises support for PSS or not, even if the two 
certificates are signed with PKCS#1 (the proof of the protocol will 
probably assume servers enforce this behavior).

Furthermore, one of the issues of PSS in RFC 4055 is its reliance on 
signature parameters, which have tricky agility characteristics. For 
everyone's sake, it may help adoption if new OIDs for PSS signatures 
were used that correspond to fixed parameters. In any case, this 
discussion is out of the scope of the TLS WG.