On Thursday 21 January 2016 18:25:00 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 > > <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.
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/ > 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. 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
