Subject: [TLS] Closing on PSS. PR#1114

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Dec 2017 17:24:19 -0800

Hi folks,

I've put together a PR that attemps to address the PSS issue.

See:
https://github.com/tlswg/tls13-spec/pull/1114

Because there are platforms which don't have any support for PSS in
the cert validator, at all, it seems like we MUST be able to express
the following:

1. I accept PSS in CV, but nowhere in certificates, and the SPKI
   MUST be of type rsaEncryption (because this is what Chrome
   can do on some platforms).

Going forward, we want to be able to express:

2. I accept PSS in CV *and* everywhere in the certificate chain
   (otherwise PSS certificates are dead)

3. I accept EdDSA in CV but not for signing certificates
   (note that this is subtly different from the PSS case because
   you would need an EdDSA SPKI)

4. I accept EdDSA in CV and everywhere in the cert chain

Of these, #4 is mandatory, but #2 and #3 are pretty nice to have if
we want fast deployment. Otherwise, it's not possible to roll out
EdDSA (or other new algorithms) to browsers which don't have full
support in the validator, which, based on history, seems like a
pretty common situation.

Unfortunately, this seems to require two distinctions:

1. CV versus cert chain (for any incremental deployment)
2. PKCS#1 versus PSS (for the goofy PSS case).

So, I think in order to address this problem we need two constructs:

- A separate extension that refers only to the cert chain
- Two sets of RSA code points, one for PSS and one for PKCS#1.

For the first, we would introduce a new signature_algorithms_certs
which says: "this is what I support for the signature algorithms in
certificates" (and by extension SPKI) If this is present, you filter:

   (a) CV signatures/EE keys against signature_algorithms

   (b) the signatures on certificates (and keys of their signers)
   against signature_algorithms_cert

If it's absent, you filter everything against signature_algorithms as
in the current design.

For the second, we would have:

- rsa_pss_shaX_rsae       == "I support PSS signatures with rsaEncryption
SPKI"
                             [these would use the current rsa_pss_shaX code
points]
- rsa_pss_shaX_rsassa_pss == "I support PSS signatures with RSASSA-PSS SPKI"

To go back to our requirements, you would say #1 (PSS in CV only, with
rsaEncryption)
as:

  signature_algorithms = [rsa_pss_shaX_rsae]
  signature_algorithms_cert = [rsa_pkcs1_shaX]

You would say #2 (full PSS) as:

  signature_algorithms = [rsa_pss_shaX_rsae, rsa_pss_shaX_rsassa_pss]
  signature_algorithms_cert = [rsa_pkcs1_shaX, rsa_pss_shaX_rsae,
rsa_pss_shaX_rsassa-pss]

You would say #3 (EdDSA in CV only as)

  signature_algorithms = [ed25519]
  signature_algorithms_cert = [something else like ecdsa_secp256r1_sha256]

And finally, #4 (full EdDSA support)

  signature_algorithms = [ed25519]
  signature_algorithms_cert = [ed25519]

I recognize that this isn't totally ideal, but I think it covers all the
relevant
cases, and even some we don't need to cover, like you would support
RSASSA-PSS
SPKI in the EE cert:

  signature_algorithms = [rsa_pss_shaX_rsae, rsa_pss_shaX_rsassa_pss]
  signature_algorithms_cert = [rsa_pkcs1_shaX]

Comments?
-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Dec 2017 12:35:41 +1100

> - Two sets of RSA code points, one for PSS and one for PKCS#1.

To be clear, this is two sets of RSA-PSS code points, one for PSS SPKI
and one for PKCS#1 SPKI.

That's awful, but I agree that it is necessary.  I like the overlap
with signature_algorithms and signature_algorithms_cert, because it
makes the simple design possible without making the horrible
intermediate steps possible.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 05 Dec 2017 12:00:34 +0100

> 4. I accept EdDSA in CV and everywhere in the cert chain

I do not see why specific platform considerations should lead such a
major protocol change, at the cost of the platforms which can
accomodate the requirements. I believe that such major moves for
compatibility for specific platforms should be explicitly expressed in
the WG charter.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 11 Dec 2017 08:59:44 +0100

> > https://github.com/tlswg/tls13-spec/pull/1114

As I guess, we cannot mandate RSA-PSS private keys and certificates for
TLS1.3, I've followed up with a subsection on security considerations
for re-using the RSA and RSA-PSS private keys. That includes
recommendations to reduce the impact from cross-protocol attacks
affecting these keys.

https://github.com/tlswg/tls13-spec/pull/1123

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 11 Dec 2017 16:51:01 +0200

> https://github.com/tlswg/tls13-spec/pull/1123

Some comments:

- Shared keys between servers are fairly common. Some of those servers
  are very badly configured (e.g. Static RSA enabled).
- If another server does not share key, but has certificate valid for
  the name, that certificate can be used as well.

(These are the same considerations as for DROWN).

-Ilari