Subject: Re: [TLS] RSA-PSS in TLS 1.3

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Mar 2016 20:20:38 +1100

On 1 March 2016 at 16:06, Viktor Dukhovni <[email-masked]> wrote:
>> It is much easier to mandate PSS in TLS 1.3 now, than to remove it
>> later.  Servers that can't do PSS will use TLS 1.2.  This avoids
>> a break-the-web day.
>
> Sorry, ... than to remove *PKCS#1.5* later ...

Yes, this is true for some people, and likely it will be more true in
the future.  However, a MUST implement PSS is enough for me.  If it
seems like consensus is against this position, I'll back that all the
way.  However, on the web side of things, we've some experience with
killing stuff that we don't like.  It's not always painless (see
SHA-1), but I'd rather rely on that system than risk holding back 1.3.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 01 Mar 2016 11:02:10 +0100

On Mon, 2016-02-29 at 09:32 -0800, Joseph Salowey wrote:
> We seem to have good consensus on moving to RSA-PSS and away from
> PKCS-1.5 in TLS 1.3.  However, there is a problem that it may take
> some hardware implementations some time to move to RSA-PSS.  After an
> off list discussion with a few folks here is a proposal for moving
> forward.  
> 
> We make RSA-PSS mandatory to implement (MUST implement instead of
> MUST offer).   Clients can advertise support for PKCS-1.5 for
> backwards compatibility in the transition period.   
> Please respond on the list on whether you think this is a reasonable
> way forward or not.  

The mandatory to implement approach didn't help TLS 1.0 (which had a
DHE-RSA ciphersuite implemented by no-one for several years). If you
want to push for RSA-PSS, then please only define RSA-PSS. That, in
addition would allow to prevent that sharing of keys between TLS 1.2
and TLS 1.3 (i.e., prevent any cross-protocol attacks).

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Mar 2016 13:32:20 +0200

> On 1 Mar 2016, at 6:56 AM, Martin Thomson <[email-masked]> wrote:
> 
> On 1 March 2016 at 04:32, Joseph Salowey <[email-masked]> wrote:
>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
>> offer).   Clients can advertise support for PKCS-1.5 for backwards
>> compatibility in the transition period.
> 
>> From my perspective, this is fine.  I would like to say that we won't
> ever support PKCS#1.5 for TLS 1.3, but I think that I would rather
> have users on 1.3 with PKCS#1.5 than have them stuck on 1.2.
> 
> It seems like others are taking the position that we should say "MUST
> NOT use PKCS#1.5”.  

I’d go even further. I’d remove the rsapss(4) value from SignatureAlgorithm, leaving just rsa(1), and say that in TLS 1.3 an RSA signature is PSS just as it was PKCS#1.5 in TLS 1.2.

Certificates are a different issue altogether.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Mar 2016 13:35:26 +0200

> On 1 Mar 2016, at 6:52 AM, Andrey Jivsov <[email-masked]> wrote:
> 
> On 02/29/2016 02:36 PM, Hanno Böck wrote:
>> We have an RFC for PSS since 2003.
>> We had several attacks showing the weakness of PKCS #1 1.5.
> 
> In the face of such danger, what's your opinion on PKCS #1.5 signatures being perfectly fine in TLS 1.3 ? I refer to signatures in X.509 certs in the latest https://tools.ietf.org/html/draft-ietf-tls-tls13-11.
> 
> Why not ban PKCS #1.5 altogether from TLS 1.3? It will not only make TLS 1.3 more secure, but code simpler and footprint smaller. Besides, it's reasonable: TLS 1.2 already allows PSS in X.509

It would be cool to ban PKCS#1.5 from certificates, but we are not the PKIX working group. Nor are we the CA/Browser forum. When a CA issues a certificate it has to work with every client and server out there, When we use TLS 1.3, the other side supports TLS 1.3 as well, so it’s fair to assume that it knows PSS.

Yoav

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 1 Mar 2016 18:23:25 +0000

On 2016-03-01 11:35, Yoav Nir wrote:

>>> [HB] We have an RFC for PSS since 2003. We had several attacks 
>>> showing the weakness of PKCS #1 1.5.

And so (maybe not entirely coincidentally!): another attack, dubbed
DROWN, just emerged¹, using SSLv2 as - you guessed it - a
Bleichenbacher padding oracle against RSA PKCS#1 v1.5!

