Subject: [TLS] PR to clarify RSASSA-PSS requirements

From: Peter Wu <[email-masked]>
Date: Wed, 22 Nov 2017 03:54:04 +0000

Hi,

At the moment there is still ambiguity in the requirements for PSS with
relation to certificates. Proposal to clarify this:
https://github.com/tlswg/tls13-spec/pull/1098

This PR intends to clarify the requirements for PSS support.

The requirements are intentionally minimal to reduce implementation
efforts, but recognizes that some other implementations may be more
complete. Notes:

- "Supporting PSS signatures on certificates is a mandatory requirement
  and I think we should be very clear about the parameters we permit."
  https://www.ietf.org/mail-archive/web/tls/current/msg23007.html
- Martin Rex wishes to remove TLS requirements on signature algorithms
  for certificates, hence the "MAY" for other PSS parameters in this PR.
  https://www.ietf.org/mail-archive/web/tls/current/msg23021.html
- Regardless, rsa_pss_sha256 is currently MTI for CertificateVerify and
  certificates, hence the strong MUST wording in this PR.
- It does not say anything about non-end-entity certificates, that's up
  to the PKI verifier. Consider case "CA Key: rsa-pss; EE signature:
  rsa-pss; EE key: rsa" from
  https://www.ietf.org/mail-archive/web/tls/current/msg24453.html
- PSS params in certificates are explicitly not restricted, satisfying
  https://www.ietf.org/mail-archive/web/tls/current/msg24457.html

>From what I have heard, boringssl does not (or will not?) implement any
PSS support in the certificates (yet?). Don't know if anything should be
changed here to reflect that decision, but I thought it is worth
mentioning. It is possible that I'll follow boringssl's example in tris.

If a TLS extension is introduced later, hopefully that improves interop
with odd keys and signatures that are optional in this PR (PSS pubkey or
custom salt lengths).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Nov 2017 20:37:45 -0800

I don't think that this is the right answer.

Let's separate out the question of (a) what people need to support and (b)
what the code points mean. (b) needs to be unambigous, as that's the point
of the extension and this PR actually makes it explicitly unambigous.

With that said, there seem to be two points of contention:

- Whether the code point refers to signatures other than those in
CertificateVerify
- Whether the code point refers to SPKIs with OIDs other than rsaEncryption

For the first point, I recognize that there are those who believe that the
code point should refer only to CertificateVerify but that's not what it
meant in TLS 1.2 and I don't think there's consensus to make that change.
We could certainly introduce a new extension later which refers to just
chain certificates.

For the second point, I wouldn't be averse to having two code points, one
for PSS that means "must be rsaEncryption" and one for "PSS with funny
parameters" (with the hope we only ever needed the first). But that's not
this PR.

-Ekr

On Tue, Nov 21, 2017 at 7:54 PM, Peter Wu <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 22 Nov 2017 09:42:04 +0100

> This PR intends to clarify the requirements for PSS support.

Hi,
 I commented on the PR, but to provide more context. I believe RSA-PSS
keys without parameters MUST be supported under TLS1.3. The reason is
that keys explicitly marked as RSA-PSS cannot be used for RSA PKCS#1
1.5 encryption, and thus they provide a way for the server to know that
it must protect that key against (cross-protocol) attacks which utilize
RSA ciphersuites under TLS1.2.

On why you don't want mixing keys for TLS1.3 and TLS1.2 RSA
ciphersuites, see all the bleichenbacher attack reiterations over the
years.

So what about distinguishing the RSA-PSS keys with and without
parameters:

"an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters MUST
be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS) with
parameters MAY be supported`."

regards,
Nikos

---

From: Peter Wu <[email-masked]>
Date: Wed, 22 Nov 2017 12:10:44 +0000

> meant in TLS 1.2 and I don't think there's consensus to make that change.

Yes, it is my understanding (now) that the code point covers both CV
(and SKE in TLS 1.2) and certificate signatures based on RFC 5246.

> parameters" (with the hope we only ever needed the first). But that's not

Limiting it to rsaEncryption sounds good to me, it removes some
complication. Since it is not clear to me which parameters MUST be
supported now, rather than defining three codepoints for PSS keys now,
what about deferring it to a future spec (possibly in combination with
the new extension for negotiating supported certificates)?

Alternatively something arbitrary can be done such as requiring the
parameters as used for TLS handshakes to be supported (as the PR
proposes) and allowing alternative configurations to be supported too.

Kind regards,
Peter

---

From: Peter Wu <[email-masked]>
Date: Wed, 22 Nov 2017 12:15:58 +0000

Hi Nikos,

> parameters MAY be supported`."

