From nobody Wed May 26 14:38:45 2021 Return-Path: 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 3F9EC3A0788 for ; Wed, 26 May 2021 14:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 IW9mJD3Mdwoq for ; Wed, 26 May 2021 14:38:40 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5D93A0781 for ; Wed, 26 May 2021 14:38:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 47C40300BE7 for ; Wed, 26 May 2021 17:38:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id I-c53eLwFLGw for ; Wed, 26 May 2021 17:38:31 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id A8087300AFC; Wed, 26 May 2021 17:38:31 -0400 (EDT) From: Russ Housley Message-Id: <1BF68544-CB14-4A60-88BB-4E80E2D9A094@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_ED9B403D-9BB6-4695-93B7-ACBE18F001E8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Wed, 26 May 2021 17:38:29 -0400 In-Reply-To: <1EED8807-C5C5-461F-BE60-34C44791849E@mit.edu> Cc: IRTF CFRG To: Justin Richer References: <1EED8807-C5C5-461F-BE60-34C44791849E@mit.edu> X-Mailer: Apple Mail (2.3445.104.20) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2021 21:38:44 -0000 --Apple-Mail=_ED9B403D-9BB6-4695-93B7-ACBE18F001E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 RFC 4055 has this recommendation: The saltLength field is the octet length of the salt. For a given hashAlgorithm, the recommended value of saltLength is the number of octets in the hash value. Russ > On May 26, 2021, at 4:45 PM, Justin Richer wrote: >=20 > Hi everyone, >=20 > I=E2=80=99m one of the editors of the HTTP Message Signatures spec, = and I=E2=80=99ve 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: >=20 > = https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.h= tml = >=20 > 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. >=20 > One of the methods we=E2=80=99re defining uses RSA PSS with SHA512 for = a hash. What we=E2=80=99ve discovered in implementation is that it seems = like there might be a couple other parameters that also need to be = specified, specifically the =E2=80=9Csalt length=E2=80=9D. 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=E2=80=99t find anything in RFC8017 that = suggests an appropriate value, so if I=E2=80=99m just missing it please = point me to it.=20 >=20 > The current text from the signatures spec is the following, and I=E2=80=99= d plan to just add =E2=80=9Cthe salt length (sLen) value is (XX)=E2=80=9D = in both the sign and verify sections below: >=20 > To sign using this algorithm, the signer applies the RSASSA-PSS-SIGN = (K, M) function [RFC8017 = ] with the signer's private signing key (K) and the = signature input string (M) (Section 2.5 = ). The hash SHA-512 [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 = . >=20 > To verify using this algorithm, the verifier applies the = RSASSA-PSS-VERIFY ((n, e), M, S) function [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 = . The hash function SHA-512 [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 = . The results of the verification function are compared to = the http message signature to determine if the signature presented is = valid. >=20 > Thank you so much for your help, and please be sure to CC me on = replies as I am not subscribed to this list.=20 > =E2=80=94 Justin > _______________________________________________ > CFRG mailing list > CFRG@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_ED9B403D-9BB6-4695-93B7-ACBE18F001E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 RFC = 4055 has this recommendation:

         The = saltLength field is the octet length of the salt.  For a
         given hashAlgorithm, the = recommended value of saltLength is the
  =        number of octets in the hash value.

Russ

On May = 26, 2021, at 4:45 PM, Justin Richer <jricher@mit.edu> wrote:

Hi everyone,

I=E2=80=99m one of the = editors of the HTTP Message Signatures spec, and I=E2=80=99ve 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-sign= atures-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=E2=80=99re defining uses RSA PSS with SHA512 for a hash. What we=E2=80=99= ve discovered in implementation is that it seems like there might be a = couple other parameters that also need to be specified, specifically the = =E2=80=9Csalt length=E2=80=9D. 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=E2=80=99t find anything in RFC8017 that suggests an = appropriate value, so if I=E2=80=99m just missing it please point me to = it. 

The = current text from the signatures spec is the following, and I=E2=80=99d = plan to just add =E2=80=9Cthe salt length (sLen) value is (XX)=E2=80=9D = in both the sign and verify sections below:

To sign using this = algorithm, the signer applies the RSASSA-PSS-SIGN = (K, M) function [RFC8017] with the signer's = private signing key (K) and the signature input = string (M) (Section 2.5). The hash = SHA-512 [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.
To verify using this algorithm, the = verifier applies the RSASSA-PSS-VERIFY ((n, e), M, = S) function [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. The hash function = SHA-512 [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. 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. 
 =E2=80=94 = Justin
_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

= --Apple-Mail=_ED9B403D-9BB6-4695-93B7-ACBE18F001E8--