Re: [TLS] RSA-PSS in TLS 1.3

Andrey Jivsov <> Wed, 02 March 2016 01:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4AD2B1B4445 for <>; Tue, 1 Mar 2016 17:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 71sz1gx1KWD9 for <>; Tue, 1 Mar 2016 17:05:20 -0800 (PST)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E533D1B443D for <>; Tue, 1 Mar 2016 17:05:19 -0800 (PST)
Received: from ([]) by with comcast id Qp5D1s0044vw8ds01p5Gva; Wed, 02 Mar 2016 01:05:16 +0000
Received: from [] ([]) by with comcast id Qp331s00Q1ivTfo01p36YZ; Wed, 02 Mar 2016 01:03:14 +0000
References: <> <> <20160229233617.5466ebd3@pc1> <> <> <> <>
From: Andrey Jivsov <>
Message-ID: <>
Date: Tue, 1 Mar 2016 17:03:03 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1456880716; bh=qHXUzGhQzDc4hQY386oiQfp+dHISwUY2FbC/HzTSMOU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=l8R+TVbKU6h4IbPr00v76/TePcaY6U2dg+FNs9j6GEiMfDHwnqktKhjKpuyr2YvXf 4lMkeSG+HRwBszpUis42wjdXvRl266uCIqHxabCYfhd1kKuxSdcnhsG2BGw40jdR6e Tm6TO1lD/8SpPD7X3EUdwYAlAILSbU9ORUu7sgK+ckUQa8lu16nqLKLFALNtGJ+0tI vBE1QARKwVzOKH2WEVSU3X4Z81sV/VA2lD2NLqxcfuIqljNbJ6ILt8eKa/aiPRDk4m JY8Wfsq1+tZSULSRSzm9WCPFPcQduoDXiMKS36XM9MmxnDzGZVgOGqHtnbl4fkNI6R Ng994pzoYVleA==
Archived-At: <>
Subject: Re: [TLS] RSA-PSS in TLS 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: Wed, 02 Mar 2016 01:05:22 -0000

On 03/01/2016 11:20 AM, Yoav Nir wrote:
> On 1 Mar 2016, at 8:23 PM, Alyssa Rowan <> wrote:
>>> [YN] It would be cool to ban PKCS#1.5 from certificates, but we
>>> are not the PKIX working group. Nor are we the CA/Browser forum.
>>> When a CA issues a certificate it has to work with every client
>>> and server out there, When we use TLS 1.3, the other side supports
>>> TLS 1.3 as well, so it’s fair to assume that it knows PSS.
>> Perhaps the PKIX working group and CAB/Forum could both use a friendly
>> reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains?
> Neither you nor I can post in any of the CA/Browser forum’s lists, because neither of us has either a browser or a public CA.
> There are some people who are active there and are reading this list, so they might take such a proposal there. I’m not very optimistic, though. While only CAs and browsers are members, they are keenly aware that even the public CAs have a wide variety of relying parties, running all sorts of software. And it’s much harder to scan clients than it is to scan servers, so it’s difficult to say how many clients will not be able to connect to a server with a certificate signed with RSA-PSS. Probably far too many for the CA/BF to be comfortable deprecating PKCS#1.
> The PKIX working group has shut down several years ago. The Curdle WG is a new working group whose charter includes deprecating obsolete stuff. Perhaps they might be interested.
> Yoav

The removal of PKCS #1.5 signature support in TLS 1.3 is a client issue 
when client authentication is used. See examples here: .

Regarding server-only authentication, it seems that there is assumption 
that TLS 1.3 will continue to use PKCS#1.5 for a long time in X.509 
certs. Then why "break Internet" or slow down adoption of TLS 1.3 by 
mandating PSS in one field of handshake?

Imagine that there is PSS#2 in the future. Is the intent to issue new 
TLS 1.4 that bans PSS and hardwires PSS#2? If not, there may still be a 
signature negotiation mechanism in TLS 1.3 in the future.

The reasons CAs are cold to adoption of PSS are similar to these of TLS 
servers or clients: 3d-party dependence, prior investment, FIPS 140 
certification, cost.

TLS WG can ban PKCS #1.5 in CA certs in TLS 1.3, but it wisely doesn't. 
Why one signature field is an exception? IMO this will lead to slower 
adoption of TLS 1.3, on balance. Nothing prevents e.g. OpenSSL from 
implementing PSS in HS (which is proposed as MUST anyway). Nothing 
prevents servers from not negotiating TLS 1.3.

> _______________________________________________
> TLS mailing list