Subject: [TLS] TLS RSA-PSS and various versions of TLS

From: Timothy Jackson <[email-masked]>
Date: Wed, 8 Feb 2017 19:34:16 +0000

I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS apply only to the signatures that can be used for signing handshakes or does it apply to the entire certificate chain as well? I ask because while I think the latter may have been the intent I have not found anything that indicates the former is not actually what the RFCs require.

The relevant section of RFC4056 reads:

7.4.2 Server Certificate
…
Note that there are certificates that use algorithms and/or algorithm
   combinations that cannot be currently used with TLS.  For example, a
   certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
   SubjectPublicKeyInfo) cannot be used because TLS defines no
   corresponding signature algorithm.

I don’t see anything here that restricts which signatures can be used on the certificates themselves. Is that accurate? If so, then I think the relevant restrictions are not in TLS RFCs at all, but rather are in RFCs such as 4055, 4056, and 5756. These RFCs allow RSASSA-PSS. Is it therefore permissible to have a CA that is signed with RSASSA-PSS with TLS 1.0, 1.1, or 1.2.

Is this what was intended?

Thanks,

Tim

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Feb 2017 22:20:46 +0200

> On 8 Feb 2017, at 21:34, Timothy Jackson <[email-masked]> wrote:
> 
> I don’t see anything here that restricts which signatures can be used on the certificates themselves. Is that accurate?

No.  A few paragraphs up:

   If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.

And it doesn’t help if the client does not provide the extension.  The extension can restrict from among the set of supported algorithms, Its absence does not allow undefined algorithms.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Feb 2017 08:05:42 +1100

On 9 February 2017 at 07:20, Yoav Nir <[email-masked]> wrote:
> And it doesn’t help if the client does not provide the extension.  The
> extension can restrict from among the set of supported algorithms, Its
> absence does not allow undefined algorithms.

Since TLS 1.3 defines code points for RSA-PSS, perhaps this is no
longer accurate - at least for PSS.

NSS supports PSS signatures in TLS 1.2.  It caused a small amount of
compatibility pain deploying them thanks to some infrequently used,
but overzealous implementations.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 8 Feb 2017 23:17:38 +0200

On Wed, Feb 08, 2017 at 07:34:16PM +0000, Timothy Jackson wrote:
> I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with
> RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS
> apply only to the signatures that can be used for signing handshakes or
> does it apply to the entire certificate chain as well? I ask because while
> I think the latter may have been the intent I have not found anything that
> indicates the former is not actually what the RFCs require.
> 
> I don’t see anything here that restricts which signatures can be used on
> the certificates themselves. Is that accurate? If so, then I think the
> relevant restrictions are not in TLS RFCs at all, but rather are in RFCs
> such as 4055, 4056, and 5756. These RFCs allow RSASSA-PSS. Is it
> therefore permissible to have a CA that is signed with RSASSA-PSS with
> TLS 1.0, 1.1, or 1.2.
> 

My interpretation:

If client includes RSA-PSS codepoints in its signature_algorithms,
then:

- The server handshake signature MAY be signed using RSA-PSS in TLS
  1.2 or later. Yes, 1.2, not 1.3.
- The certificate chain MAY contain certificates signed with RSA-PSS
  in any TLS version (however, the salt length must match hash length).

In converse case:

- The server MUST NOT sign handshake using RSA-PSS in any TLS
  version
- The certificate chain SHOULD NOT contain certificates signed with
  RSA-PSS in any TLS version.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Feb 2017 10:49:17 +1100

>   in any TLS version (however, the salt length must match hash length).

This is consistent with TLS 1.3 (and the discussion we had on the same
subject previously).

RSASSA-PSS algorithms: Indicates a signature algorithm using
RSASSA-PSS [RFC3447] with mask generation function 1. 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 also defined for
use with TLS 1.2.

---

From: Dr Stephen Henson <[email-masked]>
Date: Sat, 18 Feb 2017 02:31:19 +0000

>   RSA-PSS in any TLS version.

Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
certificates too?

For example could a TLS 1.2 server legally present a certificate containing an
RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
a certificate contain an RSASSA-PSS key?

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: Martin Thomson <[email-masked]>
Date: Sat, 18 Feb 2017 21:01:43 +1100

On 18 February 2017 at 13:31, Dr Stephen Henson
<[email-masked]> wrote:
> could a TLS 1.2 server legally present a certificate containing an

NSS, when configured to do so, will do just that.  I wouldn't
recommend it right now, but it is legal.  Actually, if you offer
support for validating PSS and end up negotiating 1.2, then you should
be prepared to receive PSS signatures.  It's a wee gotcha in the 1.3
spec.

---

From: Dr Stephen Henson <[email-masked]>
Date: Sat, 18 Feb 2017 13:01:36 +0000

> be prepared to receive PSS signatures.  It's a wee gotcha in the 1.3

The reason I wasn't sure about this is that for TLS 1.2 the server certificate
key algorithm is associated with a ciphersuite. So for example the "RSA" in
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 would previously refer to the OID
rsaEncryption (1 2 840 113549 1 1 1) if PSS is included in signature algorithms
it could also refer to id-RSASSA-PSS.

