[CFRG] RSA PSS Salt Length for HTTP Message Signatures

Justin Richer <jricher@mit.edu> Wed, 26 May 2021 20:45 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 786C03A1727 for <cfrg@ietfa.amsl.com>; Wed, 26 May 2021 13:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 M4BQjBmn057U for <cfrg@ietfa.amsl.com>; Wed, 26 May 2021 13:45:55 -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 036DC3A1726 for <cfrg@irtf.org>; Wed, 26 May 2021 13:45:54 -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 14QKjqqX008567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <cfrg@irtf.org>; Wed, 26 May 2021 16:45:53 -0400
From: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AC751C08-B8D8-4FB5-8AC7-617CF88084CE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
Message-Id: <1EED8807-C5C5-461F-BE60-34C44791849E@mit.edu>
Date: Wed, 26 May 2021 16:45:52 -0400
To: cfrg@irtf.org
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/YHkZVX3sZrpJG2wZl6LyYv9R7CA>
Subject: [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: Wed, 26 May 2021 20:46:00 -0000

Hi everyone,

I’m one of the editors of the HTTP Message Signatures spec, and I’ve got a question that I was told this list might be a good place to find an answer for. The latest draft of the spec is here if you want to follow along:

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html>

For some background, this spec defines methods for normalizing and signing HTTP messages (both request and response), along with ways to attach the results of that signature to the HTTP message. This is a draft of the HTTP WG. While applications can profile this with any algorithm that can take in the input string and output the byte array signature, we are defining a handful of general-use signature algorithm methods that can be signaled explicitly.

One of the methods we’re defining uses RSA PSS with SHA512 for a hash. What we’ve discovered in implementation is that it seems like there might be a couple other parameters that also need to be specified, specifically the “salt length”. I had been using one library that defaults this to 20, another library defaults it to (I think?) 32, and another library seems to vary it based on the SHA hash size. Is there a best practice here, or a way to determine what the correct salt length is? I couldn’t find anything in RFC8017 that suggests an appropriate value, so if I’m just missing it please point me to it. 

The current text from the signatures spec is the following, and I’d plan to just add “the salt length (sLen) value is (XX)” in both the sign and verify sections below:

To sign using this algorithm, the signer applies the RSASSA-PSS-SIGN (K, M) function [RFC8017 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#RFC8017>] with the signer's private signing key (K) and the signature input string (M) (Section 2.5 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#create-sig-input>). The hash SHA-512 [RFC6234 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#RFC6234>] is applied to the signature input string to create the digest content to which the digital signature is applied. The resulting signed content byte array (S) is the HTTP message signature output used in Section 3.1 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#sign>.

To verify using this algorithm, the verifier applies the RSASSA-PSS-VERIFY ((n, e), M, S) function [RFC8017 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#RFC8017>] using the public key portion of the verification key material ((n, e)) and the signature input string (M) re-created as described in Section 3.2 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#verify>. The hash function SHA-512 [RFC6234 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#RFC6234>] is applied to the signature input string to create the digest content to which the verification function is applied. The verifier extracts the HTTP message signature to be verified (S) as described in Section 3.2 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#verify>. The results of the verification function are compared to the http message signature to determine if the signature presented is valid.

Thank you so much for your help, and please be sure to CC me on replies as I am not subscribed to this list. 
 — Justin