Subject: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

From: Peter Wu <[email-masked]>
Date: Fri, 8 Sep 2017 23:59:48 +0100

Hi!

While working on adding RSASSA-PSS support to Go's crypto/tls library
(TLS 1.2), I have noticed something that may cause interop problems
later.

The current draft says the following about Server Certificate Selection
(https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.2.2):

   -  The certificate MUST allow the key to be used for signing (i.e.,
      the digitalSignature bit MUST be set if the Key Usage extension is
      present) with a signature scheme indicated in the client's
      "signature_algorithms" extension.

In TLS 1.2, the cipher suite was responsible for selecting the hash
function and signature algorithm (e.g. for ServerKeyExchange) while
"signature_algorithms" directed what certificate signatures are
accepted.  But in TLS 1.3, this also influences what algorithms can be
used for signing handshake messages (CertificateVerify).

This results in possible interop problem: while implementations
advertise RSASSA-PSS support in "supported_algorithms" because they can
indeed sign/verify handshake messages with said algorithm, they might
not be able to accept certificates with a RSASSA-PSS signature (because
the PKI library does not implement it for example). And because PSS
certificates are non-existent now, it will only be discovered later.

Some implementations I have checked wrt RSASSA-PSS support:
 - Go crypto/tls (TLS 1.2) - no RSASSA-PSS yet.
 - tls-tris (TLS 1.3) - accepts PSS for CV, but not certificates.
 - BoringSSL - failed, "bssl server" rejects cert.
 - OpenSSL - failed, s_server rejects cert. Related:
   https://github.com/openssl/openssl/issues/2878
 - NSS - not checked, but I think it has the same problem as tls-tris.
   Related: https://bugzilla.mozilla.org/show_bug.cgi?id=158750

These implementations will require fixing, but at the moment it is just
broken. Is this the expected behavior/intention?

While RSASSA-PSS is quite well understood for handshake messages, its
restrictions for certificates are not explicit. Currently the draft
limits the salt length for handshake messages, but what about certs?
What is needed for a TLS implementation to claim support for RSASSA-PSS?

In particular, for certificates:

 - Limitations on salt length?
 - What AlgorithmIdentifier OID to use?
 - Whether to constrain other AlgorithmIdentifier Params? (MGF, hash
   algorithm, trailerField)?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 9 Sep 2017 14:37:31 +0300

>  - Limitations on salt length?

Salt must be the same length as hash output.

>  - What AlgorithmIdentifier OID to use?

The following are used:

1.2.840.113549.1.1.10		RSA-PSS
1.2.840.113549.1.1.8		MGF1
2.16.840.1.101.3.4.2.1		SHA-256 (NULL optional)
2.16.840.1.101.3.4.2.2		SHA-384 (NULL optional)
2.16.840.1.101.3.4.2.3		SHA-512 (NULL optional)
2.16.840.1.101.3.4.2.8		SHA3-256 (Parameters absent)
2.16.840.1.101.3.4.2.9		SHA3-384 (Parameters absent)
2.16.840.1.101.3.4.2.10		SHA3-512 (Parameters absent)

>    algorithm, trailerField)?

The other constraints:

- Only MGF1 is supported.
- The MGF hash must be the same as the data hash.
- TrailerField must be absent (indicating default).

Basically, that implementation supports exact matches (and variants
with SHA-2 substituted by SHA-3) of the TLS schemes.

-Ilari

---

From: Dr Stephen Henson <[email-masked]>
Date: Sun, 10 Sep 2017 15:38:32 +0100

>    algorithm, trailerField)?

Note that you have to check any PSS restrictions in the certificates themselves
too. For signatures on certificates this should be handled as part of the normal
chain validation process. For restrictions on the EE key this would add
additional complications on the digests the key can sign with in the handshake.

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/

---

From: Hubert Kario <[email-masked]>
Date: Mon, 11 Sep 2017 12:57:22 +0200

On Sunday, 10 September 2017 16:38:32 CEST Dr Stephen Henson wrote:
> Note that you have to check any PSS restrictions in the certificates
> themselves too. For signatures on certificates this should be handled as
> part of the normal chain validation process. For restrictions on the EE key
> this would add additional complications on the digests the key can sign
> with in the handshake.

That being said, the RFC specifying RSA-PSS recommends that EE certificates 
should not have limitations.

But yes, if you want to support all valid certificates, you need to check 
limitations of the EE certificate before you select signing algorithm.
But that is also the case if you are using HSM for signing and it doesn't 
support necessary algorithms (in extreme case, it may even require disabling 
TLS 1.3 support completely).
-- 
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: Eric Rescorla <[email-masked]>
Date: Mon, 11 Sep 2017 11:42:03 -0700

