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

From: Andrey Jivsov <[email-masked]>
Date: Thu, 21 Jan 2016 18:25:00 -0800

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.

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] http://tools.ietf.org/html/draft-ietf-tls-tls13-11.html
[2] 4.4 has no PSS: 
http://jp.atos.net/content/dam/global/we-do/cardos-datenblatt.pdf
[3] 5.0 has PSS: 
https://atos.net/content/dam/global/we-do/cardos-v5-datenblatt.pdf

[4] 2x more legacy than PSS: 
http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html
wget http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html
$ 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] https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf 
https://www.ietf.org/jabber/logs/tls/2015-11-04.html

---

From: Hubert Kario <[email-masked]>
Date: Fri, 22 Jan 2016 12:14:04 +0100

On Thursday 21 January 2016 18:25:00 Andrey Jivsov wrote:
> >     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
> 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/

> 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

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 22 Jan 2016 10:39:26 -0800

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

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

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

---

From: Hubert Kario <[email-masked]>
Date: Fri, 22 Jan 2016 20:14:43 +0100

On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:
> > Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not
> > cutting it off now would be negligent.
> 

If we don't do it for HS in TLS first, we'll never get rid of it in 
X.509 certs.

We need to start somewhere, and it's more reasonable to expect that 
hardware with support for new protocols will get updated for RSA-PSS 
handling than that libraries and hardware will suddenly start 
implementing it in droves just in anticipation of the time when CAs 
_maybe_ will start issuing certificates signed with RSA-PSS.

> security by mandating PSS in TLS 1.3, in practice it doesn't work.

We had to wait for XP SP2 to be over 10 years old for the CA's to even 
_consider_ using anything but SHA-1 for signatures. And most of them did 
that only on explicit request when requesting certificates.

If new signature types can't be deployed for new protocols they will 
never get deployed. There always will be implementations that do the 
absolute minimum to get interoperability *right now* and not a single 
extra step.
-- 
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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 25 Jan 2016 10:29:18 -0600

> _maybe_ will start issuing certificates signed with RSA-PSS.

Isn't it more a matter of TLS being a consumer of external PKIX
infrastructure, the web PKI, etc.?  They are out of the reach of the
IETF TLS working group; any requirements we attempted to impose would be
unenforceable, even if there was an Internet Police (which there is not).

-Ben

---

From: Sean Turner <[email-masked]>
Date: Mon, 25 Jan 2016 12:31:13 -0500

All,

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 (https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf).

spt

> On Jan 21, 2016, at 21:25, Andrey Jivsov <[email-masked]> wrote:
> 
> Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the following language in sec 4.8.1
> 
> 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.
> 
> [2] 4.4 has no PSS: http://jp.atos.net/content/dam/global/we-do/cardos-datenblatt.pdf
> [3] 5.0 has PSS: https://atos.net/content/dam/global/we-do/cardos-v5-datenblatt.pdf
> 
> [4] 2x more legacy than PSS: http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html
> [5] https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf https://www.ietf.org/jabber/logs/tls/2015-11-04.html
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 Jan 2016 20:43:22 +0100

On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote:
> IETF TLS working group; any requirements we attempted to impose would
> be unenforceable, even if there was an Internet Police (which there
> is not).

TLS will happily use PKCS#1 v1.5 signed X.509 certificates, so how 
exactly is creating a side effect of increasing the deployment rate of 
RSA-PSS _in TLS implementations_ an "overreach"?!
-- 
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

---

From: Russ Housley <[email-masked]>
Date: Mon, 25 Jan 2016 18:11:05 -0500

> RSA-PSS _in TLS implementations_ an "overreach"?!

I have been a supporter of PSS for a very long time -- see RFC 4055.

We have many algorithm transition issues, but this is one place where we have seen very little progress.  I would like to see support for PSS in the protocol, even if we need to support PKCS v1.5 for certificate signatures for a long time.

Russ

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 25 Jan 2016 19:32:57 -0800

> We have many algorithm transition issues, but this is one place where we have seen very little progress.  I would like to see support for PSS in the protocol, even if we need to support PKCS v1.5 f…

