Re: [TLS] Possible TLS 1.3 erratum

Ryan Sleevi <> Tue, 20 July 2021 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 45CE83A2B26 for <>; Tue, 20 Jul 2021 10:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zSmQFgpRPFww for <>; Tue, 20 Jul 2021 10:05:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0570A3A2B25 for <>; Tue, 20 Jul 2021 10:05:26 -0700 (PDT)
Received: by with SMTP id e14so8972211plh.8 for <>; Tue, 20 Jul 2021 10:05:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c62/KUZ1E6lZxT8KwFyd1/w9UbNcOoGK+NkVukiiocQ=; b=F7k9Xnv6xtnSVYFEMLp/jeTElsGLAX1UNGtlQGNrTxdN1FvFjVzW+IgchFZE0bK4TR ye/dqGKLklaazofhbTYK5Wb07IrTOOcg09POE8w81FtHj0WkO0ik1ErHDVsRmPGSCegb 4PFrT9f2Po4jW8fQ4C5vwnm3MmiFlAL5iktAh3iuXJDJSjk0yC4zA4h8Iq/sM/dqftj7 0qT3UZ21Mteo+MX9w8IUFYzpgazByn1DfJBca+mIBJloZ7jQx4MFYHzZfLWCdNGq4WVc W4yB1zyTMUNdwDtoMcLM/eZAzWvAn4YX4k7QymbS6TCvuF5yCmfNnW9p7Vysjle8eSqz Mlgw==
X-Gm-Message-State: AOAM532vyzs+EobcIZVS7XPMjlhVoYMT0CPqoN1tcewh13G4wko5mHAi UogPiHbYSvAMQKQzByV77IZi2+72t+Y=
X-Google-Smtp-Source: ABdhPJy/KMyFdRFfn34KdoI7DVV8JRRZ7e2nv1xSvpji6j/b09GZwSc0P5QpW9KEKYcD3fPgq0XOTA==
X-Received: by 2002:a17:90a:6a43:: with SMTP id d3mr37113687pjm.15.1626800725919; Tue, 20 Jul 2021 10:05:25 -0700 (PDT)
Received: from ( []) by with ESMTPSA id v31sm19598147pgl.49.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jul 2021 10:05:25 -0700 (PDT)
Received: by with SMTP id j3so11730993plx.7 for <>; Tue, 20 Jul 2021 10:05:25 -0700 (PDT)
X-Received: by 2002:a17:90a:9205:: with SMTP id m5mr36691157pjo.172.1626800725059; Tue, 20 Jul 2021 10:05:25 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Tue, 20 Jul 2021 13:05:14 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Peter Gutmann <>
Cc: Ryan Sleevi <>, Hubert Kario <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000056705b05c7910f72"
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: Tue, 20 Jul 2021 17:05:31 -0000

On Tue, Jul 20, 2021 at 12:17 PM Peter Gutmann <>

> Is that purely to parse PSS in X.509, or for the overall PSS
> implementation?

The overall PSS implementation. Parsing PSS w/o an implementation is

Like most modern libraries, NSS is decoupled through various concerns. For
example, one layer deals with parsing the DER and extracting a higher-level
symbolic value specific to the API.

> I know PSS is a dog's breakfast of arbitrary parameters and values, but
> I'm a
> bit suspicious of that line count just to to process the 'Parameters'
> structure, particularly since it's shared with OAEP so already present if
> you
> support OAEP.

Eh, say that again? PSS uses RSASSA-PSS-Params and that's a distinct type
than RSAES-OAEP-Params - saltLength/TrailerField vs pSourceAlgorithm.

But most APIs abstract things so folks aren't dealing directly in DER, but
in whatever language-specific representation with type-safety - e.g. a C
struct/Java class/etc

Or are you supporting every single possible corner case and weird option
> rather than just { SHA-2, MGF1, SHA-2, $SHA2-blocksize }?

This is 100% part of the problem with PSS - that the parameters have
multiple combinations, rather than being either empty (encapsulated by the
OID to represent the combination) or being memcmp()able. However, both
cryptographic libraries and PKI libraries tend to deal with the abstract

> And that's exactly the point I'm making, the standard currently encodes
> low-
> level internal details of the PKI implementation into the TLS
> implementation.

Others have pointed out, this was already true with prior versions of TLS
and signature_algorithms reflecting both the TLS parameters and the PKI
parameters. The only distinction here is TLS 1.3 allows them to be treated
separately - since from the TLS point of view, the PKI is *mostly* an
opaque black box. I say *mostly*, because there is the TLS-level constraint
on the keyUsage of the identity certificate.

> Unless you're using one library to do it all, the TLS layer has no idea
> what
> OID the PKI layer is using to identify an RSA key in a certificate, and so
> it
> has no idea whether it should be saying rsa_pss_rsae or rsa_pss_pss because
> the PKI layer just presents a certificate with an RSA key.

No, this isn't really correct either. As mentioned above, since the first
version of TLS, there has been some coupling to the subject certificate
(the server certificate on the server, the client certificate for the
client). The server certificate's keyUsage has long affected the available
ciphersuites a TLS server can successfully negotiate - e.g. whether you're
using an ephemeral key exchange or not - and the subject key has equally
had an impact - e.g. you're not going to negotiate RSA with an EC key, full

So there's inherently a coupling at the subject certificate, but the
remainder, the certificate path building and verification part, is largely
left as an exercise to the reader. Netscape did this with SSL the IANA IPRA
of RFC 1422 never came about (and for good reason). It was left as a "TBD /
implementation defined" about the policy side, other than the requirements
on the leaf.

TLS 1.3 simply continues this abstraction. The TLS library knows what it
supports at the TLS layer, and still has to be able to parse certificates
and keys (but only its identity certificate), and can leave the
caller/consumer to provide the parameters about what its PKI library

> All of this is currently hidden by the fact that you can't get PSS-OID
> certs
> from any public CA that I know of

Yes, they're generally forbidden by browser policy, to avoid the
combinatorial compatibility explosion.

> so everyone can just hardcode rsa_pss_rsae
> everywhere and ignore the issue, but at some point some CA may accidentally
> issue a PSS-OID cert and then who knows what'll happen.

I'm not sure why you're posing it as "unknown" what will happen,
considering it's well-defined.