Ugh.

Generally, the idea with signature schemes is that they are supposed to
reflect both the capabilities of your TLS stack and the capabilities of
your PKI verifier [0]. So, yes, if you advertise this it is supposed to
work. So, ideally we would just say that it's as Ilari says in his followup.

It seems like there are really two choices:

1. Only advertise algorithm X if you support algorithm X in both places
2. Invent a new extension whose semantics are "if present, this tells you
what the PKI validator accepts, otherwise look at signature schemes"

I hate to be suggesting #2 at this stage in the process, but maybe it's
right anyway...

-Ekr

[0] I recognize that there are people who think that TLS shouldn't say
anything about the PKI verifier,
but I don't think that this is viable, for exactly the reason shown here:
it's possibly to have an algorithm which is widely supported in TLS stacks
but not in PKI verifiers.

On Fri, Sep 8, 2017 at 3:59 PM, Peter Wu <[email-masked]> wrote:

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

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 12 Sep 2017 00:39:02 +0000

This situation is likely to arise every time a new signature algorithm is
introduced. Suppose a TLS client library is updated to support Ed25519
certificates, but that the PKIX library only supports validating Ed25519
certificates signed by RSA or ECDSA, which signature schemes should the
client present? This is similar to the 2014 issue with ECDSA and Chrome on
XP (https://bugs.chromium.org/p/chromium/issues/detail?id=409901), in which
the PKIX library didn't support ECDSA, but the TLS stack did. As long as
TLS and PKIX libraries are decoupled, the dual meaning of the signature
scheme makes the addition of a new algorithm to one or the other a bit
messy.

For example: In the current situation, it is mandatory to support
rsa_pss_sha256, but how many of these clients support certificates signed
with PSS? Not many -- including OpenSSL (
https://github.com/openssl/openssl/issues/2878#issuecomment-328576616).
Without PSS certificate support, if we chose EKR's option 1, these clients
would not be able to support TLS 1.3 according to the spec. This seems like
an unnecessary dependency.

An easy fix would be to use a different extension for PSS certificates, but
this makes the naming and code point definitions more troublesome. Will all
new signature schemes get two codepoints, one for the handshake and one for
the certificate? The other option, EKR's option 2, seems more promising.

This option could be implemented as follows:
- keep the old hash and signature algorithm extension from TLS 1.2 to
indicate certificate signature support
- add a new extension for handshake signature scheme support

This would have the additional advantage of allowing us to clean up some of
the issues that have been raised before on this list around the numbering
of new TLS 1.3 signatureSchemes, specifically the fact that the byte order
is backwards for RSA-PSS relative to existing TLS 1.2 values.

Nick

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 12 Sep 2017 07:46:09 +0200

On Mon, 2017-09-11 at 11:42 -0700, Eric Rescorla wrote:
> Ugh.
> 
> Generally, the idea with signature schemes is that they are supposed
> to reflect both the capabilities of your TLS stack and the
> capabilities of your PKI verifier [0]. So, yes, if you advertise this
> it is supposed to work. So, ideally we would just say that it's as
> Ilari says in his followup.
> 
> 2. Invent a new extension whose semantics are "if present, this tells
> you what the PKI validator accepts, otherwise look at signature
> schemes"
> 
> I hate to be suggesting #2 at this stage in the process, but maybe
> it's right anyway...
> 
> -Ekr
> 
> [0] I recognize that there are people who think that TLS shouldn't
> say anything about the PKI verifier,
> but I don't think that this is viable, for exactly the reason shown
> here: it's possibly to have an algorithm which is widely supported in
> TLS stacks but not in PKI verifiers.

In practice, I find it perfectly reasonable for stacks which do not
support that algorithm in both PKI and TLS not to advertise it. The
option (1) brings simplicity to a rather complex protocol, while (2)
bloats the protocol for the benefit of helping not up-to-date stacks
claim TLS 1.3 compliance.

In theory, the only reason for having RSA-PSS is its security proof.
Mixing RSA (certificates) and RSA-PSS (handshake) in a protocol may
hardly bring any benefit; it looks like it will make a convoluted
protocol without particular goal or focus.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Sep 2017 10:49:17 +0300

> claim TLS 1.3 compliance.

Unfortunately, I have seen behavior like the following (this is
modified client and one of the test servers (the mod_nss @draft-20 one)
in the wiki):

[State ClientHello] Sending client_hello:
  ┌─────┬──────────────┨ Payload ┠──────────────┬────────────────┐
  │    0│0303 CBD9 FD89 B99E 292A E0F4 791D 0C29│........)*..y..)│
  │    1│07F2 0C62 7D94 6ED6 7C93 59EA BD6F 72F6│...b}.n.|.Y..or.│
  │    2│0CF9 0000 12CC A9C0 2BC0 2CCC A8C0 2FC0│........+.,.../.│
  │    3│3013 0313 0113 0201 0000 9900 2B00 0D0C│0...........+...│
  │    4│7F15 7F14 7F13 7F12 7F11 0303 000A 000C│................│
  │    5│000A 001D 0017 001E 0018 0019 0028 0026│.............(.&│
  │    6│0024 001D 0020 C02A 8D3E 32F4 ED55 9F6B│.$... .*.>2..U.k│
  │    7│9ADF 772C 1F8C 39FE D6D3 D03A 179A 14A1│..w,..9....:....│
  │    8│8180 F41A 8C58 0000 0018 0016 0000 1366│.....X.........f│
  │    9│7261 6E7A 6973 6B75 736B 6965 6665 722E│ranziskuskiefer.│
  │    A│6465 0005 0005 0100 0000 0000 1200 0000│de..............│
  │    B│0D00 1200 1008 0708 0804 0305 0306 0306│................│
  │    C│0105 0104 0100 1700 00FF 0100 0100 1053│...............S│
  │    D│0002 4000                              │..@.            │
  └─────┴─────────────┨ 212 bytes ┠─────────────┴────────────────┘
... snip ...
Chosen configuration: Version: TLS 1.3-draft20, Protection:Aes128Gcm, Hash: Sha256, Exchange group: X25519, Extended Master Secret: N/A
[State Tls13CertificateVerify] Received (borrowed) certificate_verify:
  ┌─────┬──────────────┨ Payload ┠──────────────┬────────────────┐
  │   00│0401 0100 2716 5FF4 5A0B 9F05 5B42 8609│....'._.Z...[B..│
...snip...
  │   10│BACC 04E5                              │....            │
  └─────┴─────────────┨ 260 bytes ┠─────────────┴────────────────┘
do_local_abort: #42:CertificateVerify contains bad signature

That is Client Hello that does not advertise RSA-PSS, but does
advertise RSA-PKCS#1.

The server responds with TLS 1.3 and signature scheme 0x0401, which
is RSA-PKCS#1 with SHA-256. And then client aborts because it does
not like that scheme.

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Sep 2017 13:02:19 +0200 (CEST)

> but not in PKI verifiers.

I believe you got it backwards.

A new TLS extension to convey acceptable signatures on certs would be
needed, and for this, it would be preferable to pass along ASN.1
OIDs from AlgIds (not full AlgIds, this would be too messy with RSA-PSS).  

The text in rfc5246 which suggests that contents of the "signature_algorithm"
extension should be applied to certificates is a defect of rfc5246, and
only a small fraction of implementors seems to have gotten this wrong,
and created implementations that erroneously abort by making flawed
assumptions on what the peer might support (or not).

The signature_algorithms extensions must only be applied to transforms
used within the TLS protocol itself (digitally_signed), because only this
transform can be negotiated and produced at will by communication peers.

Certificates will, in most real-world usage cases, be created out-of-band
by third party entities (CAs), and can typically not be created by the
TLS communication endpoints.  It is OK to use "signature_algorithms"
as a selection hint.  It is a dumb idea for a TLS communication peer
to abort a TLS handshake by making flawed assumptions about whether
a communication peer does or does not support a particular signature
scheme on certificates.

TLS handshake failures based on flawed assumptions are unconditionally BAD.
If the peer has a certain policy, it is up to that peer to apply this
policy during _verification_.  TLS handshake failures are unprotected,
they can not be recovered from at the TLS level (transparently), but require
app-level acrobatics, and may require repeated proxy traversals.  And
they create downgrade vulnerabilities, such as the silly "downgrade dance"
implemented by a number of browsers, which creates the POODLE vulnerability.

btw. some PKIs are currently switching to using RSA-PSS signatures
on certificate chains.  But they do use rsaEncryption for the key
in the endEntity certificate.  Because they want to use end-entity
certs for both, PKCS#7/CMS (and maybe SOAP) signatures as well as
SSL/TLS client certificates.  For use with TLSv1.2 as client certs,
they're hardwired to RSA PKCS#1 v1.5 signatures, which precludes tagging
the keys in client end-entity certs as RSA-PSS.

TLSv1.3 needs to avoid more "MUST" mistakes around algorithms that
work just fine with earlier version of TLS.  It is perfectly OK to
created RSA-PSS signatures with keys that are tagged as rsaEncryption,
and adding words or semantics to TLSv1.3 that suggests this is not
OK, would be terribly bad.

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Sep 2017 15:25:06 +0300

> OIDs from AlgIds (not full AlgIds, this would be too messy with RSA-PSS).  

With RSA-PSS, there is also the parametrization signature by hashes.

The implementation I have supports the following six sets of parameters
for RSA-PSS:

- hash=SHA-256, mgf=MGF1[SHA-256], salt=256, trailer=1
- hash=SHA-384, mgf=MGF1[SHA-384], salt=384, trailer=1
- hash=SHA-512, mgf=MGF1[SHA-512], salt=512, trailer=1
- hash=SHA3-256, mgf=MGF1[SHA3-256], salt=256, trailer=1
- hash=SHA3-384, mgf=MGF1[SHA3-384], salt=384, trailer=1
- hash=SHA3-512, mgf=MGF1[SHA3-512], salt=512, trailer=1

The first three are the TLS 1.3 RSA-PSS schemes. The last three are the
same, except with SHA-2 hash replaced by correspoding SHA-3 hash.

(I mostly implemented those SHA-3 algorithms as to test of the
architecture.)

> assumptions on what the peer might support (or not).

This is mostly not about peers aborting on bad assumptions. It is peers
making bad assumptions and then sending something that the peer does not
support.

The TLS server I wrote does abort on some certificates (e.g., all
signature algorithms must be recognized). However, all checks except
ones on exchange signatures are independent of the capabilities
advertised by peer.

The TLS 1.3 has SHOULD on that signature algorithm selection. I wrote
my implementation to outright immediately abort, since I do not see
that there is any way things can work if that SHOULD is broken.

The default (can be overridden) certificate selection code prefers
certificates signed by algorithms appearing in signature_algorithms,
but if no suitable certificate is found, expands the search to all
algorithms. Unlike in previous point, there is a chance things will
work even if unadvertised algorithm is chosen (e.g.,
ECDSA-P256-SHA3-256 certificate being sent to the corresponding
client implementation... Those are in fact supported).

> transform can be negotiated and produced at will by communication peers.

There are restrictions from end-entity certificates the server has.
E.g. 0x804 and 0x403 require different end-entity certificates.

> a communication peer does or does not support a particular signature

Yes, most of the time, the server only has one or two certificate
chains available.

> implemented by a number of browsers, which creates the POODLE vulnerability.

As far as I understand this issue, this is not _server_ aborting
because it can't select a chain, it is _client_ aborting because it can
not deal with what the server sent (because the server had no idea that
the client could not deal with what it sent).

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Tue, 12 Sep 2017 15:16:45 +0200

> https://github.com/openssl/openssl/issues/2878#issuecomment-328576616).

Actually OpenSSL does support certificates signed with RSA-PSS, it doesn't 
support RSA-PSS keys in certificates.

> an unnecessary dependency.

With RSA-PSS the situation is even more complex, as you have it in two places, 
in the signature and in the public key id.

So the possibilities are as follows:
 - CA key: rsa; EE signature: rsa; EE key: rsa
   - that certificate can be used with any version of TLS and can make both 
     rsa-pss and rsa signatures
 - CA key: rsa; EE signature: rsa; EE key: rsa-pss
   - that certificate can be used only with TLS 1.3 or TLS 1.2 that was 
     updated to support TLS 1.3 signatures, does not require support for
     RSA-PSS in PKIX (with the assumption that the library allows the TLS
     library to extract the RSA-PSS parameters from the certificate)
 - CA key: rsa; EE signature: rsa-pss; EE key: rsa
   - that certificate can be used again only with TLS 1.3 or TLS 1.2 but
     that's because RFC compliant peer can send only certificates that have
     signatures listed in SignatureAlgorithms. Can sign using both rsa and
     rsa-pss but it DOES require RSA-PSS support in PKIX
 - CA Key; rsa; EE signature: rsa-pss; EE key: rsa-pss
   - similarly to the above, but does limit the usage of certificate to 
     TLS 1.2 with rsa-pss or TLS 1.3, cannot be used to make RSA-PKCS#1 v1.5 
     signatures in TLS 1.2
 - CA Key: rsa-pss; EE signature: rsa-pss; EE key: rsa
   - exactly as with CA key: rsa; EE signature: rsa-pss; EE key: rsa
 - CA Key; rsa-pss; EE signature: rsa-pss; EE key: rsa-pss
   - similarly to the above, but cannot be used to make RSA-PKCS#1 v1.5 
     signatures in TLS 1.2, thus requires RSA-PSS support in TLS 1.2 from
     the TLS part of the library

Now, if a client sends only rsa_pss_sha256, I'd say, that all of the following 
need to work:
 - CA key: rsa; EE signature: rsa-pss; EE key: rsa
 - CA Key; rsa; EE signature: rsa-pss; EE key: rsa-pss
 - CA Key: rsa-pss; EE signature: rsa-pss; EE key: rsa
 - CA Key; rsa-pss; EE signature: rsa-pss; EE key: rsa-pss

If both rsa_pss_sha256 and rsa_pkcs1_sha256 are sent, then all 6 combinations 
should be supported by client.

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Sep 2017 15:21:29 +0200 (CEST)

> - hash=SHA3-512, mgf=MGF1[SHA3-512], salt=512, trailer=1

The salt length is supposed to be in bytes, not bits, and for SHA-1
defaults to 20.  The salt length suggested in the standard is the
output size of the underlying hash length in bytes.

But it seems that some existing implementations use weird/unusual salt
values for RSA-PSS signature with hash algs other than SHA-1.

-Martin

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 12 Sep 2017 14:41:16 +0100

On 11/09/2017 19:42, Eric Rescorla wrote:
> Ugh.
> 
> Generally, the idea with signature schemes is that they are supposed to reflect
> both the capabilities of your TLS stack and the capabilities of your PKI
> verifier [0]. So, yes, if you advertise this it is supposed to work. So, ideally
> we would just say that it's as Ilari says in his followup.
> 
> 2. Invent a new extension whose semantics are "if present, this tells you what
> the PKI validator accepts, otherwise look at signature schemes"
> 
> I hate to be suggesting #2 at this stage in the process, but maybe it's right
> anyway...
> 

It's rather more than just certificate signatures.

The problem here is that there is no way to indicate an implementation supports
rsaEncryption keys but not RSASSA-PSS keys and the current draft requires that
implementations support both AFAICS.

RSASSA-PSS keys are pretty rare at the moment. There are some complications
involved with supporting them not present with other key types: more complex
parameter sets and key restrictions for example. Implementors might feel
(despite what the draft says) that the added complexity is not justified because
no one will ever want to use RSASSA-PSS keys.

At the same time if important implementations abort the handshake when they see
an RSASSA-PSS key then this is a strong reason for a server to not deploy
RSASSA-PSS keys: it will cause interoperability issues.

Steve.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 12 Sep 2017 16:10:44 +0200

On Tue, 2017-09-12 at 14:41 +0100, Dr Stephen Henson wrote:
> > it's right
> involved with supporting them not present with other key types: more
> complex parameter sets and key restrictions for example.

Right, that is indeed a significant complexity, and unfortunately the
RSASSA-PSS parameters in certificates/keys are quite uniquely in PKIX.
However, these are optional parameters, and one could support RSA-PSS
keys without such parameters/restrictions relatively easily. Moreover,
keys without paramters, are the keys which are typically expected to be
used by TLS. 

That is, because a TLS server would typically sign with whatever
algorithm the client supports and would very rarely be interested to
utilize the security advantages of including the parameters (which,
advantages, are quite unclear even to a crypto expert). Otherwise, a
certificate restricted to SHA-384 and 48-bytes of salt, will not be
able to serve a client which only supports RSASSA-PSS with SHA-256.

As such, it would make sense for TLS 1.3 to recommend no parameters for
such RSASSA-PSS certificates, to ease their deployment.

>  Implementors might feel
> (despite what the draft says) that the added complexity is not
> justified because no one will ever want to use RSASSA-PSS keys.

If an implementation does not support RSASSA-PSS-only keys, it means it
will (as a server) not be able to use separate keys for RSASSA-PSS and
RSA PKCS#1 v1.5 operations, right? That's quite a fundamental
limitation and if it exists in popular implementations it makes the TLS
1.3 move to RSASSA-PSS quite questionable. It may be better to support
RSA PKCS#1 v1.5 in TLS1.3 alongside RSASSA-PSS (for the implementations
that chose to opt-in), rather than forcing a move to RSASSA-PSS without
providing any of the benefits of using it. 

