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

Sean Turner <> Mon, 25 January 2016 17:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ACBDD1B3798 for <>; Mon, 25 Jan 2016 09:31:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QRLj01r7KpJQ for <>; Mon, 25 Jan 2016 09:31:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EBC11B3794 for <>; Mon, 25 Jan 2016 09:31:16 -0800 (PST)
Received: by with SMTP id u68so40303534ykd.2 for <>; Mon, 25 Jan 2016 09:31:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=KOxSeZubhD8T4ADB+2wmRanCTnf9j30Gqcm7YF7+98U=; b=bbV6dxxDR+QovKCXwj9cNi6Ip6GxYrRgfQ2KxxkN9OWGTXaaGd7hPzp/hxpSQvoAZs K38D6t8FtYSi4w490mqyefapc2Ed8cY8g6n3eecyhoowXwbo06qneePa00MBMUncfdVS E1SI3ua16NRcojAbohlNaE9CVXe6CWErmVaSQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=KOxSeZubhD8T4ADB+2wmRanCTnf9j30Gqcm7YF7+98U=; b=PF54NyModA2fuFpjBJ8fXbZJPrB+oHWwhl3bgwRPEeqt3YZYdzYuMMUhO4vO/LO3cl a1bB2WYx/CSXVjMztqod8QHrjBQsowSDOP25MwogbuePzuIN56jtKDXXxaO52lVFZosX FTHtW2h40L595hStS2gIP6t50fYcANOxweUXzRHM25ZOSstjC/4mKcVHQ15cdSkrCi6l HTQAQiixyyodHFqMtMf/njszQ5LObT50+xx+pS7HxhZ0814ZD27KnWTzC21YRy9HsDXS e9GC2trE0Y8hxOizmJO84W+F08Z32A2kOOx6RQK+QGtYLzTF/BuToNe0Cw1xfZXHLhEy 4RQA==
X-Gm-Message-State: AG10YOS82vBTS2ZlndCgg4QT23llWShs2O2hv4I7i3HcwQCWTdSvzNURrLXCAeLsSYnm3w==
X-Received: by with SMTP id v63mr9687380ybb.71.1453743075386; Mon, 25 Jan 2016 09:31:15 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id v130sm14839809ywe.24.2016. for <> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 09:31:14 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Sean Turner <>
In-Reply-To: <>
Date: Mon, 25 Jan 2016 12:31:13 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "" <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Subject: Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 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: Mon, 25 Jan 2016 17:31:18 -0000


Andrey sent this message at the chairs' request to make sure that we adequately discussed the issue, which we discussed at the last IETF meeting (


> On Jan 21, 2016, at 21:25, 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  <>] 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.
> Unfortunately, the product I work on, which is responsible for ~15% of Internet traffic, is not compatible with the "frictionless idea" due to the current TLS 1.3 spec [1] mandating PSS in the handshake.
> The issue here is that these already sold products use 3d party components that can only perform RSA signing with CRT optimization when the padding is PKCS1 1.5. In the best case this means ~2x performance penalty for TLS 1.3. In the worst case the existing server keys cannot do PSS signature if the keys are on FIPS-certified devices.
> The same issue applies to client TLS authentication with smartcards. Many smartcards cannot do PSS, e.g. [3].
> Likewise, it's unclear if PSS is supported by e.g. PKCS#11 libraries of HSM vendors, or the HSM hardware.
> Other products on the Internet use the same components, so that 15% is a minimum I know of.
> 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.
> Can support for PSS be added by 3d party vendors? If the limitation is in middleware like PKCS#11 or in firmware/microcode, this is technically possible. This does require an update and the brings version dependency. Further, if the firmware is FIPS 140-2 certified, this type of upgrade will have re-certification cost (more friction). In some cases this is a physical limitation. For example, I know from my experience working on smartcard decryption a few years back that the chips themselves insist on PKCS#1.5 padding for half of the vendors we supported and won't e.g. accept raw or OAEP padding with RSA, e.g. [2]. It is apparent from the specs that [3] does support PSS while [2] doesn't.
> I prepared the slides on this subject for Yokohama [5]. I believe Eric Rescorla presented these.
> How much do the members of the WG value the idea of lower hurdles to the deployment of TLS 1.3? Is there desire to add a PKCS#1 1.5 signature fallback, just like there is one already for X.509 certificates in TLS 1.3?
> 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.
> Thank you.
> [1]
> [2] 4.4 has no PSS:
> [3] 5.0 has PSS:
> [4] 2x more legacy than PSS:
> wget
> $ grep RSASSA-PSS rsanewval.html | wc -l
> 593
> $ grep RSASSA-PKCS1_V1_5 rsanewval.html | wc -l
> 2005
> $ grep RSASSA rsanewval.html | wc -l
> 2607
> [5]
> _______________________________________________
> TLS mailing list