Subject: Re: [TLS] PSS and TLS 1.3

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 06 Feb 2017 01:12:05 +0100

On Mon, 2017-01-23 at 12:52 +0200, Ilari Liusvaara wrote:
> On Mon, Jan 23, 2017 at 09:05:28AM +0100, Nikos Mavrogiannopoulos
> wrote:
> > On Fri, 2017-01-20 at 17:43 +0000, Dr Stephen Henson wrote:
> > 
> > > Additionally PSS signatures (see RFC4055) can be used with RSA
> > > keys
> > > (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID).
> > > Does
> > > the RSASSA-PSS mean that both types must be accepted?
> > 
> > That's a quite interesting finding. Although that protocol behavior
> > seems to ease transition to RSASSA-PSS, it also paves the field for
> > new
> > cross protocol attacks. A server which can sign with either of
> > RSASSA-
> > PSS and RSA-PKCS1 and the same key is certainly less secure than a
> > server which can sign with either of them. The only way to enforce
> > that
> > a key is restricted is by requiring the id-RSASSA-PSS OID for
> > RSASSA-
> > PSS.
> 
> Unfortunately, dedicated RSA-PSS keys are pretty much undeployable,
> and
> requirement to use those would be de facto the same as removing RSA
> server signatures entierely from TLS 1.3[1].
> 
> I don't know any CA that would certify RSA-PSS keys. And adding new
> key
> types is a slow process. Heck, Certifying ECDSA keys are poorly
> supported among CAs[2].
> 
> And looking at RSA-PKCS1 and RSA-PSS, it doesn't seem likely that
> there
> exists a EM that is both valid in RSA-PKCS1 and RSA-PSS for any
> messages, unless keysizes are too small, hashes are too large or
> salts are too large.

The issue is that we cannot tell for sure. Any proof of security 
assumes that the keys are restricted to a single scheme. So I think we
got into a trap where we intended to increase security, while in fact
reduced the protocol's security, by ending-up adding RSA-PSS in a way
that can share keys with PKCS#1 1.5. I think that we should treat RSA-
PSS as the mean to increase security rather than the end-goal.

Even if the approach of separating keys would mean that RSA-PSS will
not be deployed immediately, it will allow implementors to provide
well-behaved clients that will refuse to mix marked as RSA-PSS keys
with the legacy ones. On the current protocol description it is
impossible for an implementor to do that. The reason is that if one
does that, his software will not be functional, will fail to connect to
several web servers, and thus will have to compromise (functionality
always wins over security).

> [2] Some commercial CAs (don't have list) and Let's Encrypt (signed 
> with RSA[3] and even then most ACME software can't handle those)..

TLS 1.3 requiring a different key type, will provide an incentive for
them to update.

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Feb 2017 13:36:28 +1100

> TLS 1.3 requiring a different key type, will provide an incentive for

I don't think that's how this works.  More likely, that would become a
reason not to deploy TLS 1.3 if you insist that only RSA-PSS certs are
used.

Yes, I know that it's relatively easy to configure a PSS certificate
separately.  I wrote the code that did that in NSS, but it's going to
remain the case that most servers have one cert.  If you have one
cert, then it's going to be the one that works with all the clients.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 6 Feb 2017 02:46:15 +0000

Nikos Mavrogiannopoulos <[email-masked]> writes:

>TLS 1.3 requiring a different key type, will provide an incentive for them to
>update.

No, it'll be an incentive for them to ignore the requirement, or work around
it.  The S/MIME WG looked at this years ago when they considered tying AES use
to RSA-PSS/OAEP, the plan being to use the adoption of AES to try and force
adoption of RSA-not-PKCS1.5.  It was canned pretty quickly: No implementation
support, no CA support, no HSM/smart card support, and you'd have to somehow
figure out how to set up keys so they couldn't be used with PKCS # 1.5 any
more in an environment where everything did PKCS #1.5.

(I realise this was a long time ago, so now it'll be more like little
implementation support, no CA support, little to no HSM/smart card support,
and the same thing about the environment.  And, as long as you do PKCS #1.5 as
encode-then-compare as per the spec, no particular motivation to move to PSS).

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 6 Feb 2017 07:27:36 +0200

> On 6 Feb 2017, at 4:36, Martin Thomson <[email-masked]> wrote:
> 

Right. The only reason anyone is currently using RSA rather than ECDSA is for compatibility with older clients. If those clients are so old that they don’t support ECDSA keys, they’re not likely to support RSA-PSS.

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 6 Feb 2017 14:19:17 +0200

> PSS as the mean to increase security rather than the end-goal.

Looking at the signature constructions, I would say it is _extremely_
unlinkely that cross-protocol attacks are possible.

And this is with extremely loose criteria and extremely loose attacker
resource budget.
 
> TLS 1.3 requiring a different key type, will provide an incentive for

More like roadblock to upgrade to TLS 1.3.

Getting CA support for RSA-PSS keys would be SLOW to say the least.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 6 Feb 2017 11:57:30 -0500 (EST)

----- Original Message -----
> unlinkely that cross-protocol attacks are possible.

Isn't the whole purpose of moving to formally proved schemes, the fact that there
is a proof of security? This support by TLS 1.3 invalidates this proof, thus
making any reason to have RSASSA-PSS moot, (unless of course we have a proof
that RSASSA-PSS when combined with RSA PKCS#1 1.5 is secure).

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 6 Feb 2017 23:18:26 +0200

> that RSASSA-PSS when combined with RSA PKCS#1 1.5 is secure).

As to why I said I consider it unlikely: You need to match up a lot of hash
output bits (easily over 1,000) with at most 512 bits of input in order to
effect a cross-protocol attack.

Matching up 1,000 hash output bits would be hard enough. That one has
only 512 bits of input makes it with overwhelming probability impossible.

-Ilari