Re: [TLS] PSS and TLS 1.3

[Nikos Mavrogiannopoulos <[e-mail]>]

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