Re: [TLS] PSS and TLS 1.3

[Ilari Liusvaara <[e-mail]>]

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.

E.g. with 2048-bit keys, and SHA-512 with 512-bit salts, there are
126 octets to match, but only 64 octets to control, making it very
unlikely that suitable control value can be found. With longer keys,
each octet in key adds an octet to match but leaves octets to control
unchanged.


[1] Not that this wouldn't have security benefits, thanks to insecure
stuff SSL and earlier TLS versions pull off...

[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)..

[3] TLS 1.2 and 1.3 allows mixing and matching RSA and ECDSA in
chain.


-Ilari