Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

[Hubert Kario <[e-mail]>]

On Wednesday, 13 September 2017 16:35:25 CEST Blumenthal, Uri - 0553 - MITLL 
wrote:
> >     > enforcing the default. The default being:
> >     > - Hash algorithm the same as specified in Signature Algorithm
> >     > - MGF1 hash is the same as above
> >     > - Salt length same as digest length above
> >     
> >     No problem with that being recommendation, but I've seen people
> >     claiming
> > 
> > that some applications don't follow that salt length requirement, so I'd
> > say it would cause unnecessary problems if it was set too strict
> 
> I’m sure some apps follow, and some don’t. I’m simply saying that it makes
> sense for TLS to pick a sensible default (like the above) and stick with
> it. Other apps may do what they think is best.

hmm, thing is, that while certificates with subjectPublicKeyInfo of rsa-pss 
are still pink unicorns in production deployments, certificates with 
signatureAlgorithm of rsa-pss are fairly common in Microsoft shops - it is the 
default signature method for MS AD for good few years now.

I do not know what hashes, how consistent with MGF1 and what salts sizes do MS 
CAs select for those signatures.

I'm quite sure that people will want to use those existing CA certificates and 
intermediate CA certificates on new servers that will be deploying TLS 1.3...

> As for above, in view of the following discussion I think it would be better
> to replace “Signature Algorithm” above with
> “subjectPublicKeyInfo.algorithm.parameters.hashAlgorithm”. I still think
> that only the necessary minimum of parameters should be passed explicitly.

And I would agree, if we didn't have PKCS#11 tokens. If you work on pure-
software implementation it will be much easier to have EE that cannot have 
limitations specified in subjectPublicKeyInfo. But as soon as you have to work 
with any kind of hardware implementations of RSA, that assumption goes out the 
window. Because even if your HSM does do all combinations, different one may 
not.

> >     and there are clients that advertise only a subset of hashes:
> >     https://www.ssllabs.com/ssltest/viewClient.html?
> >     name=Safari&version=6&platform=iOS%206.0.1&key=33
> Seriously? iOS 6? Why not iOS 5 or 4? I think I still have an iOS 5 device
> somewhere. ;-)

my point is that if a client from a major technological company, largely 
focused on security, can make such decisions, I don't see why other developers 
couldn't follow the same logic that makes them do what Apple did.

> >     > The cryptographic module would perform RSA-PSS *signature* with
> >     > whatever
> >     > hashes it can. It won’t bother with *validation*, so this module’s
> >     > limitations shouldn’t matter.
> >     
> >     but it can't perform that signature using hash
> >     *that the client didn't advertise*
> 
> You’re probably right. But for my benefit, could you please outline the
> scenario how this would/could be used? To make sure I completely understand
> the use case?

The use case may be of a limited client that implements only one hash 
algorithm and because it's low power, doesn't have a software fallback - 
allowing SHA256 only, everywhere (both on TLS level and on certificate 
signature level).

That client can then, exactly as the standard prescribes, advertise support 
only for signature schemes that support sha256: 
 * rsa_pkcs1_sha256
 * rsa_pss_sha256
 * ecdsa_secp256r1_sha256

Server side can be limited by policy, to have just sha384 signing in rsa with 
big key sizes (e.g. because some part of the web site is considered 'Top 
secret' and need to use keys more resistant to quantum computers) but also 
have P-256 ECDSA certificate for the public part of the web site as a 
fallback.

That server policy can be encoded in the subjectPublicKeyInfo.

In such situation we want the server to sign Certificate Verify with the ECDSA 
key - ecdsa_secp256r1_sha256 - even if the client advertises preference for 
RSA and server wants to respect it.

Situation with two RSA keys with different limitations is not much different.
We still want to pick a certificate that can be used to make a signature that 
client claims it will be able to verify - rsa_pss_sha256.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic