Re: [TLS] Possible TLS 1.3 erratum

[Peter Gutmann <[e-mail]>]

Eric Rescorla <[e-mail]> writes:

>As we are currently working on a 8446-bis, the best thing to do would be to
>file a PR at: https://github.com/tlswg/tls13-spec

Before I do that I thought I'd get some input on what to say, there's actually
two issues, the first being the one I mentioned.  I was thinking something
like:

  TLS 1.2 defined the entries in the "extension_data" as two eight-bit values
  constituting a { hash, signature } pair.  TLS 1.3 changes the definition to
  be a single 16-bit value constituting a cipher suite that encodes both the
  signature and hash algorithm into a single value.  Although some of the TLS
  1.3 values, in particular the rsa_pss_rsae_xxx ones, appear to follow the
  TLS 1.2 format, implementations SHOULD NOT treat them as { hash, signature }
  pairs but as a single cipher suite identifier.

The second one is the fact that there are two different cipher suites for RSA-
PSS, rsa_pss_rsae_xxx and rsa_pss_pss_xxx, with conditions for use that are
stated in a somewhat backwards form, "If the public key is carried in an
X.509 certificate, it MUST use the RSASSA-PSS OID".  Since the only reason
these exist AFAICT is to deal with rsaEncryption vs. RSA-PSS certs, it should
really be stated as something like "the RSA-PSS code point used depends on how
the key is carried in an X.509 certificate.  If the certificate OID is
rsaEncryption then the rsa_pss_rsae_xxx form MUST be used.  If the certificate
OID is RSASSA-PSS then the rsa_pss_pss_xxx form MUST be used".

And then add some explanation for why this is so and what'll go wrong if you
use the other one, since I can't see any reason why you can't just use
rsa_pss_rsae_xxx or rsa_pss_pss_xxx for everything.  What vulnerability is
this mitigating?

Peter.