regards,
Nikos

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 12 Sep 2017 16:42:31 +0100

> such RSASSA-PSS certificates, to ease their deployment.

Well restrictions in CA keys would be handled by the PKI verifier: if there is a
violation the chain should be rejected and it's a problem with the chain itself
and an error by the CA that issued it. A different case is where the
restrictions are legal from a PKIX standpoint but not allowed by TLS 1.3, though
again it's a CA error issuing such a chain for TLS 1.3 use.

A restriction on the EE key isn't quite the same. There are two cases.

One is that the parameters are not permitted by TLS 1.3 at all (e.g. MGF1 digest
doesn't match signing digest or minimum salt length exceeds digest length). In
this case a server should never present the chain or if it does a client would
justifiably reject it and abort the handshake. Again this is an error by the
issuing authority which should be corrected.

The second case is that the parameter restriction is permitted by TLS 1.3 and
this limits the digest which the key can sign with. Say the restriction is
SHA384 and the client only supports rsa_pss_sha256. The server might then use to
a different PSS key (and certificate chain) that supports rsa_pss_sha256 or fall
back to an RSA key to use rsa_pss_sha256. Again if a client sees a TLS message
signed with parameters that violate the restrictions it could (with some
justification) abort the handshake.

This could get pretty messy: it requires a logic not used in any other
algorithm. I'd be more than happy to have an outright prohibition on EE PSS key
parameter restrictions in TLS 1.3 so implementers don't have to bother with this.

Steve.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Sep 2017 09:02:27 -0700

> parameter restrictions in TLS 1.3 so implementers don't have to bother

This sounds plausible to me. Would you be willing to send a PR?

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Tue, 12 Sep 2017 19:30:30 +0200

On Tuesday, 12 September 2017 17:42:31 CEST Dr Stephen Henson wrote:
> Well restrictions in CA keys would be handled by the PKI verifier: if there
> is a violation the chain should be rejected and it's a problem with the
> chain itself and an error by the CA that issued it. A different case is
> where the restrictions are legal from a PKIX standpoint but not allowed by
> TLS 1.3, though again it's a CA error issuing such a chain for TLS 1.3 use.
> 
> One is that the parameters are not permitted by TLS 1.3 at all (e.g. MGF1
> digest doesn't match signing digest or minimum salt length exceeds digest
> length). In this case a server should never present the chain or if it does
> a client would justifiably reject it and abort the handshake. Again this is
> an error by the issuing authority which should be corrected.
> 
> The second case is that the parameter restriction is permitted by TLS 1.3
> and this limits the digest which the key can sign with. Say the restriction
> is SHA384 and the client only supports rsa_pss_sha256. The server might
> then use to a different PSS key (and certificate chain) that supports
> rsa_pss_sha256 or fall back to an RSA key to use rsa_pss_sha256. Again if a
> client sees a TLS message signed with parameters that violate the
> restrictions it could (with some justification) abort the handshake.
> 
> algorithm. I'd be more than happy to have an outright prohibition on EE PSS
> key parameter restrictions in TLS 1.3 so implementers don't have to bother
> with this.

what about hardware tokens that support only specific hashes or signatures?
(I've seen ones that can do only RSA with SHA256 and SHA-1, but not SHA-384 or 
SHA-512) Isn't it basically the same code path (though the limitation does 
come from slightly different place).
-- 
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: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 12 Sep 2017 17:36:04 +0000

