Subject: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

From: Andrey Jivsov <[email-masked]>
Date: Tue, 29 May 2018 11:57:39 -0700

Greetings.

TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client
wants to negotiate TLS 1.3, it must support an upgraded (and
incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow
RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.

You might recall that the possibility to negotiate between PSS and
RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509
signatures, was discussed on the mailing list. The WG decision then was
to hard-wire PSS in the TLS 1.3 handshake.

I don't recall any discussion on going further than this, all the way to
changing the 10-year old TLS 1.2.

Unfortunately, our products have issues with PSS beyond our control. The
only solution left to avoid receiving PSS with TLS 1.2 is to never
negotiate TLS 1.3 as a client. Another solution is insecure fallback,
but we presently don't do this.

Is my reading of the situation correct? Thank you.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 May 2018 14:13:19 -0500

> Is my reading of the situation correct? Thank you.

Sounds like it:

   RSASSA-PKCS1-v1_5 algorithms  Indicates a signature algorithm using
      RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm
      as defined in [SHS].  These values refer solely to signatures
      which appear in certificates (see Section 4.4.2.2) and are not
      defined for use in signed TLS handshake messages, although they
      MAY appear in "signature_algorithms" and
      "signature_algorithms_cert" for backward compatibility with TLS
      1.2,

-Ben

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 29 May 2018 12:35:20 -0700

>       "signature_algorithms_cert" for backward compatibility with TLS

I was referring to
> 
>    -  Implementations that advertise support for RSASSA-PSS (which is
>       mandatory in TLS 1.3), MUST be prepared to accept a signature
>       using that scheme even when TLS 1.2 is negotiated.  In TLS 1.2,
>       RSASSA-PSS is used with RSA cipher suites.

I am OK with what you quoted. What I just quoted represents a
significant change in behavior in TLS 1.2 and there is no way to opt out
of this change to TLS 1.2.

I will add that I've seen this behavior by servers already, even when
client doesn't advertise TLS 1.3. Just the fact of including some 08 xx
IDs in signature_algorithms in ClientHello, without protocol_version
extension, gets the TLS 1.2 upgraded to RSA-PSS.

IMO this paragraph should be removed. Those that want PSS in the
handshake should negotiate TLS 1.3. Preservation of current behavior of
TLS 1.2 is important, at least as an option.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 May 2018 14:42:51 -0500

> of this change to TLS 1.2.

Ah, I misread your original message, but all is clear now.

> TLS 1.2 is important, at least as an option.

First off, it's basically too late to make substantive changes like that;
the bar to meet is something like "a huge outcry from deployments" or
"a critical security flaw".

Second, what's going on here is that TLS 1.3 is defining some new signature
algorithms for TLS messages, and making them mandatory to support for TLS 1.3.
But negotiation of TLS signature algorithms has *always* been independent of
protocol version.  If you support TLS 1.3, you also support the new signature
algorithms; if you support TLS 1.3 and TLS 1.2, you support the new signature
algorithms and you support TLS 1.2, therefore by the longstanding negotiation
rules you are obligated to support the combination.  You are in effect proposing
that we make a break in the signature (and hash) algorithm space with individual
algorithms supported either in <=1.2 or >=1.3, but not both -- we did this for
ciphersuites since we fundamentally changed the meaning of what a ciphersuite is.
But the signature scheme does not seem to have undergone such a fundamental change,
so it seems hard to justify introducing this sort of split.

-Ben

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 29 May 2018 13:01:51 -0700

> so it seems hard to justify introducing this sort of split.

We are talking about TLS 1.3-specific IDs:

         /* RSASSA-PSS algorithms with public key OID rsaEncryption */
          rsa_pss_rsae_sha256(0x0804),
          rsa_pss_rsae_sha384(0x0805),
          rsa_pss_rsae_sha512(0x0806)

In TLS 1.2 08 corresponds to the (undefined) hash algorithm, and thus
these IDs have no meaning to TLS 1.2.

TLS 1.3 spec purposely "split" these IDs so that they have no meaning to
TLS 1.2 servers. One needs the paragraph I quoted to force
implementations to change the behavior of TLS 1.2.

What's the harm of dropping this one paragraph I quoted and keeping TLS
1.2 behavior the same?

---

From: David Benjamin <[email-masked]>
Date: Tue, 29 May 2018 16:07:08 -0400

I'm not sure I follow this. So, in this scenario, you are the client. You
wish to support TLS 1.3, which requires supporting RSA-PSS in TLS 1.3, and
this is fine. You are able to verify RSA-PSS signatures from the server at
TLS 1.3.

At the same time, you still talk to some TLS 1.2 servers, so you may get a
response from them. As TLS 1.2 and TLS 1.3 use the same signature
algorithms negotiation, that same ClientHello obligates your client (newly
updated to support TLS 1.3) to also verify RSA-PSS signatures from TLS 1.2.
But this causes troubles somehow.

I'm confused how a client would have an RSA-PSS function available at one
version, but not the other. Or am I misunderstanding your situation?

On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov <[email-masked]> wrote:

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

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 29 May 2018 13:26:27 -0700

On 05/29/2018 01:07 PM, David Benjamin wrote:
> I'm not sure I follow this. So, in this scenario, you are the client.
> You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS
> 1.3, and this is fine. You are able to verify RSA-PSS signatures from
> the server at TLS 1.3.
> 
> At the same time, you still talk to some TLS 1.2 servers, so you may get
> a response from them. As TLS 1.2 and TLS 1.3 use the same signature
> algorithms negotiation, that same ClientHello obligates your client
> (newly updated to support TLS 1.3) to also verify RSA-PSS signatures
> from TLS 1.2. But this causes troubles somehow.
> 
> I'm confused how a client would have an RSA-PSS function available at
> one version, but not the other. Or am I misunderstanding your situation?

There is a need to upgrade TLS 1.2 stack, just because one can now
negotiate TLS 1.3.

Does this "upgrade" to TLS 1.2 extends to client authentication? Then
this adds more work.

There can be a performance penalty with RSA-PSS v.s. RSA legacy and more
issues when private keys are used in client authentication (because e.g.
they are HSM keys).

> 
> On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>

---

From: David Benjamin <[email-masked]>
Date: Tue, 29 May 2018 16:58:53 -0400

> There is a need to upgrade TLS 1.2 stack, just because one can now

I think this came up on the list earlier which way to go here, and folks
seemed to generally prefer this one. In our implementation, we unified the
TLS 1.2 and TLS 1.3 signature logic which made things simpler overall. I
think this was true for most folks.

> issues when private keys are used in client authentication (because e.g.

The client authentication scenario seems unrelated to me. In both TLS 1.2
and TLS 1.3, there is no relation between the client's advertised signature
algorithm list (which is the algorithms it will *accept* from the server)
and the client's signing preferences (which control the CertificateVerify
it will *send*). The latter is never even sent over the wire.

As a client, you get to choose which signature algorithm you use. Offering
RSA-PSS to the server for its TLS 1.2 ServerKeyExchange does not obligate
you to select it in your TLS 1.2 CertificateVerify. You select out of what
the server offered in CertificateRequest. This code point allocation means
the server *may* offer RSA-PSS and you *may* select it if offered. But if
that is difficult for whatever reason, you also can still select PKCS#1 if
the server offers it. (Of course, the server may offer you only things you
can't handle, but that's not a new concern.)

Chrome does just that. Our verify preferences include RSA-PSS, but our
signing preferences when configured for client certificates are separate,
precisely because of issues with smartcards and the like.

As for the performance penalty, I think it was clearly the WG's consensus
that the benefits of migrating to PSS outweighed the entropy draw and hash
operations that PSS takes.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 May 2018 16:00:17 -0500

> Does this "upgrade" to TLS 1.2 extends to client authentication? Then

In short: no.  CertificateRequest/CertificateVerify have a separate signature+hash
negotiation from the initial handshake, and the server is highly unlikely
to only list the new signature schemes.  (And I think you could decline the
authentication in that case anyway, but didn't double-check.)

The answer could also be "yes" in that if both sides *want* to, it can be done
for client authentication, but in your case you don't want to and are not
obligated to do so.

-Ben

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 29 May 2018 14:19:21 -0700

On 05/29/2018 01:58 PM, David Benjamin wrote:
> On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov <[email-masked]
> seemed to generally prefer this one. In our implementation, we unified
> the TLS 1.2 and TLS 1.3 signature logic which made things simpler
> overall. I think this was true for most folks.
>  
> 
> The client authentication scenario seems unrelated to me. In both TLS
> 1.2 and TLS 1.3, there is no relation between the client's advertised
> signature algorithm list (which is the algorithms it will *accept* from
> the server) and the client's signing preferences (which control the
> CertificateVerify it will *send*). The latter is never even sent over
> the wire.
> 
> As a client, you get to choose which signature algorithm you use.
> Offering RSA-PSS to the server for its TLS 1.2 ServerKeyExchange does
> not obligate you to select it in your TLS 1.2 CertificateVerify. You
> select out of what the server offered in CertificateRequest. This code
> point allocation means the server *may* offer RSA-PSS and you *may*
> select it if offered. But if that is difficult for whatever reason, you
> also can still select PKCS#1 if the server offers it. (Of course, the
> server may offer you only things you can't handle, but that's not a new
> concern.)

