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