> . . . 

I think that the requirement of having the same hash everywhere in this certificate takes care of this problem. 

If I’m missing the actual problem you’re pointing at – please outline the use case where it might manifest, and let’s take it from there.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 12 Sep 2017 20:06:55 +0200

On Tuesday, 12 September 2017 19:36:04 CEST Blumenthal, Uri - 0553 - MITLL 
wrote:
> > what about hardware tokens that support only specific hashes or
> > signatures? (I've seen ones that can do only RSA with SHA256 and SHA-1,
> > but
> > not SHA-384 or SHA-512) Isn't it basically the same code path (though the
> > limitation does come from slightly different place).
> 
> If I’m missing the actual problem you’re pointing at – please outline the
> use case where it might manifest, and let’s take it from there.

What Stephen is pointing at, is a server certificate (End Entity certificate) 
when using RSA-PSS public key id in the X.509 certificate can have RSA-PSS 
parameters in the public key id or can have them omitted. When the parameters 
are omitted, it means that that key can be used for signing with any hash 
(SHA-1, SHA-256, SHA-384, SHA3-256, etc.) but must be used with rsa-pss 
padding scheme. When the parameters are present the hash is set in stone and 
that key can then be used to sign with one hash and one hash only - the hash 
that is specified in certificate (and rsa-pss padding).