In my understanding, the parameters are REQUIRED (cannot be NULL), but
an "empty" DER encoding means that the default parameters are used
(SHA-1, MFG1 with SHA-1, salt length equal to SHA-1 output (20), default
trailer) per https://tools.ietf.org/html/rfc8017#page-75

Is this restriction what you intended?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 22 Nov 2017 14:33:29 +0100

On Wed, 2017-11-22 at 12:15 +0000, Peter Wu wrote:
> > > At the moment there is still ambiguity in the requirements for
> > > PSS
> > > with

That's not what the DEFAULT keyword means in ASN.1. My understanding is
that the default value applies when there is a sequence without that
value present, not when the sequence is not there at all.

Nevertheless, irrespective of that interpreation, for TLS1.3 an empty
DER encoding means nothing of that as these parameters are negotiated
over TLS (e.g, rsa_pss_sha256). See:
https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.2.3

On whether empty parameters are allowed on RSA-PSS certificates,
RFC4055 is clear on that:
"CAs MAY require that the parameters be present in the
publicKeyAlgorithms field for end-entity certificates."

https://tools.ietf.org/html/rfc4055#section-3

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Wed, 22 Nov 2017 14:45:17 +0100

> trailer) per https://tools.ietf.org/html/rfc8017#page-75

No, when the parameters are completely omitted (the 
AlgorithmIdentifier.parameters is completely omitted in the SEQUENCE of 
AlgorithmIdentifier), that means that the key is unrestricted and can be used 
with arbitrary hashes and salt lengths (just like a rsaEncryption key).
If the AlgorithmIdentifier.parameters is present but empty (empty SEQUENCE in 
DER), that means that all parameters are restricted and have default 
parameters (sha1, 20 byte salt).

RFC 5756 is a bit more explicit on requirements for EE and CA certificates:
   When the id-RSASSA-PSS object identifier appears in the
   TBSCertificate subjectPublicKeyInfo algorithm field of CA
   certificates, then the parameters field SHOULD include the RSASSA-
   PSS-params structure.  When the id-RSASSA-PSS object identifier
   appears in the TBSCertificate subjectPublicKeyInfo algorithm field of
   EE certificates, then the parameters field MAY include the RSASSA-
   PSS-params structure.

The unrestricted EE keys should be supported, and I would even go as far as 
specifying that in TLS1.3 RSA-PSS EE certs MUST be unrestricted.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Nov 2017 21:30:40 +0200

> RSA ciphersuites under TLS1.2.

Furthermore, this would also let the client know that the key itself is
not likely to be subject to DROWN-type issues.

This becomes extremely significant when considering things like
Delegated Credentials (WG document now). E.g., I consider it
unacceptable risk to accept DCs signed with RsaEncryption keys.
_Even_ if the certificate has an additional extension.

> ciphersuites, see all the bleichenbacher attack reiterations over the

There was a rather nasty one just very recently.

> parameters MAY be supported`."

+1

-Ilari

---

From: Peter Wu <[email-masked]>
Date: Wed, 29 Nov 2017 00:06:37 +0000

Hi Eric and list,

I have updated the PR https://github.com/tlswg/tls13-spec/pull/1098 last
week based on received feedback. Two issues are however still open:

 - Should a different codepoint be used for SPKIs other than
   rsaEncryption (i.e. id-RSASSA-PSS)? If so, what codepoints?

 - Should certificates with SPKI id-RSASSA-PSS be required to have no
   parameters (i.e. not restrict the hash algorithm chosen in TLS)?

Ideally it would already be sorted out before draft 22 is released. If
nothing is changed, then the specification remains ambiguous and
interoperability issues may occur.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl