Subject: [TLS] PSS and TLS 1.3

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 20 Jan 2017 17:43:21 +0000

Draft 18 says:

   RSASSA-PSS algorithms  Indicates a signature algorithm using RSASSA-
      PSS [RFC3447] with MGF1.  The digest used in the mask generation
      function and the digest being signed are both the corresponding
      hash algorithm as defined in [SHS].  When used in signed TLS
      handshake messages, the length of the salt MUST be equal to the
      length of the digest output.  This codepoint is defined for use
      with TLS 1.2 as well as TLS 1.3.

What are the requirements for certificates when these RSSSA-PSS is used?

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?

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?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 20 Jan 2017 20:14:55 +0200

> What are the requirements for certificates when these RSSSA-PSS is used?

AFAIK, no special requirements.
 
> 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.

This comes from not even having RSA-PSS validation code that could deal
with arbitrary salt length.
 
> RSASSA-PSS mean that both types must be accepted?
 
I don't think you will see the latter outside some test sites for a
while...

But hmm, I think I should implement RSA-PSS only keys in some of my
stuff...

-Ilari

---

From: Brian Smith <[email-masked]>
Date: Fri, 20 Jan 2017 09:29:04 -1000

> 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.

> 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.

>> 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/

---

From: Adam Langley <[email-masked]>
Date: Fri, 20 Jan 2017 12:37:08 -0800

On Fri, Jan 20, 2017 at 11:29 AM, Brian Smith <[email-masked]> wrote:
> leaking (parts of) the private key in an undetectable way.

Brian's disowned recommendation in the TLS 1.3 draft matches what I
suggest for PSS signatures:

* Salt length is the length of the hash function.
* MGF1 hash function is the same as the message hash function.
* The trailer field has the default value.

(I like Brian's idea, but I hate options, so I'm torn here.)

Certificates that don't match that format are at risk of not working
in Google products because we hate excessive options. (We'll see,
practically speaking, much we have to bend on that point, as always)

Cheers

AGL

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 23 Jan 2017 09:05:28 +0100

On Fri, 2017-01-20 at 17:43 +0000, Dr Stephen Henson wrote:

> (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does
> the RSASSA-PSS mean that both types must be accepted?

That's a quite interesting finding. Although that protocol behavior
seems to ease transition to RSASSA-PSS, it also paves the field for new
cross protocol attacks. A server which can sign with either of RSASSA-
PSS and RSA-PKCS1 and the same key is certainly less secure than a
server which can sign with either of them. The only way to enforce that
a key is restricted is by requiring the id-RSASSA-PSS OID for RSASSA-
PSS.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 23 Jan 2017 12:52:41 +0200

> a key is restricted is by requiring the id-RSASSA-PSS OID for RSASSA-

Unfortunately, dedicated RSA-PSS keys are pretty much undeployable, and
requirement to use those would be de facto the same as removing RSA
server signatures entierely from TLS 1.3[1].

I don't know any CA that would certify RSA-PSS keys. And adding new key
types is a slow process. Heck, Certifying ECDSA keys are poorly
supported among CAs[2].

And looking at RSA-PKCS1 and RSA-PSS, it doesn't seem likely that there
exists a EM that is both valid in RSA-PKCS1 and RSA-PSS for any
messages, unless keysizes are too small, hashes are too large or salts
are too large.

E.g. with 2048-bit keys, and SHA-512 with 512-bit salts, there are
126 octets to match, but only 64 octets to control, making it very
unlikely that suitable control value can be found. With longer keys,
each octet in key adds an octet to match but leaves octets to control
unchanged.

[1] Not that this wouldn't have security benefits, thanks to insecure
stuff SSL and earlier TLS versions pull off...

[2] Some commercial CAs (don't have list) and Let's Encrypt (signed 
with RSA[3] and even then most ACME software can't handle those)..

[3] TLS 1.2 and 1.3 allows mixing and matching RSA and ECDSA in
chain.

-Ilari