Re: [TLS] PR to clarify RSASSA-PSS requirements

[Hubert Kario <[e-mail]>]

On Wednesday, 22 November 2017 13:15:58 CET Peter Wu wrote:
> Hi Nikos,
> 
> On Wed, Nov 22, 2017 at 09:42:04AM +0100, Nikos Mavrogiannopoulos wrote:
> > On Wed, 2017-11-22 at 03:54 +0000, Peter Wu wrote:
> > > Hi,
> > > 
> > > At the moment there is still ambiguity in the requirements for PSS
> > > with
> > > relation to certificates. Proposal to clarify this:
> > > https://github.com/tlswg/tls13-spec/pull/1098
> > > 
> > > 
> > > This PR intends to clarify the requirements for PSS support.
> > 
> > Hi,
> > 
> >  I commented on the PR, but to provide more context. I believe RSA-PSS
> > 
> > keys without parameters MUST be supported under TLS1.3. The reason is
> > that keys explicitly marked as RSA-PSS cannot be used for RSA PKCS#1
> > 1.5 encryption, and thus they provide a way for the server to know that
> > it must protect that key against (cross-protocol) attacks which utilize
> > RSA ciphersuites under TLS1.2.
> > 
> > On why you don't want mixing keys for TLS1.3 and TLS1.2 RSA
> > ciphersuites, see all the bleichenbacher attack reiterations over the
> > years.
> > 
> > So what about distinguishing the RSA-PSS keys with and without
> > parameters:
> > 
> > "an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters MUST
> > be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS) with
> > parameters MAY be supported`."
> 
> In my understanding, the parameters are REQUIRED (cannot be NULL), but
> an "empty" DER encoding means that the default parameters are used
> (SHA-1, MFG1 with SHA-1, salt length equal to SHA-1 output (20), default
> trailer) per https://tools.ietf.org/html/rfc8017#page-75

No, when the parameters are completely omitted (the 
AlgorithmIdentifier.parameters is completely omitted in the SEQUENCE of 
AlgorithmIdentifier), that means that the key is unrestricted and can be used 
with arbitrary hashes and salt lengths (just like a rsaEncryption key).
If the AlgorithmIdentifier.parameters is present but empty (empty SEQUENCE in 
DER), that means that all parameters are restricted and have default 
parameters (sha1, 20 byte salt).

RFC 5756 is a bit more explicit on requirements for EE and CA certificates:
   When the id-RSASSA-PSS object identifier appears in the
   TBSCertificate subjectPublicKeyInfo algorithm field of CA
   certificates, then the parameters field SHOULD include the RSASSA-
   PSS-params structure.  When the id-RSASSA-PSS object identifier
   appears in the TBSCertificate subjectPublicKeyInfo algorithm field of
   EE certificates, then the parameters field MAY include the RSASSA-
   PSS-params structure.

The unrestricted EE keys should be supported, and I would even go as far as 
specifying that in TLS1.3 RSA-PSS EE certs MUST be unrestricted.
-- 
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