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

Neil Madden <> Sat, 29 May 2021 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0311C3A07F5 for <>; Fri, 28 May 2021 23:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ylCvSCrYSv0y for <>; Fri, 28 May 2021 23:59:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FB303A07F4 for <>; Fri, 28 May 2021 23:59:33 -0700 (PDT)
Received: by with SMTP id v12so5351249wrq.6 for <>; Fri, 28 May 2021 23:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=YADYGqhvy8zQaadgHrYfWYgaEMwNFp2uBhwxcoUQlQk=; b=jf/doBSXxSDX6Fng4gT9tN5fMH0J2Nl4h9QrlJHpfyB6vG/YR/lWVB1nUz3dgmEpUZ uGHwdWTkyJhl5UQ7wjdKJgoox3wtwC8tIi04xpuhU59D2VYOTxOozKVV2vgYR/tJhSky xMsinuFJBTiRtVPoNYTGK0HTNMyI9vJYFKy9spA19wXA0ybpfIx1zaWciGGm6irnNiF+ 6YN2OYlWdXQ4wXdASneHHrf/kyw8qZvRzFnlnzuh2wYEBVhr35GvR+/ehJqLDpegcIRL r/bOwa1Xh5rZiC8lWOK1Rozj6zTODBrZTG/bmct3RSU+GmbmM+rmUJmkcX3HOxHRhfT+ ecxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=YADYGqhvy8zQaadgHrYfWYgaEMwNFp2uBhwxcoUQlQk=; b=B2qCtskMWrZTj5s/o9SGFIKqc4MmfFWBw9UN/nYpYdIxcDS2DE657ZeDQOFO+RZv52 C9EGbBKYqaDAH831yEpJyZQRz8IkI9QX5tfc9RcGKkYAM8vi1DK+waSlNAjQSzBMIz3/ aIHwv0VR6qaSDOHjBsBZEtt0RXOLeDFl0YSTTokeB4BfeJzEMj2bFsz5q+rc5iOY4V7W VN4cWtMcXHN1X0mTSk11bq+z4wnJfk2WNIvlkDgYK3Ouv3P1VYGfW+jh7VBqQUwP4BXL bTVQ2VwWsy9xHwZjXKHlt18uvqAOtvZjXpyOvEKYXh90gP1VAhlDrSVN17qWg+ObmdoT 7mZA==
X-Gm-Message-State: AOAM532Vhagp8D/jXndDyZjBD/UqRTa9B2tuA2i1J1OFU3bxPytFd9N2 s86VI3kQQyvOQcX9X69FzRg=
X-Google-Smtp-Source: ABdhPJwiwBElP+FSnQoGRtSmUkvNDFnw1dINLAgHP+B7Fkbd7sAhyhnifQpN/iapyelBqKxEg4QGkg==
X-Received: by 2002:adf:f90c:: with SMTP id b12mr12731736wrr.409.1622271570051; Fri, 28 May 2021 23:59:30 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id m7sm10622055wrv.35.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 May 2021 23:59:29 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-BEF43801-9375-4422-911A-DA9E15627975
Content-Transfer-Encoding: 7bit
From: Neil Madden <>
Mime-Version: 1.0 (1.0)
Date: Sat, 29 May 2021 07:59:27 +0100
Message-Id: <>
References: <>
Cc: "Salz, Rich" <>, Russ Housley <>, IRTF CFRG <>
In-Reply-To: <>
To: Justin Richer <>
X-Mailer: iPhone Mail (18D70)
Archived-At: <>
Subject: Re: [CFRG] RSA PSS Salt Length for HTTP Message Signatures
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 May 2021 06:59:38 -0000

> On 28 May 2021, at 15:45, Justin Richer <> wrote:
> On May 28, 2021, at 9:05 AM, Salz, Rich <> wrote:
>> Perhaps reconsider PSS. 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.

No EdDSA? RSA signatures are not very performant for this kind of sign-once-verify-once use-case, because the signing operation is comparatively very expensive for short messages. Although that cost is pushed out to the client, which is preferable, if that client is sending a lot of small API requests this can be a very large overhead. 

I have some serious reservations about the use of signatures for this use case at all. There is no privacy considerations section in the draft, but surely making user’s HTTP requests signed has serious implications for their privacy? Especially if the signing key may be unique to an individual. I think this will have similar privacy issues as DKIM [1].

If the intent of the draft is to provide “end-to-end integrity and authenticity” then IMO a MAC is more appropriate than a signature (which provides much stronger properties), perhaps in combination with an authenticated KEM like HPKE [2].



— Neil