Now, if the certificate specifies in parameters SHA384 hash and client 
advertises support only for SHA256 with RSA-PSS, the server should switch to 
(e.g.) ECDSA certificate that does not have that limitation and continue 
connection instead of aborting the connection (very bad) or sending 
certificate which most likely will be rejected by client as not 
understandable/unverifiable (bad).

What I've added is that that limitation may not come from the certificate but 
may come from the cryptographic module (software or hardware) that implements 
rsa-pss with just one or two hashes, irrespective of rsa-pss parameters in the 
certificate public key id.

So, I'm not sure what hash you are suggesting should be "the same everywhere".
I'm quite sure you're not suggesting that we should limit TLS 1.3 to SHA256 
only (no SHA384 or SHA512), are you?
-- 
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: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 12 Sep 2017 18:33:21 +0000

What Stephen is pointing at, is a server certificate (End Entity certificate) 
    when using RSA-PSS public key id in the X.509 certificate can have RSA-PSS 
    parameters in the public key id or can have them omitted.

Yes. And I concur with him that it is better to omit them, enforcing the default. The default being:
- Hash algorithm the same as specified in Signature Algorithm
- MGF1 hash is the same as above
- Salt length same as digest length above

    When the parameters 
    padding scheme.

Not quite. Since this key is a part of the given certificate – RSA-PSS padding scheme should be used with the same hash as “Signature Algorithm” specifies.

    When the parameters are present the hash is set in stone and 
    that key can then be used to sign with one hash and one hash only - the hash 
    that is specified in certificate (and rsa-pss padding).

