On Fri, Jul 16, 2021 at 12:43:34PM +0000, Peter Gutmann wrote:
> Eric Rescorla <e...@rtfm.com> 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.
Actually, I think this is quite messy issue:
- Signature schemes 0x0403, 0x0503 and 0x0603 alias signature algoritm 3
hash 4, 5 and 6. However, those two things are not the same, because
the former have curve restriction, but the latter do not.
- The Ed25519 and Ed448 in TLS 1.2 are registered in messy way: It
looks like signature algorithms 7 and 8 are registered for that.
However, those are only valid for hash 8, so codepoints actually
precisely overlap with corresponding TLS 1.3 signature schemes.
- There is even worse issue with GOST signatures in TLS 1.2. Those are
signature algorithms 64 and 65, only valid for hash 8. Unfortunately,
the corresponding schemes 0x0840 and 0x0841 are unallocated.
Allocating those could cause issues.
- Signature algorithms 224 to 255 are reserved for private use. However,
much of the schemes those alias are unallocated. Putting any standard
allocations there could cause issues. No similar issue exists for hash
algorithms in private use range, because any standard signatures one
would use with those are reserved anyway.
So one algorithm one could use is:
- Handle anything with signature 0-3/224-255 and hash 0-6/224-255 as
signature/hash pair.
- Display schemes 0x0840 and 0x0841 specially.
- Handle anything else as signature scheme.
However, this would not be right for the three ECDSA codepoints, and it
would not be right if in future anything gets allocated to some
potentially troublesome scheme identifiers. It is not necressary to do
anything special with 0x0807 and 0x0808 because mapping those to schemes
gives correct result anyway.
> 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?
It is not mitigating any vulnerability. The reason is that some TLS
implementations have very hard time supporting RSA-PSS certificates.
And I do not find the conditions to be backwards: There are two, both
scoped.
There is an edge case through: What if keys are not carried on X.509
certificate? In that case, it seems that both are allowed. In
practicular, are Raw Public Keys X.509 certificates? Those do have
RSAEncryption/RSA-PSS distinction like X.509 certificates do. And
then there was some certificate type for automotive applications,
and potentially more future certificate types ("CBOR compressed" is
particualrly fun one, considering those can expand to actual X.509
certificates, but might not do so.)
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
