Ilari Liusvaara <ilariliusva...@welho.com> wrote: >> The text above indicates the salt length for TLS messages. There are no >> restrictions placed on certificate signature salt lengths. Does this mean >> that >> any valid salt length (from 0 to the maximum permitted) must be supported? > > Well, the code I have written enforces the salt length restriction also on > any possible RSA-PSS certificates in chain.
RSA PSS with a zero-length salt is a deterministic, subliminal-channel-free signature scheme. It is one of the few signature schemes that structurally prevent an HSM from directly leaking (parts of) the private key in an undetectable way. The PKCS#11 interface for RSA-PSS in particular only allows one to choose the length of the salt, not the value of the salt, thus using a zero-length salt is the only way to ensure that a HSM doesn't leak the private key. Accordingly, I think it's a bad idea for clients to enforce the salt length requirement, and for the TLS 1.3 draft to specify a requirement for a salt (that isn't empty). Although I originally suggested the salt length requirement that was added to the TLS 1.3 draft, I now am pretty sure it was a mistake. I'm pretty sure that PSS signatures can be *proven* to be safe with just 1 bit of salt in TLS, because the message that is being signed contains at least 1 random bit (from each party). Note also that it has already been proven many years ago that the salt length requirement that the TLS 1.3 draft currently imposes is too large. Similarly, in the case of the Web PKI, most CAs include at least one random bit in each certificate they sign, so it should be possible to construct the same proof for such certificates. > This comes from not even having RSA-PSS validation code that could deal > with arbitrary salt length. This is currently the case in my own software (*ring* and webpki) too, but I plan to make changes to both of them so that 0-length and maybe 1-bit salts are also acceptable, once the proof of security of shorter salt lengths is done. Note also that most deployed RSA-PSS certificates (that I've seen) are generated from Microsoft's software, which was (is?) hard-coded to use SHA-1 as the MGF digest function. Some newer software doesn't accept SHA-1 as the MGF digest function and so there's a trap there, regardless of the salt length issue. >> Additionally PSS signatures (see RFC4055) can be used with RSA keys >> (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does the >> RSASSA-PSS mean that both types must be accepted? It is better to implement id-RSASSA-PSS. (It is also good to enforce that certificates with a keyUsage extension that doesn't indicate encryption aren't used for RSA encryption, which is a related problem.) Cheers, Brian -- https://briansmith.org/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