OK. We don't know, though, what will happen in practice with TLS 1.2
CertificateRequest if the server upgraded TLS 1.2 ServerKeyExchange.
Will it be more likely that the choices in CertificateRequest will be
narrower?

> signing preferences when configured for client certificates are
> separate, precisely because of issues with smartcards and the like.
> 
> As for the performance penalty, I think it was clearly the WG's
> consensus that the benefits of migrating to PSS outweighed the entropy
> draw and hash operations that PSS takes.

The issue here is that some hardware devices don't implement RSA CRT
method with PSS, because they hard-wide RSA, legacy padding, and CRT
method in one operation. RSA PSS can still be done, but only via a
general modexp operation, which will be ~2x shower. Therefore, in these
scenarios PSS incurs 2x performance penalty.

( Maybe RSA verification should be done on CPU, but this will require
changes to TLS 1.2 code. )

The limitations are similar to what you wrote about smartcards. There
are some odd hardware limitations. That hardware was just fine years ago
with TLS 1.2.

Higher entropy consumption is negligible here.

>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote:
>     >     >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote:
>     >     >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:
>     >     >>>> Greetings.
>     >     >>>>
>     >     >>>> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells
>     that if
>     >     a client
>     >     >>>> wants to negotiate TLS 1.3, it must support an upgraded (and
>     >     >>>> incompatible) version of TLS 1.2, the one that changes
>     RFC 5246
>     >     to allow
>     >     >>>> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.
>     >     >>>>
>     >     >>>> You might recall that the possibility to negotiate
>     between PSS and
>     >     >>>> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed
>     >     for X.509
>     >     >>>> signatures, was discussed on the mailing list. The WG
>     decision
>     >     then was
>     >     >>>> to hard-wire PSS in the TLS 1.3 handshake.
>     >     >>>>
>     >     >>>> I don't recall any discussion on going further than this, all
>     >     the way to
>     >     >>>> changing the 10-year old TLS 1.2.
>     >     >>>>
>     >     >>>> Unfortunately, our products have issues with PSS beyond our
>     >     control. The
>     >     >>>> only solution left to avoid receiving PSS with TLS 1.2 is
>     to never
>     >     >>>> negotiate TLS 1.3 as a client. Another solution is insecure
>     >     fallback,
>     >     >>>> but we presently don't do this.
>     >     >>>>
>     >     >>>> Is my reading of the situation correct? Thank you.
>     >     >>>
>     >     >>> Sounds like it:
>     >     >>>
>     >     >>>    RSASSA-PKCS1-v1_5 algorithms  Indicates a signature
>     algorithm
>     >     using
>     >     >>>       RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash
>     >     algorithm
>     >     >>>       as defined in [SHS].  These values refer solely to
>     signatures
>     >     >>>       which appear in certificates (see Section 4.4.2.2)
>     and are not
>     >     >>>       defined for use in signed TLS handshake messages,
>     although
>     >     they
>     >     >>>       MAY appear in "signature_algorithms" and
>     >     >>>       "signature_algorithms_cert" for backward compatibility
>     >     with TLS
>     >     >>>       1.2,
>     >     >>>
>     >     >>> -Ben
>     >     >>>
>     >     >>
>     >     >> I was referring to
>     >     >>>
>     >     >>>    -  Implementations that advertise support for RSASSA-PSS
>     >     (which is
>     >     >>>       mandatory in TLS 1.3), MUST be prepared to accept a
>     signature
>     >     >>>       using that scheme even when TLS 1.2 is negotiated. 
>     In TLS
>     >     1.2,
>     >     >>>       RSASSA-PSS is used with RSA cipher suites.
>     >     >>
>     >     >> I am OK with what you quoted. What I just quoted represents a
>     >     >> significant change in behavior in TLS 1.2 and there is no
>     way to
>     >     opt out
>     >     >> of this change to TLS 1.2.
>     >     >
>     >     > Ah, I misread your original message, but all is clear now.
>     >     >
>     >     >> I will add that I've seen this behavior by servers already,
>     even when
>     >     >> client doesn't advertise TLS 1.3. Just the fact of
>     including some
>     >     08 xx
>     >     >> IDs in signature_algorithms in ClientHello, without
>     protocol_version
>     >     >> extension, gets the TLS 1.2 upgraded to RSA-PSS.
>     >     >>
>     >     >> IMO this paragraph should be removed. Those that want PSS
>     in the
>     >     >> handshake should negotiate TLS 1.3. Preservation of current
>     >     behavior of
>     >     >> TLS 1.2 is important, at least as an option.
>     >     >
>     >     > First off, it's basically too late to make substantive changes
>     >     like that;
>     >     > the bar to meet is something like "a huge outcry from
>     deployments" or
>     >     > "a critical security flaw".
>     >     >
>     >     > Second, what's going on here is that TLS 1.3 is defining
>     some new
>     >     signature
>     >     > algorithms for TLS messages, and making them mandatory to
>     support
>     >     for TLS 1.3.
>     >     > But negotiation of TLS signature algorithms has *always* been
>     >     independent of
>     >     > protocol version.  If you support TLS 1.3, you also support the
>     >     new signature
>     >     > algorithms; if you support TLS 1.3 and TLS 1.2, you support the
>     >     new signature
>     >     > algorithms and you support TLS 1.2, therefore by the
>     longstanding
>     >     negotiation
>     >     > rules you are obligated to support the combination.  You are in
>     >     effect proposing
>     >     > that we make a break in the signature (and hash) algorithm space
>     >     with individual
>     >     > algorithms supported either in <=1.2 or >=1.3, but not both
>     -- we
>     >     did this for
>     >     > ciphersuites since we fundamentally changed the meaning of
>     what a
>     >     ciphersuite is.
>     >     > But the signature scheme does not seem to have undergone such a
>     >     fundamental change,
>     >     > so it seems hard to justify introducing this sort of split.
>     >     >
>     >     > -Ben
>     >     >
>     >
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 May 2018 11:17:21 +1000