I think the point Stephen was making is that Signature Algorithm specifies a hash – and there’s no reason to use a different one for MGF1.

This is a different question. The point being addressed here is that each certificate is internally consistent, using the same hash for all the purposes within that certificate.

If the server’s certificate is signed with SHA384, so be it. There’s no reason for a client to not support SHA384 *for signature verification*, as hardware token restrictions shouldn’t apply here – it’s software-based validation.

The cryptographic module would perform RSA-PSS *signature* with whatever hashes it can. It won’t bother with *validation*, so this module’s limitations shouldn’t matter.

Within one certificate – one hash. I.e., *no* SHA512 in Signature Algorithm, SHA384 for message hash in SHA384-RSA-PKCS-PSS, SHA256 for MGF1.

Oh no – I’m eccentric but not quite insane yet. ;-)

---

From: Hubert Kario <[email-masked]>
Date: Wed, 13 Sep 2017 12:55:42 +0200

On Tuesday, 12 September 2017 20:33:21 CEST Blumenthal, Uri - 0553 - MITLL 
wrote:
> >     What Stephen is pointing at, is a server certificate (End Entity
> > 
> > certificate) when using RSA-PSS public key id in the X.509 certificate can
> > have RSA-PSS parameters in the public key id or can have them omitted.
> 
> Yes. And I concur with him that it is better to omit them, 

