Re: [TLS] RSA-PSS in TLS 1.3

Yoav Nir <ynir.ietf@gmail.com> Wed, 02 March 2016 06:37 UTC

Return-Path: <ynir.ietf@gmail.com>
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 451371A1A25 for <tls@ietfa.amsl.com>; Tue, 1 Mar 2016 22:37:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 QUtT7479GqUB for <tls@ietfa.amsl.com>; Tue, 1 Mar 2016 22:37:49 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50CC1A0470 for <tls@ietf.org>; Tue, 1 Mar 2016 22:37:48 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id l68so65784717wml.0 for <tls@ietf.org>; Tue, 01 Mar 2016 22:37:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4Nc9gZB6xGItpO1Zv8zMorlLZa/IirBvhLJB4XzYd8w=; b=owHjZEuZBkvFquwBiffAPsxr6Wwa1goqzz9ZvsMLjQseP/hOjUd5hN1wr5jUXnqJ+x kVfVJJ7oqtU9nHdxTIZmzBTObt39+JczDsKOv3Rgzc33JhdMnZt2zPkUAZpoySV2uvVF ezxR6XMN3g6g+KOIkOdBTQHpp0WeaJmOudlDqv5JA+RPNo1bDPgblCQ9lEzk2efeQowW nUjXPJfNWzeum3/OLK7vz7mmWHak76vcRoJBF1xcZO2RXs4+RFtytNKywNFiEOreM+aR SCOvpKBFv3X3VPl479UZVyaSSV3+j9jpmCP9ALxq6pWlRf0JF+Zw2iEAH+TQGM6OP81p /dOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4Nc9gZB6xGItpO1Zv8zMorlLZa/IirBvhLJB4XzYd8w=; b=WpI35QCxKL3YPKEfehFkmxOEdNPXJV16ZOJirSDkZMsdiolq07ZFwR9DqLFtcPJmS1 5BXF/tL+q7WE4UKC0kM85u+1vWzuZ4xOmvERMdVvnTYhHG3NcCqosr2J2Vb91MOOEsPu TX+uTyMzpkvQERHxtbUtF6rOf8QlUsH3OPj9qVLlB0Yt9Lhqdrzbnbox0thfej6KiSBf stfQwcwTiR0ZEXOZZQj7LFejJcMQGpQVu+pSXvESJJ9qI7QLPHUk1ei6LqCoeRDts1k9 YjvYEyvKvELL6f310IQRmR5adIS60aGhycFEANom61CLiA7J36AwgGzLa6Ia3E6wQiNW kB5w==
X-Gm-Message-State: AD7BkJJLVGwx5Kh5fQzPCiOu/FTrEabIZQE37dgmKIwAzbOfp/9C12YDIayv8LWDY2bRAw==
X-Received: by 10.28.145.8 with SMTP id t8mr2735715wmd.103.1456900667216; Tue, 01 Mar 2016 22:37:47 -0800 (PST)
Received: from [192.168.137.52] ([176.13.3.32]) by smtp.gmail.com with ESMTPSA id av3sm34361880wjc.44.2016.03.01.22.37.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 22:37:46 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <56D63BC7.5010302@brainhub.org>
Date: Wed, 02 Mar 2016 08:37:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC718116-64C4-46C0-870C-D82DE64B4C63@gmail.com>
References: <CAOgPGoD=AAFDUXN8VkOHwTMEUm+-qi548NsicoD=1yQKSu-sng@mail.gmail.com> <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <DE710794-CA42-48E1-9AB9-A2BE2899E071@gmail.com> <56D5DE1D.3000708@akr.io> <BBA8149E-114A-49D3-8159-A87ADB545482@gmail.com> <56D63BC7.5010302@brainhub.org>
To: Andrey Jivsov <crypto@brainhub.org>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/T0i1BwHS1csjXsqD5G6B_2Wkj-E>
Cc: tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 02 Mar 2016 06:37:51 -0000

> On 2 Mar 2016, at 3:03 AM, Andrey Jivsov <crypto@brainhub.org> wrote:
> 
> On 03/01/2016 11:20 AM, Yoav Nir wrote:
>> 
>> On 1 Mar 2016, at 8:23 PM, Alyssa Rowan <akr@akr.io> 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: https://www.ietf.org/mail-archive/web/tls/current/msg19096.html .
> 
> 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?

The easy answer is: because we can. We can’t mandate for the CA industry what kind of certificates they should issue, or rather, we can, but they’ll rightly ignore us. We *can* mandate how a new TLS 1.3 implementation signs for another new TLS 1.3 implementation. Mandating that the certificates are signed with PSS would definitely slow down the adoption of TLS 1.3. Mandating what algorithm is used within the protocol does not. 

As long as the spec allows PKCS#1 all implementations will support it and many implementors will delay PSS because it’s not needed for interoperability. That’s what a rational manager would do: implement TLS 1.3 with PKCS#1 now, and place implementing PSS “on the roadmap”. I don’t think we should give them that incentive.

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

That depends. Did we find that PSS is insecure in this 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.

Both servers and clients tend to use libraries that implement both the protocol and the algorithms. OpenSSL springs to mind, as do NSS, GNUTLS, SChannel and whatever Apple calls their library. Sure there are separate libraries with software handshakes and hardware algorithms. Even OpenSSL does this with their “engines”. I don’t think this is reason enough to keep dragging obsolete algorithms with us.

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

Because this is a particular field that we control.

Yoav