Re: [TLS] Possible TLS 1.3 erratum

Ryan Sleevi <> Tue, 20 July 2021 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E93493A267B for <>; Tue, 20 Jul 2021 08:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.645
X-Spam-Status: No, score=-1.645 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 M6cSkGoMN0hH for <>; Tue, 20 Jul 2021 08:18:13 -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 91C953A2676 for <>; Tue, 20 Jul 2021 08:18:08 -0700 (PDT)
Received: by with SMTP id me13-20020a17090b17cdb0290173bac8b9c9so2107414pjb.3 for <>; Tue, 20 Jul 2021 08:18:08 -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=LXn5c4p+upnBOdjLYX3Tmc2M3QT9fyQ5IU7tl0vz8LY=; b=YESaKdCFdaJ2yzHYuZiEifIaEmXbQWuLQVedwJzlrQJBcVlD1PtIMbjQr51/hE9pIH OEzzxGgheg4fF4GiUiZh+35P5j4ye1sJpAHS3ykW4qChn10wGDHGE6or3niA4fB0HFSr I2oKIvyaMcwtndXBoUmwUcGZKKPbPYU1mdq83VQz98uXWUQmYGyQRPUJvo5DNIW2wT2f ZeEuRrNG2ysdq5lD+jF5MYckFZ24js3HH/jM6k58CO4urzezcGIGhzuQBpXVMH7xXlyw 6ZjWVG44SBKKG+oRqVJs+2G318J/XSjzvJmrN+LCUyo5ynl5hYCxw1QI0YoC8nFDTPz/ FBMA==
X-Gm-Message-State: AOAM530/znAIBCEfMnSavfLdCxrqVKjko8tZ6bUfPPFZndcz0gORQzRW /18XCiEQB+6iMd3fwHBnmTxTCpqOPVk=
X-Google-Smtp-Source: ABdhPJw9oyuJdnq53R3NF2CLtyG8O/460gsY7MtUK/K/4xNi8v7gXkrbpH2O4LKitiTA6kD0Xht3+g==
X-Received: by 2002:a17:903:2445:b029:12b:9d0e:6b97 with SMTP id l5-20020a1709032445b029012b9d0e6b97mr2233674pls.84.1626794287294; Tue, 20 Jul 2021 08:18:07 -0700 (PDT)
Received: from ( []) by with ESMTPSA id n23sm26056032pgv.76.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jul 2021 08:18:06 -0700 (PDT)
Received: by with SMTP id my10so13794724pjb.1 for <>; Tue, 20 Jul 2021 08:18:06 -0700 (PDT)
X-Received: by 2002:a17:902:9a41:b029:12b:8e55:d2b1 with SMTP id x1-20020a1709029a41b029012b8e55d2b1mr6753809plv.78.1626794286748; Tue, 20 Jul 2021 08:18:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Tue, 20 Jul 2021 11:17:55 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Peter Gutmann <>
Cc: Hubert Kario <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000009598ed05c78f8fc5"
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 15:18:18 -0000

On Tue, Jul 20, 2021 at 10:19 AM Peter Gutmann <>

> Hubert Kario <> writes:
> >I suggest you go back to the RFCs and check exactly what is needed for
> proper
> >handling of RSA-PSS Subject Public Key type in X.509. Specifically when
> the
> >"parameters" field is present.
> Looking at the code I'm using, it's four lines of extra code for PSS when
> reading sigs and four lines extra when writing (OK, technically seven if
> you
> include the "if" statement and curly braces lines).

I'm very happy for you. I think other implementers' experiences vastly
differ from your experience, and I hope we can agree that both are valid of

For example, the NSS library used by Mozilla has well exceeded a thousand
lines of code so far. I'm sure a thousand lines may not seem like much, in
the grand scheme of things, but not every line is "free or easy" - some
lines are harder to change, and reason about, due to the security
implications. For NSS, this is in part due to its layering design based on
PKCS#11 and its abstraction interfaces for certificates and verification.
It's also partly because as a security-critical library that affects
millions of users, a different standard is applied than might be applied a
hobbyist project.

For browsers like Chrome, used by over a billion users, there are indeed
practical concerns regarding the separation between the TLS layers and the
certificate layer. The "classic" late-90s view of "one library to do it
all" (TLS and PKI) is actually not that common in industry, at least not
those being used "at internet scale". From browsers to mobile devices to
the server room, it's not uncommon for TLS to be implemented by one layer
or library, while certificate verification to be handled by another. They
may share a cryptographic library (e.g. using NSS or JSSE), or they may not
(e.g. Chrome, which integrates with both BoringSSL and the OS libraries).
As such, it's not uncommon for there to be distinction in terms of
capabilities, whether due to abstractions in use or capabilities of the
library in use.