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

Hanno Böck <> Thu, 25 December 2014 20:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 547351A885B for <>; Thu, 25 Dec 2014 12:21:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xh_whw8n_fcY for <>; Thu, 25 Dec 2014 12:21:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEB631A885A for <>; Thu, 25 Dec 2014 12:21:36 -0800 (PST)
Received: from pc ( [::ffff:]) (AUTH: LOGIN, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by with ESMTPSA; Thu, 25 Dec 2014 21:21:32 +0100 id 000000000000001A.00000000549C71CC.00006AE7
Date: Thu, 25 Dec 2014 21:21:41 +0100
From: Hanno Böck <>
To: Antoine Delignat-Lavaud <>
Message-ID: <20141225212141.61122705@pc>
In-Reply-To: <>
References: <> <20141223102635.3bda9ed2@pc> <>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary=""
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: Thu, 25 Dec 2014 20:21:39 -0000


On Tue, 23 Dec 2014 12:26:27 +0100
Antoine Delignat-Lavaud <> wrote:

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

Okay, then I misinterpreted you.

But my point remains: Why not just say "TLS 1.3 has to use RSA with
PSS, mo more PKCS #1 1.5"?

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

I am aware that using same key for both protocol versions is bad
practice. However are you aware of any sign this may be a real risk?

Anyway, for the scenario that TLS 1.3 uses only PSS, could a server
send different keys for <=1.2 and 1.3?

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

I know all the problems, I implemented this once :-)

Hanno Böck