Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

Hubert Kario <hkario@redhat.com> Fri, 22 January 2016 11:22 UTC

Return-Path: <hkario@redhat.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 EF7B21A044E for <tls@ietfa.amsl.com>; Fri, 22 Jan 2016 03:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 2UNBKR0t0UGK for <tls@ietfa.amsl.com>; Fri, 22 Jan 2016 03:22:46 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4737E1A0439 for <tls@ietf.org>; Fri, 22 Jan 2016 03:22:46 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 24F965375; Fri, 22 Jan 2016 11:14:10 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-125.brq.redhat.com [10.34.0.125]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0MBE9kJ016714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2016 06:14:10 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Fri, 22 Jan 2016 12:14:04 +0100
Message-ID: <3013469.iP5Fz9KfdM@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; )
In-Reply-To: <56A192FC.4060206@brainhub.org>
References: <56A192FC.4060206@brainhub.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2014552.nqi3SfhAKr"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/xOaduKVCHP41RA6CAEYWzrtlZZw>
Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 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: Fri, 22 Jan 2016 11:22:48 -0000

On Thursday 21 January 2016 18:25:00 Andrey Jivsov wrote:
> Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the
> following language in sec 4.8.1
> 
> >     In RSA signing, the opaque vector contains the signature
> >     generated
> >     using the RSASSA-PSS signature scheme defined in [RFC3447 
> >     <http://tools.ietf.org/html/rfc3447>] with MGF1. The digest
> >     used in the mask generation function MUST be the same as the
> >     digest which is being signed (i.e., what appears in
> >     algorithm.signature).  The length of the salt MUST be equal to
> >     the
> >     length of the digest output.  Note that previous versions of TLS
> >     used
> >     RSASSA-PKCS1-v1_5, not RSASSA-PSS.
> 
> The
> 
> >        struct {
> >        
> >           SignatureAndHashAlgorithm algorithm;
> >           opaque signature<0..2^16-1>;
> >        
> >        } DigitallySigned;
> 
> defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec 
A.3.1.1:
> >        enum {
> >        
> >            rsa(1),
> >            dsa(2),
> >            ecdsa(3),
> >            rsapss(4),
> >            eddsa(5),
> >            (255)
> >        
> >        } SignatureAlgorithm;
> 
> since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificates
> only.
> 
> 
> Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be as
> frictionless as possible regarding the upgrade of existing TLS
> installations to TLS 1.3. We should expect that all TLS 1.3 servers
> and clients will have support for older versions of TLS on the same
> node. Ideally, it should be possible to upgrade the software /
> firmware to add TLS 1.3 support on existing hardware with minimal
> penalty.

The transition to TLS 1.3 is not urgent matter. Making sure that it is 
as robust as possible is of higher importance than "making it easy to 
implement for existing TLS1.2 implementations".

That's right there in the charter:
https://datatracker.ietf.org/wg/tls/charter/

> The current list of FIPS 140 products that support RSA shows twice as
> many products that support RSASSA-PKCS1_V1_5 than these that support
> RSASSA-PSS [4]. There is greater than 50% chance to lose FIPS
> certification with TLS 1.3, factoring client auth and servers.

You also need a FIPS certified implementation of HKDF. So yes, it most 
likely will require new certifications.

> The only solution that's available at this point is conditioning TLS
> 1.3 support on appropriate hardware. For this reason TLS 1.3 it
> probably won't be enabled by default in the product I work on. I
> would prefer for TLS 1.3 to be enabled by default and write the code
> to decide whether it does PSS or falls back to RSA PKCS1 1.5.

Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not cutting 
it off now would be negligent.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic