Re: [TLS] Possible TLS 1.3 erratum

Ilari Liusvaara <> Fri, 16 July 2021 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84B473A383F for <>; Fri, 16 Jul 2021 07:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bVbsep_t_0hN for <>; Fri, 16 Jul 2021 07:01:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A21A3A383D for <>; Fri, 16 Jul 2021 07:01:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AADDC67C86 for <>; Fri, 16 Jul 2021 17:01:47 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id mou0tnXVPxks for <>; Fri, 16 Jul 2021 17:01:44 +0300 (EEST)
Received: from LK-Perkele-VII2 ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id EDCEE28C for <>; Fri, 16 Jul 2021 17:01:42 +0300 (EEST)
Date: Fri, 16 Jul 2021 17:01:41 +0300
From: Ilari Liusvaara <>
To: "" <>
Message-ID: <YPGRRZVx1DbhEJ+x@LK-Perkele-VII2.locald>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] Possible TLS 1.3 erratum
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Jul 2021 14:01:55 -0000

On Fri, Jul 16, 2021 at 12:43:34PM +0000, Peter Gutmann wrote:
> Eric Rescorla <> writes:
> >As we are currently working on a 8446-bis, the best thing to do would be to
> >file a PR at:
> 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

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