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

Andrey Jivsov <crypto@brainhub.org> Fri, 22 January 2016 18:39 UTC

Return-Path: <crypto@brainhub.org>
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 7A3241B2BCA for <tls@ietfa.amsl.com>; Fri, 22 Jan 2016 10:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPpZtbeF0jeO for <tls@ietfa.amsl.com>; Fri, 22 Jan 2016 10:39:29 -0800 (PST)
Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D361B2BCB for <tls@ietf.org>; Fri, 22 Jan 2016 10:39:28 -0800 (PST)
Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-11v.sys.comcast.net with comcast id 96fP1s0045Clt1L016fUoq; Fri, 22 Jan 2016 18:39:28 +0000
Received: from [IPv6:::1] ([73.170.34.26]) by resomta-po-17v.sys.comcast.net with comcast id 96fT1s0020ZpzqZ016fTmA; Fri, 22 Jan 2016 18:39:28 +0000
Message-ID: <56A2775E.5010507@brainhub.org>
Date: Fri, 22 Jan 2016 10:39:26 -0800
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Hubert Kario <hkario@redhat.com>, tls@ietf.org
References: <56A192FC.4060206@brainhub.org> <3013469.iP5Fz9KfdM@pintsize.usersys.redhat.com>
In-Reply-To: <3013469.iP5Fz9KfdM@pintsize.usersys.redhat.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453487968; bh=V42tADVCwDFDwAq9QnrQqj/RfEvO9jXUc1riBkL0gRQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hM44U5rBnXq8s7BRwUi6aJh8xPwaVXLInrmwc6J2m77Ymf6W4279ffv1vIPjMn9K1 fDy+ZaAlGertkvWCpKdNJqzMMRegXMEKOrTBYJN1aRuvFhxBGnuM6txr7cs3GfWU2F TE2tpLlvoKZViBrN3Y5EoCFKBGZa2U6kSMU4UPY8FPFMw+qvVM7ToN1RToRGWrxhjX vafe1cmwT2FjinPCQX3cPlWGHJ4CtP9rAG7+0UpWF3f96UFqPIg8JuHd3ZarVV1H1m HJV1vbxOpg1cI3oQmr6Ma2IinDJBwoSvlEC321+5pH0DphZMr0d68HktHI0AA6T5cE rwCm5r7kh0lJA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/k6-c-Q2t8hOREKKik5u11NsFn6E>
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 18:39:32 -0000

On 01/22/2016 03:14 AM, Hubert Kario wrote:
> 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 issue here is to be able to use existing hardware with TLS 1.3.

The CAs got PKCS#1 1.5 exemption under TLS 1.3. I suppose that the 
reason HS did not get matching capability is it was believed that 
PSS-only would not be a problem. I noted a few problems with PSS in HS.

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

HKDF is somewhat orthogonal to the this thread.

I was pointing out that there are devices, e.g. FIPS PCI cards or 
smartcard, that "hold" RSA keys. Some of them can only do RSA PKCS#1 1.5 
signing with these keys. These devices work with TLS 1.2 and won't work 
with TLS 1.3. These problems might be fixable if vendors are willing to 
do so, but observe that for FIPS devices this means more costly and 
slower re-certification, not just firmware update.

Regarding HKDF, note that FIPS 140-2 specifically says that it doesn't 
certify TLS, SSH, or protocols in general. It certifies crypto 
primitives. Vendors are free to chose which crypto primitives they 
certify (and this set is noted on the FIPS certificate).

KDFs in TLS are covered by 
http://csrc.nist.gov/groups/STM/cavp/documents/components/askdfvs.pdf. 
TLS 1.2 KDF is noted as "TLS KDF" on 
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2014.htm . 
Not many modules claim certification for TLS KDF for current TLS and 
this may continue to be the case for HKDF in TLS.

In our case we do TLS KDF "ourselves" and I think other conceivable 
implementations can do this too, so this is not an issue in this thread.

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

You mean for HS only, while leaving it for X.509 certs?

More importantly, note that while I understand the intent to increase 
security by mandating PSS in TLS 1.3, in practice it doesn't work.

We/our customers will have to select the highest protocol that works (or 
is reasonably fast). If the spec is written to mean (TLS1.3 && PSS), if 
we can't do PSS, we can't do TLS 1.3. There are other desirable security 
enhancements in TLS 1.3, besides PSS, that would be nice to deploy.