and I'm saying that such limitation on EE certificate won't help much if you 
also support hardware tokens as they can limit supported signature schemes too

> enforcing the
> default. The default being: 

No problem with that being recommendation, but I've seen people claiming that 
some applications don't follow that salt length requirement, so I'd say it 
would cause unnecessary problems if it was set too strict
 
> >     that key can then be used to sign with one hash and one hash only -
> >     the
> > 
> > hash that is specified in certificate (and rsa-pss padding).
> 
> I think the point Stephen was making is that Signature Algorithm specifies a
> hash – and there’s no reason to use a different one for MGF1.

this is not a problem we're talking about, I don't have any kind of problem 
with MGF1 requirement to be the same as the signature hash

> >     advertises support only for SHA256 with RSA-PSS, the server should
> > 
> > switch to (e.g.) ECDSA certificate that does not have that limitation and
> > continue connection instead of aborting the connection (very bad) or
> > sending certificate which most likely will be rejected by client as not
> This is a different question. The point being addressed here is that each
> certificate is internally consistent, using the same hash for all the
> purposes within that certificate.

and what you're talking about is a non-issue. Binding MGF1 hash with signature 
hash is sensible and unlikely to cause problems.
 
> If the server’s certificate is signed with SHA384, so be it. There’s no
> reason for a client to not support SHA384 *for signature verification*, as
> hardware token restrictions shouldn’t apply here – it’s software-based
> validation.

I'm talking about subjectPublicKeyInfo field, *not* about signatureAlgorithm 
field from RFC 3280

and there are clients that advertise only a subset of hashes:
https://www.ssllabs.com/ssltest/viewClient.html?
name=Safari&version=6&platform=iOS%206.0.1&key=33
 
> >     What I've added is that that limitation may not come from the
> > 
> > certificate but may come from the cryptographic module (software or
> > hardware) that implements rsa-pss with just one or two hashes,
> > irrespective
> > of rsa-pss parameters in the certificate public key id.
> 
> The cryptographic module would perform RSA-PSS *signature* with whatever
> hashes it can. It won’t bother with *validation*, so this module’s
> limitations shouldn’t matter.

but it can't perform that signature using hash 
*that the client didn't advertise*

> Within one certificate – one hash. I.e., *no* SHA512 in Signature Algorithm,
> SHA384 for message hash in SHA384-RSA-PKCS-PSS, SHA256 for MGF1.

There are four places in which different hashes can be in a certificate:
 subjectPublicKeyInfo.algorithm.parameters.hashAlgorithm
 subjectPublicKeyInfo.algorithm.parameters.maskGenAlgorithm
 signatureAlgorithm.algorithm.parameters.hashAlgorithm
 signatureAlgorithm.algorithm.parameters.maskGenAlgorithm

