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