Similarly for client certificates there is the ClientCertificateType rsa_sign
though RFC5246 just says "a certificate containing an RSA key".

I'd be curious to know what other implementations do. I suggest we make this
possibility clear in the spec, along with the salt length in certificate
signatures previously discussed. Otherwise it isn't inconceivable that some will
reject id-RSASSA-PSS keys in end entity certificates in TLS 1.2.

Steve.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Feb 2017 16:26:04 +0000

> a certificate contain an RSASSA-PSS key?

Isn't an RSA public key independent of the signature algorithms it
might be employed with?  If the EE cert has an RSA key, and RSA-PSS
is not negotiated, can't the peer (client or server) just sign with
PKCS#1?  So the same EE cert would then be valid for either PSS or
PKCS#1?  Or have I missed the memo on how PSS works with EE certs?

As for the signatures in the X.509 chain itself, the "SHOULD NOT"
above just means that we have a non-PSS chain to offer, then we
offer that, but if PSS is all we have, then present that chain.

Fundamentally, X.509 verification lies outside of TLS, and it is
not the job of TLS to second-guess the X.509 stacks on either end.
The peers can provide hints about preferred/supported algorithms,
but in the case of X.509 these are not hard constraints.  The X.509
algorithm hints in TLS are about increasing the chances of
interoperability, and not excluding unadvertised codepoints.

-- 
	Viktor.

---

From: Dr Stephen Henson <[email-masked]>
Date: Sat, 18 Feb 2017 18:22:23 +0000

> PKCS#1?  Or have I missed the memo on how PSS works with EE certs?

The most commonly deployed certificates containing RSA keys use rsaEncryption (1
2 840 113549 1 1 1). For those the key can be used for PKCS#1 and PSS.

There is however a second OID id-RSASSA-PSS defined in RFC4055 et al. With that
OID the key can only be legally used for PSS (with possible additional
restrictions) and not PKCS#1. That algorithm OID in EE certs was unusable for
TLS before 1.3 as the signature was always PKCS#1. As a result very few such
certificates have been seen in the wild, but (as mentioned in other threads)
they MUST be supported in TLS 1.3 (rsa_pss_sha256 is a mandatory algorithm).

My question was whether this implied TLS 1.2 implementations (that include PSS
in the signature algorithms extension) must support them too.

Steve.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 18 Feb 2017 21:25:16 +0200

> in the signature algorithms extension) must support them too.

The behaviour of implementation I have been writing in regards to
RSA-PSS:

- Only the 3 TLS 1.3 variants of RSA-PSS are supported. Including in
  1.2 and certificates.
- When using RSA-PSS for SKE signature, the ciphersuite signature
  algorithm is set to RSA.
- Ciphersuite signature algorithm is ignored on receipt.
- RSA-PSS SKE signatures are recognized from hash=8, algoritm=4, 5 or
  6 in DigitallySigned algorithm. The hash is determined from the
  algorithm number.
- RSA-PSS certificate signatures are recognized by exact match to
  precomposed algorithmidentifier values.
- RsaEncryption keys can be used to validate RSA-PKCS#1 v1.5 and
  RSA-PSS signatures.
- RSA-PSS keys can be used to validate RSA-PSS only, not RSA-PKCS#1
  v1.5.
- Normally, any server RSA keys need to be RsaEncryption type, but
  it is possible to force RSA-PSS key by some tricks..
- If client indicated support for both RSA-PKCS#1 v1.5 and RSA-PSS
  and RSA key is selected, RSA-PSS is preferred.

Nearly all of this just falls from the TLS 1.3 support. The only
version-specific part is knowing to set RSA certificate algorithm if
RSA-PSS was chosen (and this is controlled by one bitmask)..

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Feb 2017 09:32:26 +1100

>   and RSA key is selected, RSA-PSS is preferred.

NSS does all of this too.  With the only difference being in server
configuration.  Server RSA keys are used for PKCS#1 and PSS if they
are of the rsaEncryption type, and RSA-PSS keys - as determined by the
OID in the certificate SPKI - are only used for PSS.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 20 Feb 2017 12:40:00 +0100

On Saturday, 18 February 2017 18:22:23 CET Dr Stephen Henson wrote:
> >> For example could a TLS 1.2 server legally present a certificate
> >> containing an RSASSA-PSS key for an appropriate ciphersuite? Similarly
> >> could a client present a certificate contain an RSASSA-PSS key?
> > 
> The most commonly deployed certificates containing RSA keys use
> rsaEncryption (1 2 840 113549 1 1 1). For those the key can be used for
> PKCS#1 and PSS.
> 
> There is however a second OID id-RSASSA-PSS defined in RFC4055 et al. With
> that OID the key can only be legally used for PSS (with possible additional
> restrictions) and not PKCS#1. That algorithm OID in EE certs was unusable
> for TLS before 1.3 as the signature was always PKCS#1. As a result very few
> such certificates have been seen in the wild, but (as mentioned in other
> threads) they MUST be supported in TLS 1.3 (rsa_pss_sha256 is a mandatory
> algorithm).

sorry for the slight off-topic: how can you create such certificates with 
openssl command line util?

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