Re: [CFRG] RSA PSS Salt Length for HTTP Message Signatures

Justin Richer <jricher@mit.edu> Fri, 28 May 2021 14:44 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CE53A2B0F for <cfrg@ietfa.amsl.com>; Fri, 28 May 2021 07:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBuqJVyhQOAZ for <cfrg@ietfa.amsl.com>; Fri, 28 May 2021 07:44:24 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C6F3A2B0E for <cfrg@irtf.org>; Fri, 28 May 2021 07:44:24 -0700 (PDT)
Received: from [192.168.1.49] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14SEiHI6014697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 May 2021 10:44:18 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <67015DB5-A45F-41C7-A236-C54DEB30DD8F@akamai.com>
Date: Fri, 28 May 2021 10:44:17 -0400
Cc: Benjamin Kaduk <kaduk@mit.edu>, Brian Smith <brian@briansmith.org>, IRTF CFRG <cfrg@irtf.org>, Russ Housley <housley@vigilsec.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB0D5FEF-C96A-4206-95C5-A2AD9C6A7193@mit.edu>
References: <1EED8807-C5C5-461F-BE60-34C44791849E@mit.edu> <1BF68544-CB14-4A60-88BB-4E80E2D9A094@vigilsec.com> <CAFewVt54d6NGEYOX6Tx=gMf+p9NqTVkb9VkRxr+VZL5eDSmhmA@mail.gmail.com> <20210527232354.GY32395@kduck.mit.edu> <67015DB5-A45F-41C7-A236-C54DEB30DD8F@akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/4ETFcMKXTWp8e6mlcnVLlku3TAk>
Subject: Re: [CFRG] RSA PSS Salt Length for HTTP Message Signatures
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 14:44:29 -0000

On May 28, 2021, at 9:05 AM, Salz, Rich <rsalz@akamai.com> wrote:
> 
> Perhaps reconsider PSS.  https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html is excellent reading.
> 

I appreciate the reference, thank you for that. It’s enlightening, but something to note: We aren’t :just: defining RSA-PSS, we’re also defining a flavor of RSA 1.5, a flavor of HMAC, and a flavor of ECDSA, each with fixed parameters including sizes and curves and the like. Which means that our own version of PSS is going to be a very strict and narrow selection tied to a single identifier, and if there’s enough of a draw from any community to define another set of parameters, it can be registered with a new label. The intent is to have zero variability here, which is why I’m reaching out to this group to help nail some of that down as best we can.

On top of that, the algorithm selection happens up at the application layer here, since this is all on top of HTTP. That means that if the two sides have their own way of figuring out which algorithm and parameters to use and they are configured with those, then they can just do that and it doesn’t affect the spec. There’s no expectation of interoperability or runtime negotiation if you’re doing a point solution like that, but for a lot of developers out there the point solution is safer and we can avoid the JOSE “alg: none” problem as a consequence. There are already communities that have their own underlying crypto systems and key management at the application level and they want to keep using that, and we want them to be able to do that using this spec right out of the box. We’re trying to be very careful in enumerating these requirements and expectations in the spec itself, including being much clearer about algorithm and key resolution strategies.

 — Justin