Is there evidence that hard-wiring {PSS} in HS and {PSS, PKCS#1 1.5} 
with X.509 certs will lead to better PSS adoption than if {PSS, PKCS#1 
1.5} were available in both HS and X.509 certs?

This should be balanced against the reality that PSS in HS with TLS 1.3 
guarantees lower TLS 1.3 adoption as I wrote above. PSS-only in TLS 1.3 
HS may make code more complex as well.

I am trying to imagine a logic that a TLS 1.3 client supporting 
smartcard client authentiation would need to implement, assuming 
mandatory PSS signing in HS, e.g. a case of Firefox + PKCS#11 interface 
with a smartcard.

First, the code should query (attached? logged-in?) smartcard(s) to 
determine if the key(s) on the smartcard that might be used for client 
authentication can do PSS signing. PKCS#11 interface lists the PSS 
capability as CKM_SHA256_RSA_PKCS_PSS mechanism. If no such PSS+hash 
mechanism is available, the code needs to tag the keys(s) as TLS 
1.2-only. When the client connects to a TLS 1.3 server and the server 
requests client authentication with the non-PSS key, I think this will 
require protocol dance down to TLS 1.2 (insecure TLS fallback). 
Alternatively, the client will need to start from TLS 1.2 when it 
detected such a smartcard, for any server.

The underlying reasons why CAs can't sign with PSS v.s. TLS server or 
client are probably overlapping in many cases: FIPS 140, HSM, hardware. 
The all-or-nothing approach to PSS sin HS eems inconsistent with 
traditional feature negotiation in TLS HS.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 26 Jan 2016 13:33:39 +0100

On Monday 25 January 2016 19:32:57 Andrey Jivsov wrote:
> >>>>>>> The only solution that's available at this point is
> >>>>>>> conditioning
> >>>>>>> TLS
> >>>>>>> would prefer for TLS 1.3 to be enabled by default and write
> >>>>>>> the
> >>>>>>> code
> >> exactly is creating a side effect of increasing the deployment rate
> >> of RSA-PSS _in TLS implementations_ an "overreach"?!
> > 
> > We have many algorithm transition issues, but this is one place
> > where we have seen very little progress.  I would like to see
> > support for PSS in the protocol, even if we need to support PKCS
> > v1.5 for certificate signatures for a long time.

Because if PKCS#1 1.5 is available for HS, many implementations still 
won't implement PSS and we won't move one step. OTOH, if the PSS is 
mandatory, they have a clear need to add this support.

8% of servers in Alexa top 1 million websites still won't sign the 
Server Key Exchange with anything but SHA-1[1], despite the fact that 
you need to have an implementation of SHA-256 to implement TLSv1.2 in 
the first place.

> client are probably overlapping in many cases: FIPS 140, HSM,
> hardware. The all-or-nothing approach to PSS sin HS eems inconsistent
> with traditional feature negotiation in TLS HS.

PSS in X.509 is not usable now because only fraction of clients and 
servers support it. That's why CA's don't sign certificates with it - to 
minimize support costs and reissue rates (in cases the customer finds 
out that he needs the "legacy" certificate).

 1 - https://securitypitfalls.wordpress.com/2015/12/07/november-2015-scan-results/
-- 
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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 Jan 2016 17:08:25 -0600

On 01/25/2016 01:43 PM, Hubert Kario wrote:
>>> X.509 certs. We need to start somewhere, and it's more reasonable to
>>> expect that hardware with support for new protocols will get updated
>>> for RSA-PSS handling than that libraries and hardware will suddenly
>>> start implementing it in droves just in anticipation of the time
>>> when CAs _maybe_ will start issuing certificates signed with RSA-PSS. 

There seems to be some confusion here; I am saying it would be an
overreach for us to insist that the X.509 certs we get use PSS.  The
best sense I can make out of this statement is that it is a response to
a claim that requiring PSS for TLS handshakes would be an overreach (it
is not).  Am I confused?

-Ben