Re: [TLS] PSS and TLS 1.3

[Brian Smith <[e-mail]>]

Ilari Liusvaara <[e-mail]> 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/