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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