(Please do stop me if you've heard this one before! <g>)

>> [AJ] Why not ban PKCS #1.5 altogether from TLS 1.3? It will not 
>> only make TLS 1.3 more secure, but code simpler and footprint 
>> smaller. Besides, it's reasonable: TLS 1.2 already allows PSS in 
>> X.509

A very strong +1 as far as I'm concerned.

> [YN] It would be cool to ban PKCS#1.5 from certificates, but we
> are not the PKIX working group. Nor are we the CA/Browser forum.
> When a CA issues a certificate it has to work with every client
> and server out there, When we use TLS 1.3, the other side supports
> TLS 1.3 as well, so it’s fair to assume that it knows PSS.

Perhaps the PKIX working group and CAB/Forum could both use a friendly
reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains?
___
[1] <https://drownattack.com/drown-attack-paper.pdf>

- -- 
/akr

---

From: Watson Ladd <[email-masked]>
Date: Tue, 1 Mar 2016 10:26:35 -0800

On Mar 1, 2016 10:23 AM, "Alyssa Rowan" <[email-masked]> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

PSS doesn't help against Bleichenbacher attacks on encryption. The attack
still can compute a private key operation.

What we really need is key seperation or use of ECC certs only.

> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJW1d4SAAoJEOyEjtkWi2t6kIQP/2Ziaeu2RGqHqV1Oa6dB0+Go
> iPbrrHe9C7l7yHxWfhur6ldGUnqAKyzhD5X0RHby0lbpXTcBFQjWPQ3shZE8CUV2
> mM4N2UyoAu5w1kOkSvHImeWrtdOPDTBTZhwFJjzEHtLkri6+CXzKE82B94WfhX8/
> ddQxg9uaV7eDEcW4um+vn0NG/+IuiJvfVTX7YtNj0yVSvEO7bm6/WRHsWV0FaQ+C
> HtNawk+KP966PLUPH1N6vBvhNpiZkMtv3QUsKbzAQDn8SPfXHWGy2CBxPLjtIv2w
> dTmY9dOxJsc7KswtM7DJQqx7azgeGAlLc8MV1PyXw1fIq2qtVI4Fk1+DNrMteC5B
> cNkez/nPwR01FFj3QV5OnbpcqIX1v9nmGrpDuFw+99xcMjgRrSRc3boclV8/H0PA
> k8XllkgmXj75TkqSkPV1YXVwOJAT65Uwke7tKHf4TwXSwz+qZVji+y8ZqZ7ACs2/
> Pp3IrlNLuJUmFjE+p8zhhEQU6fQjEdkAxT/3KY8/1nKxlXByFVHu1p1jZk7aWBtw
> aSEDLCI4XKKAJ118yXRtHXxA7LGNujsBYCoSp1A4Rkce57Ea7iuVd4pmctbMgiTA
> g3UAb7cE4NflzRyQd1Gbycu6wenovj9bOD4HRdTuADRdfGpXv8HMEG+eOUuE7DHx
> Af4y+IDpfW7HTraWjiKX
> =iX03
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Mar 2016 18:38:17 +0000

> still can compute a private key operation.

Yes, fortunately TLS 1.3 eliminates RSA key transport.  Otherwise,
for key transport we'd want OAEP rather than PSS.

Still, even though DROWN does not attack RSA signatures, we cannot
say that ongoing use of PKCS#1 v1.5 signatures is particularly
wise.

    http://www.automatednetworkedstorage.biz/emc-plus/rsa-labs/historical/raising-standard-rsa-signatures-rsa-pss.htm

    Burt Kaliski, RSA Laboratories
    February 26, 2003

    Executive Summary

    RSA-PSS is a new signature scheme that is based on the RSA
    cryptosystem and provides increased security assurance. It was
    added in version 2.1 of PKCS #1.

    While the traditional and widely deployed PKCS #1 v1.5 signature
    scheme is still appropriate to use, RSA Laboratories encourages
    a gradual transition to RSA-PSS as new
    applications are developed.

So the question is how "gradual" we want the transition to be.  If
v1.5 is negotiable, in TLS 1.3, we're looking at another decade or
two, perhaps by then QC will make RSA obsolete?

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Mar 2016 21:20:39 +0200

> reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains?

Neither you nor I can post in any of the CA/Browser forum’s lists, because neither of us has either a browser or a public CA. 

There are some people who are active there and are reading this list, so they might take such a proposal there. I’m not very optimistic, though. While only CAs and browsers are members, they are keenly aware that even the public CAs have a wide variety of relying parties, running all sorts of software. And it’s much harder to scan clients than it is to scan servers, so it’s difficult to say how many clients will not be able to connect to a server with a certificate signed with RSA-PSS. Probably far too many for the CA/BF to be comfortable deprecating PKCS#1.  

The PKIX working group has shut down several years ago. The Curdle WG is a new working group whose charter includes deprecating obsolete stuff. Perhaps they might be interested.

Yoav

---

From: Hanno Böck <[email-masked]>
Date: Tue, 1 Mar 2016 21:45:06 +0100

On Tue, 1 Mar 2016 18:23:25 +0000

> Bleichenbacher padding oracle against RSA PKCS#1 v1.5!

To be fair, the issues surrounding RSA encryption are different ones
than the ones about RSA signatures.
We already agreed to deprecate RSA encryption entirely. Therefore DROWN
is irrelevant for the discussion here.

(What causes often confusion is that Daniel Bleichenbacher is
responsible for *two* major and completely unrelated attacks against
RSA PKCS #1 1.5, one against encryption and one against - badly
implemented - signatures)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Mar 2016 09:46:32 +1100

On 2 March 2016 at 05:38, Viktor Dukhovni <[email-masked]> wrote:
> Yes, fortunately TLS 1.3 eliminates RSA key transport.

It does not.  It just doesn't *use* RSA key transport.  That's the
unfortunate part.  Hence the call for key separation.

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 1 Mar 2016 17:03:03 -0800

> The PKIX working group has shut down several years ago. The Curdle WG is a new working group whose charter includes deprecating obsolete stuff. Perhaps they might be interested.

The removal of PKCS #1.5 signature support in TLS 1.3 is a client issue 
when client authentication is used. See examples here: 
https://www.ietf.org/mail-archive/web/tls/current/msg19096.html .

Regarding server-only authentication, it seems that there is assumption 
that TLS 1.3 will continue to use PKCS#1.5 for a long time in X.509 
certs. Then why "break Internet" or slow down adoption of TLS 1.3 by 
mandating PSS in one field of handshake?

Imagine that there is PSS#2 in the future. Is the intent to issue new 
TLS 1.4 that bans PSS and hardwires PSS#2? If not, there may still be a 
signature negotiation mechanism in TLS 1.3 in the future.

The reasons CAs are cold to adoption of PSS are similar to these of TLS 
servers or clients: 3d-party dependence, prior investment, FIPS 140 
certification, cost.

TLS WG can ban PKCS #1.5 in CA certs in TLS 1.3, but it wisely doesn't. 
Why one signature field is an exception? IMO this will lead to slower 
adoption of TLS 1.3, on balance. Nothing prevents e.g. OpenSSL from 
implementing PSS in HS (which is proposed as MUST anyway). Nothing 
prevents servers from not negotiating TLS 1.3.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Mar 2016 08:37:46 +0200

> On 2 Mar 2016, at 3:03 AM, Andrey Jivsov <[email-masked]> wrote:
> 
> The removal of PKCS #1.5 signature support in TLS 1.3 is a client issue when client authentication is used. See examples here: https://www.ietf.org/mail-archive/web/tls/current/msg19096.html .
> 
> Regarding server-only authentication, it seems that there is assumption that TLS 1.3 will continue to use PKCS#1.5 for a long time in X.509 certs. Then why "break Internet" or slow down adoption of TLS 1.3 by mandating PSS in one field of handshake?

The easy answer is: because we can. We can’t mandate for the CA industry what kind of certificates they should issue, or rather, we can, but they’ll rightly ignore us. We *can* mandate how a new TLS 1.3 implementation signs for another new TLS 1.3 implementation. Mandating that the certificates are signed with PSS would definitely slow down the adoption of TLS 1.3. Mandating what algorithm is used within the protocol does not. 

As long as the spec allows PKCS#1 all implementations will support it and many implementors will delay PSS because it’s not needed for interoperability. That’s what a rational manager would do: implement TLS 1.3 with PKCS#1 now, and place implementing PSS “on the roadmap”. I don’t think we should give them that incentive.

> Imagine that there is PSS#2 in the future. Is the intent to issue new TLS 1.4 that bans PSS and hardwires PSS#2? If not, there may still be a signature negotiation mechanism in TLS 1.3 in the future.

That depends. Did we find that PSS is insecure in this future? 

> The reasons CAs are cold to adoption of PSS are similar to these of TLS servers or clients: 3d-party dependence, prior investment, FIPS 140 certification, cost.

Both servers and clients tend to use libraries that implement both the protocol and the algorithms. OpenSSL springs to mind, as do NSS, GNUTLS, SChannel and whatever Apple calls their library. Sure there are separate libraries with software handshakes and hardware algorithms. Even OpenSSL does this with their “engines”. I don’t think this is reason enough to keep dragging obsolete algorithms with us.

> TLS WG can ban PKCS #1.5 in CA certs in TLS 1.3, but it wisely doesn't. Why one signature field is an exception? IMO this will lead to slower adoption of TLS 1.3, on balance. Nothing prevents e.g. OpenSSL from implementing PSS in HS (which is proposed as MUST anyway). Nothing prevents servers from not negotiating TLS 1.3.

Because this is a particular field that we control.

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Mar 2016 06:57:48 +0000

> Because this is a particular field that we control.

Which is in itself a reasonable argument for leaving legacy behind,
...  but also because adaptive attacks are I think a greater potential
threat against interactive TLS than against a bunch of CA-authored
bits at rest.

-- 
	Viktor.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 2 Mar 2016 09:10:57 +0000

> On 1 Mar 2016, at 8:23 PM, Alyssa Rowan <[email-masked]> wrote:
<snip>
>>> and server out there,

That doesn't have to be true.  For example, many OpenSSL-based servers 
can be configured to serve an ECC certificate to TLS clients that 
indicate support for ECC, and to serve an RSA certificate to other TLS 
clients.

>>> When we use TLS 1.3, the other side supports

+1

> There are some people who are active there and are reading this list, so they might take such a proposal there. I’m not very optimistic, though.

Please don't give up without even trying!

If you have a proposal, I'd be happy to post it to the 
[email-masked] list on your behalf.

Alternatively, you could post it to the [email-masked] list 
yourself.

<snip>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Rob Stradling <[email-masked]>
Date: Wed, 2 Mar 2016 09:16:11 +0000

On 02/03/16 09:10, Rob Stradling wrote:
<snip>
>> Neither you nor I can post in any of the CA/Browser forum’s lists,
>> because neither of us has either a browser or a public CA.
>>
>> There are some people who are active there and are reading this list,
>> so they might take such a proposal there. I’m not very optimistic,
>> though.
>

Oh, somebody else beat me to it:

https://cabforum.org/pipermail/public/2016-March/006910.html

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Mar 2016 11:25:07 +0200

> On 2 Mar 2016, at 11:16 AM, Rob Stradling <[email-masked]> wrote:
> 

Right. And the response was that while PSS in in NSS, it’s not in Firefox. No word on the other browsers out there, and definitely no word on a bunch of non-browser clients that connect to servers using certificates from the public CA.

I totally understand that the commercial CAs cannot afford to deprecate PKCS#1 now. It might be prudent to announce some long-term deprecation plan such as the one for SHA-1 signatures.

We can hope that by the time the transition is complete RSA will have been abandoned in favor of ECDSA and/or EDDSA, but I would not bet on it.

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Mar 2016 07:57:24 -0800

On Wed, Mar 2, 2016 at 1:25 AM, Yoav Nir <[email-masked]> wrote:

> Right. And the response was that while PSS in in NSS, it’s not in Firefox.
> No word on the other browsers out there, and definitely no word on a bunch
> of non-browser clients that connect to servers using certificates from the
> public CA.
>

For what it's worth, I expect PSS support to appear in Firefox sometime in
the
not too distant future, since it's clear we need it for 1.3 and it's not
much effort
to add it for 1.2 and below.

-Ekr

I totally understand that the commercial CAs cannot afford to deprecate
> PKCS#1 now. It might be prudent to announce some long-term deprecation plan
> such as the one for SHA-1 signatures.
>
> We can hope that by the time the transition is complete RSA will have been
> abandoned in favor of ECDSA and/or EDDSA, but I would not bet on it.
>
> Yoav
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Mar 2016 19:08:10 +0200

> On 2 Mar 2016, at 5:57 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, Mar 2, 2016 at 1:25 AM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On 2 Mar 2016, at 11:16 AM, Rob Stradling <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >> [email-masked] <mailto:[email-masked]> list on your behalf.
> >
> > https://cabforum.org/pipermail/public/2016-March/006910.html <https://cabforum.org/pipermail/public/2016-March/006910.html>
> 
> For what it's worth, I expect PSS support to appear in Firefox sometime in the
> not too distant future, since it's clear we need it for 1.3 and it's not much effort

I expect the version of our firewall that comes out in 2017 will support PSS as well in TLS and the PKI. The enterprise CA part of the product?  Probably not because it has to support the legacy.

Yoav

---

From: Dave Garrett <[email-masked]>
Date: Wed, 2 Mar 2016 16:16:15 -0500

On Wednesday, March 02, 2016 01:57:48 am Viktor Dukhovni wrote:
> adaptive attacks are I think a greater potential

+1

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Thu, 3 Mar 2016 13:35:46 +0000

Hi all,

Why don't we use an even more elegant RSA signature called " full-domain hash RSA signature" ?

As you know, a SHAKE (as a variable output-length hash function) naturally produces a hash value which fits any given modulus size. Therefore, no paddings are needed which avoids any potential issues with the paddings and the signature algorithm would be very simple. 

Regards,
Quynh. 

________________________________________
From: TLS <[email-masked]> on behalf of Dave Garrett <[email-masked]>
Sent: Wednesday, March 2, 2016 4:16 PM
To: [email-masked]
Subject: Re: [TLS] RSA-PSS in TLS 1.3

+1

---

From: Hanno Böck <[email-masked]>
Date: Thu, 3 Mar 2016 14:49:47 +0100

On Thu, 3 Mar 2016 13:35:46 +0000

> full-domain hash RSA signature" ?

Full Domain Hashing was originally developed by Rogaway and Bellare and
then later dismissed because they found that they could do better. Then
they developed PSS.

See
http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf

So in essence FDH is a predecessor of PSS and the authors of both
schemes came to the conclusion that PSS is the superior scheme.

> As you know, a SHAKE (as a variable output-length hash function)
> naturally produces a hash value which fits any given modulus size.
> Therefore, no paddings are needed which avoids any potential issues
> with the paddings and the signature algorithm would be very simple. 

You could also use SHAKE in PSS to replace MGF1. This is probably
desirable if you intent to use PSS with SHA-3.

PSS doesn't really have any padding in the traditional sense. That is,
all the padding is somehow either hashed or xored with a hashed value.
I don't think any of the padding-related issues apply in any way to
PSS, if you disagree please explain.

(shameless plug: I wrote my thesis about PSS, in case anyone wants to
read it: https://rsapss.hboeck.de/ - it's been a while, don't be too
hard on me if I made mistakes)

-- 
Hanno Böck
https://hboeck.de/

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Thu, 3 Mar 2016 14:21:01 +0000

Hi Hanno,

I think the PSS uses a random salt to get the hashing probabilistic.

A customized version of a SHAKE can/may take a domain-separation string or/and a random salt.

Quynh. 

________________________________________
From: TLS <[email-masked]> on behalf of Hanno Böck <[email-masked]>
Sent: Thursday, March 3, 2016 8:49 AM
To: [email-masked]
Subject: Re: [TLS] RSA-PSS in TLS 1.3

See

--
Hanno Böck
https://hboeck.de/

---

From: Fedor Brunner <[email-masked]>
Date: Fri, 4 Mar 2016 17:45:19 +0100

> hard on me if I made mistakes)
Please see the paper "Another Look at ``Provable Security''" from Neal
Koblitz and Alfred Menezes.