> scenarios PSS incurs 2x performance penalty.

I'm fairly certain that we've had this discussion before.  What is new?

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 29 May 2018 21:53:50 -0700

> I'm fairly certain that we've had this discussion before.  What is new?

The quoted text quoted is old. The need to upgrade TLS 1.2 code if I
support TLS 1.3 is new.

I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS
will take place?

- This upgrade of TLS 1.2 can only be done by servers that support TLS 1.3.
- TLS 1.2 clients won't advertise TLS 1.3 Signature Algorithm IDs; only
TLS 1.3 clients will have e.g. rsa_pss_rsae_sha256 and others in
signature_algorithms.

Therefore, TLS 1.3 should get negotiated between these peers.

The relevant paragraph from the TLS 1.3 draft seems to add uncertainty
in unexplained cases when TLS 1.3 server decides to drop the negotiated
version to TLS 1.2. What problem does this paragraph try to solve?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 May 2018 15:13:42 +1000

> The quoted text quoted is old. The need to upgrade TLS 1.2 code if I

No, I'm certain we had that discussion too.

> I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS

When people deploy TLS 1.3.  Which is happening already.  You can avoid the
need as a server because a client willing to do TLS 1.2 will probably offer
RSASSA PKCS#1 v1.5 and you can rely on that being there.  But yeah, clients
are going to have to suck it up.  Here's the text, which I think is pretty
clear:
"
Implementations that advertise support for RSASSA-PSS (which is mandatory
in TLS 1.3), MUST be prepared to accept a signature using that scheme even
when TLS 1.2 is negotiated. "

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 29 May 2018 23:03:03 -0700

> when TLS 1.2 is negotiated. "

Correct. That's the single paragraph that I think should not be there.

As I asked in the previous message, what is a scenario when this
paragraph helps? When will we see a fallback to TLS 1.2 AND upgrade of
legacy PKCS#1.5 to PSS (within TLS 1.2)? Why such a server could not
accept TLS 1.3 and use PSS there?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 May 2018 16:32:05 +1000

> Correct. That's the single paragraph that I think should not be there.

This has been discussed.  The working group felt that it was worthwhile
having support for PSS in TLS 1.2 and that they preferred not to add more
codepoints to support that.

The cost here is as you say: clients that offer 1.3 need to be able to
handle PSS certs from a server.  The cost for the alternative is to make
the signature algorithm meaningful in TLS 1.3, which leaves us looking for
a solution for 1.2 (yes, a new codepoint would achieve that).