Now, because the subjectPublicKeyInfo is chosen by the person generating the 
key (user) and signatureAlgorithm is chosen by the CA, and it is quite common 
already that e.g. a P-384 CA signs with SHA384 a P-256 intermediate CA that 
then signs EE with a SHA-256. I really don't think that *all* hashes should be 
the same.

How exactly using more secure parameters for longer lived keys is a bad idea?

> >     I'm quite sure you're not suggesting that we should limit TLS 1.3 to
> > SHA256 only (no SHA384 or SHA512), are you?
> 

well, we do work on ASN.1 stuff... ;)
-- 
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: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 13 Sep 2017 14:35:25 +0000

> enforcing the default. The default being: 

I’m sure some apps follow, and some don’t. I’m simply saying that it makes sense for TLS to pick a sensible default (like the above) and stick with it. Other apps may do what they think is best.
     
As for above, in view of the following discussion I think it would be better to replace “Signature Algorithm” above with “subjectPublicKeyInfo.algorithm.parameters.hashAlgorithm”.
I still think that only the necessary minimum of parameters should be passed explicitly.

OK, point taken. Thanks for clarifying.

Seriously? iOS 6? Why not iOS 5 or 4? I think I still have an iOS 5 device somewhere. ;-)

    
You’re probably right. But for my benefit, could you please outline the scenario how this would/could be used? To make sure I completely understand the use case?

OK, you convinced me here. I missed that. :-(

And I start developing liking of ASN.1. Does it mean it’s time to get my head examined? ;-)

---

From: Hubert Kario <[email-masked]>
Date: Wed, 13 Sep 2017 17:57:17 +0200

On Wednesday, 13 September 2017 16:35:25 CEST Blumenthal, Uri - 0553 - MITLL 
wrote:
> >     No problem with that being recommendation, but I've seen people
> >     claiming
> > 
> > that some applications don't follow that salt length requirement, so I'd
> > say it would cause unnecessary problems if it was set too strict
> 
> I’m sure some apps follow, and some don’t. I’m simply saying that it makes
> sense for TLS to pick a sensible default (like the above) and stick with
> it. Other apps may do what they think is best.

hmm, thing is, that while certificates with subjectPublicKeyInfo of rsa-pss 
are still pink unicorns in production deployments, certificates with 
signatureAlgorithm of rsa-pss are fairly common in Microsoft shops - it is the 
default signature method for MS AD for good few years now.

I do not know what hashes, how consistent with MGF1 and what salts sizes do MS 
CAs select for those signatures.

I'm quite sure that people will want to use those existing CA certificates and 
intermediate CA certificates on new servers that will be deploying TLS 1.3...

> As for above, in view of the following discussion I think it would be better
> to replace “Signature Algorithm” above with
> “subjectPublicKeyInfo.algorithm.parameters.hashAlgorithm”. I still think
> that only the necessary minimum of parameters should be passed explicitly.

And I would agree, if we didn't have PKCS#11 tokens. If you work on pure-
software implementation it will be much easier to have EE that cannot have 
limitations specified in subjectPublicKeyInfo. But as soon as you have to work 
with any kind of hardware implementations of RSA, that assumption goes out the 
window. Because even if your HSM does do all combinations, different one may 
not.

> Seriously? iOS 6? Why not iOS 5 or 4? I think I still have an iOS 5 device

my point is that if a client from a major technological company, largely 
focused on security, can make such decisions, I don't see why other developers 
couldn't follow the same logic that makes them do what Apple did.

> You’re probably right. But for my benefit, could you please outline the
> scenario how this would/could be used? To make sure I completely understand
> the use case?

The use case may be of a limited client that implements only one hash 
algorithm and because it's low power, doesn't have a software fallback - 
allowing SHA256 only, everywhere (both on TLS level and on certificate 
signature level).

That client can then, exactly as the standard prescribes, advertise support 
only for signature schemes that support sha256: 
 * rsa_pkcs1_sha256
 * rsa_pss_sha256
 * ecdsa_secp256r1_sha256

Server side can be limited by policy, to have just sha384 signing in rsa with 
big key sizes (e.g. because some part of the web site is considered 'Top 
secret' and need to use keys more resistant to quantum computers) but also 
have P-256 ECDSA certificate for the public part of the web site as a 
fallback.

That server policy can be encoded in the subjectPublicKeyInfo.

In such situation we want the server to sign Certificate Verify with the ECDSA 
key - ecdsa_secp256r1_sha256 - even if the client advertises preference for 
RSA and server wants to respect it.

Situation with two RSA keys with different limitations is not much different.
We still want to pick a certificate that can be used to make a signature that 
client claims it will be able to verify - rsa_pss_sha256.