https://eprint.iacr.org/2004/152

Section 7: Conclusion

"There is no need for the PSS or Katz-Wang versions of RSA;
one might as well use just the basic “hash and exponentiate” signature
scheme (with a full-domain hash function)."

Fedor

---

From: [email-masked] (Martin Rex)
Date: Fri, 4 Mar 2016 18:01:20 +0100 (CET)

Fedor Brunner wrote:
> one might as well use just the basic ?hash and exponentiate? signature

Thanks a million for adding some clue to this discussion!

-Martin

---

From: Hannes Mehnert <[email-masked]>
Date: Mon, 7 Mar 2016 13:51:41 +0000

> I’d go even further. I’d remove the rsapss(4) value from SignatureAlgorithm, leaving just rsa(1), and say that in TLS 1.3 an RSA signature is PSS just as it was PKCS#1.5 in TLS 1.2.

I strongly agree to Yoav's proposal!  No need to have both RSA(-PKCS)
and RSA-PSS numbers in SignatureAlgorithms.

hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 7 Mar 2016 18:04:23 +0200

On Mon, Mar 07, 2016 at 01:51:41PM +0000, Hannes Mehnert wrote:
> > I’d go even further. I’d remove the rsapss(4) value from SignatureAlgorithm,
> > leaving just rsa(1), and say that in TLS 1.3 an RSA signature is PSS just
> > as it was PKCS#1.5 in TLS 1.2.
> 

Doesn't SignatureAlgorithms also negotiate the algorithms supported for
the cert chain? If it does, I think that complicates things.

Also, making the same ClientHello mean two different things depending
on yet-unnegotiated version seems odd to me.

-Ilari