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

John Mattsson <john.mattsson@ericsson.com> Thu, 27 May 2021 17:10 UTC

Return-Path: <john.mattsson@ericsson.com>
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 10FCF3A0ADE for <cfrg@ietfa.amsl.com>; Thu, 27 May 2021 10:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 o_mkqLEnl3wR for <cfrg@ietfa.amsl.com>; Thu, 27 May 2021 10:10:42 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2085.outbound.protection.outlook.com [40.107.20.85]) (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 A8A093A0AD8 for <cfrg@irtf.org>; Thu, 27 May 2021 10:10:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dwK5ykJB/gSWR2zssLEJUl8UnJA8Y16gg/60VJjv6i+ugB8HCWZfK6qGDivZjIEwPUa/Y/mK6s4fovMDk4Dh6NbVafwimS+YzZLmExBg/oVM7XL8Lf0eUjurNKWkS2TWg1WPt/HbtN80fQ8M6ElNey4cLeB+P0nKMMF0U9TP3I0IkVybGFVxfLpg8T/1QUyjmoSpFTn8meMF2b/ximA9v1ugW9NyXCAU3n4yL3NSL0rzHqLt2VD4wxwZGDY5Mf/01wt9rE4NnNv0UfaRrnQISAIF6xAdMt+D66JnNNWDJ3lsK62igV3AHsIsycPDbEdfZDUTRHi8kPTafwA2YJWvTg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=97a6W2Ug6A/Ipv+qbeTuryuPlKjMVsbbdXOsLoeMQtg=; b=DG3zZRdUORZgjPJWKIG/NBdGRgFFEpnxj1al4Vzlw9Hhh+MSZE6rRCuTok4/hVoqSjtWLM312MkRhH3tFldLVIeqlf6uHYfElYPC4tsIAB9RjTkkGQoJ8FUT0p6doWzzGpWYQzaHJAF8f6YKVh6M5+0DFXoQMfIGtoamxDr8SHBBbTX47RICPxKe5ldUQMguHvrPxFGXB7AHaGk9EfjBERxit+kQ0ozW7AiEYHnVssX5I3idgBUolYiIVKBEQe72vkAHACjrfkNvSq3aflloGKfRRTwV6ymkrzPe1da+DRlBINmG9NvHXUKDY88sIVwd/Vbbt8MfRjFcnvTeSGrMtQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=97a6W2Ug6A/Ipv+qbeTuryuPlKjMVsbbdXOsLoeMQtg=; b=g32TweGlPApw+MxU52jFh1qrePrnzkrJGoDlOgKMvAiGiY5k3oM8XuCJlAZSPPqMOFoP1KxUlx+TfL1vD4gaghOsiIG8Fhjg3mT0exeVc0LnxECUsa6paXBSRkSf2RXPJAwVbFEbp3SaJVVwDghRTe5JNpWHbzP2jwSuSgJPbkk=
Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0702MB3563.eurprd07.prod.outlook.com (2603:10a6:7:80::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.16; Thu, 27 May 2021 17:10:36 +0000
Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3%11]) with mapi id 15.20.4173.024; Thu, 27 May 2021 17:10:35 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Justin Richer <jricher@mit.edu>, Russ Housley <housley@vigilsec.com>
CC: IRTF CFRG <cfrg@irtf.org>
Thread-Topic: [CFRG] RSA PSS Salt Length for HTTP Message Signatures
Thread-Index: AQHXUnA2Bmk3FRBRDEOCfteC/c2xyKr2Sg6AgAE3ngCAAA8M0Q==
Date: Thu, 27 May 2021 17:10:35 +0000
Message-ID: <HE1PR0701MB30509CFAC2752751667D11EA89239@HE1PR0701MB3050.eurprd07.prod.outlook.com>
References: <1EED8807-C5C5-461F-BE60-34C44791849E@mit.edu> <1BF68544-CB14-4A60-88BB-4E80E2D9A094@vigilsec.com>, <3C751F77-2362-4099-850B-263C08F60AC4@mit.edu>
In-Reply-To: <3C751F77-2362-4099-850B-263C08F60AC4@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [81.225.97.222]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0b30d137-1e84-44b2-071a-08d921325807
x-ms-traffictypediagnostic: HE1PR0702MB3563:
x-microsoft-antispam-prvs: <HE1PR0702MB35630A77E6E6F969269B907689239@HE1PR0702MB3563.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6/xMcNzeO2SYaNSjHbdm/2YkFYXNBa4kvyMhh/9TTNntCIMwDrFXlGST0N8SbyPSeKUDfHm1lellty8FPkRUrTgxLbtlHXHlU9wR9RuJKDFtWp3Uolq2Sb2rTaO0noagblc1P2wNDhYJXX4muM9rqbRoJxVu78npUKrpRsfIu2e4ReBUpV8xwwHcmIk/HMMsgWMJmJeGC789OCGFG7CG7g9r4P7VyIt94lLOGyMYIjY3qxFSjs9BuqkKLc/RjqCIcjaHzdXqeXIA1JYq/BrcAAsnqKJPa2JACPPtGco49Uyyr2gttGkIYr+KuZWNszfNQDH8Pw48kzFyuTjoyDpbA7LvxtJUiBVHQfbUc5SoKRdtTN/i57xa4pw71U7r84HpPpupjcEBxD2slPEw47JEjl3/sj3HEMPPCHxOBRbq2nv2MELawbhg44/pr/lj+VcIxhfk+4CLqv/S4iCTrmRRMZgOLq0bupwpjbbyFB468sKGgTjGvmNStZCivKRksZPLzZaI++QVHm9IBRopzz+Jf0cPoSV+qm3fHeT0cgGx1qJLosvpMi1kD4fuyLXHddOE1PmiHfImy8mS97Id4qFfd7OdtnXMEtThfMGCUbvQNNGdmiWv/JhWSiuWgnTudKOjRkZdtOhDx9imO4Ke3YV8pU4dXsQfridP7Kd7zJzvQnbk+JnvWaAC7CGbvcfX4HHHpIrYnoG1/69HhiuD3I9p2qkzOOiKlzkKu3KyrGJh3QY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(39860400002)(376002)(366004)(136003)(55016002)(53546011)(6506007)(9686003)(33656002)(76116006)(966005)(478600001)(4326008)(66446008)(64756008)(66476007)(71200400001)(66556008)(2906002)(83380400001)(316002)(122000001)(5660300002)(110136005)(38100700002)(66946007)(52536014)(7696005)(15650500001)(8936002)(26005)(44832011)(186003)(166002)(8676002)(86362001)(21615005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?gb2312?B?aHk5R3NuaTI3bXA5SExnNWxnRGYyaXpjamNoeWF6ekNFQ3JSb1FKN3NmY1c5?= =?gb2312?B?aU9aejlBWGRhMHFweGs3UGF0TzZycnNnSmhJd3RzTExrbXoxYklySkJiY3Iw?= =?gb2312?B?S0RVb0JDaDYwY1VNU1N3Qm1QbnpKdHNFd1ZNQUlGL0QzSVgrZU5GNXVvRFVj?= =?gb2312?B?S2JmdTVBcmpTOVZKYUZ0eWJIMDNDV2p1RlJrdUFFUDdSUk5VbFFzcDkxVitG?= =?gb2312?B?aVdhSzJwSUYrS3BLSlJTREpHUEZkYTVtQ1ZmK2JhMGRKQTlmQXBJdXlRamxP?= =?gb2312?B?RWZoelhSOGlRQUp1NGRlWDhQREkrQkM2N1pyNHlvRmYwK1lVWng4OU5vVHlY?= =?gb2312?B?WERZRFg4SVBnN3poMWxyVW5WWHduM0ExZGdDdmJEbFhiRWdhTms1cVNRQlo5?= =?gb2312?B?cld1dzMva1RzZWxGZithT1NmUUhEY1hCVENINkh5cUZ2M1N6MTZmMk8yeFFU?= =?gb2312?B?ejlvL2F6dGUrNXVGSnNDbFVhQ3p6c3E2R210eXhma0lxOXAyUXVLQVM0MXI1?= =?gb2312?B?Nnc2cVRDM2UrTVpxcTNOMTYzdFhCRUE1Wk5CbGNZR3RFQXlqcEhXT0Qxd1Ey?= =?gb2312?B?SUxhL0FqOFkycFRSczN3d2xLQWZMbnRMK1lYVW45Ulg0b3FHSThMWjc0dVFV?= =?gb2312?B?dHRQeGZ3MDJmYU4rUmVqdXUxZW5SV2gvR1NpSHNYR1FSKzZlRDBObzZEcWZI?= =?gb2312?B?SzRDOThvSXY4VDJsdGtJak1CTDF0ZnZnYjJKYi9WM1Z4TmhBNHRmbXlub3VW?= =?gb2312?B?MGhiUmYza3VQUTZaZGFZMWtHb2FFa0VlOG1rdFVFazFob3dKQ2JCcS82TEMv?= =?gb2312?B?WWQybzdjSmZHaWFrMk5kZzFXdm1jRWtKdEtXeHFSeTlxajc5LzlweVgyRGdu?= =?gb2312?B?Y2RUSXdpeXZXRllueloxNTNBQSszRVEwQmFFTFNtblpaWW5mOVYxMzdsN2xk?= =?gb2312?B?ejRTbWVHUnU2a1ZSSUF6alBXdGNNaWd6QVFNUkYvK2NRQlAvRHpWQmFSaE9n?= =?gb2312?B?Z1QybnRyU2ZCM0RsMHc5Ums2WmllOUhvYTNRZ2l4ak9OUVRUK1kra1lQMmV2?= =?gb2312?B?WWUxQ2pWM1psSnVQdXlodHBZNjNjT3lOYWVySVEvekt6SFVudVJBRlVLQm16?= =?gb2312?B?YUV0bFVPazUvc3NZRk5oV3FTMVRYQ29aOE1nWkM0djBWcEo3Qm1sRWgraVJV?= =?gb2312?B?Q1RmY2dQZEhSSU80Nm1QaS90UmE2VytwMTE1MUo5aTZGdStyZ2ZlZU9uNUZo?= =?gb2312?B?RUgvajFoSW1iblNjUTJEWDFWWmk0WnVtdkhtSy9IR3BLaFAvb1MzaGh5cEd4?= =?gb2312?B?R2NkOTF1L1Vaem9LemJqOGxRNWMrZ0tzSjVxV0FMY0NFS01kTHdnVzB2YlJC?= =?gb2312?B?TTl6bndicUFaWSs5TFdxZmdaUnNEZXB6d2VKazczQVNjYm1meWRXS3FsWS9S?= =?gb2312?B?bjljc2FQN0pJRlZsTm1Kb0g4V1grbEpOeGlqdlpWVk44WlE0S1pXVU9SSjJs?= =?gb2312?B?bFJZb3pMZ1JFb05oZ0J6NW1BMmVtZmw0c0RFbmVPMVhCQzNnTDByeWxISnZ5?= =?gb2312?B?Zi9xTWZBQWZDVkhoRm02TXVBWWFQU042ejJtRnNtVGMyQWhIQUNFcG05MDBj?= =?gb2312?B?QnhJSWVZY3E3R0tMTUdROXJpSVc3OXRIRllCZVMzV1lBek4rWGZBSWJIdk9i?= =?gb2312?B?bFh2UGpSQ0g3Wkw5TWM0d0w2ZTFpcXU5RXVlRmRVQTZVakQ5ZGJ5U0UvQVB0?= =?gb2312?B?YllGdmFvNWRqR1lIME5YOFo5RTJSdzh0TERYem1MdWNHcUVxKzZ5dnI1ODAw?= =?gb2312?B?MHlheEJ6eGxWMXNXZnVlZz09?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30509CFAC2752751667D11EA89239HE1PR0701MB3050_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b30d137-1e84-44b2-071a-08d921325807
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2021 17:10:35.7033 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RKCn4E6gYbaQA5Qxq70wNnQdr77OG+4b2Bea1knDxpFdu9AbBNubTBAFzckavQADscLghZ9PQvreAGbRcF56zGzzcs4qB87/xg8T05DhBzY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3563
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/lz03lF68OrdcCO0427lQ3XBZphc>
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: Thu, 27 May 2021 17:10:47 -0000

Don't forget to specify the mask generation function (MGF). That is another important input. RSA-PSS use two different hash functions that can be different. I have seen implementations of RSA-PSS with SHA2 that only support MGF©\1 with SHA©\1.

Modern standards like CAB Forum Baseline Requirement, JOSE, and COSE, RFC 8692 require use of the same hash algorith for both. CAB Forum Baseline Requirement calls it:

"RSASSA©\PSS with SHA©\512, MGF©\1 with SHA©\512, and a salt length of 64 bytes"

Cheers,
John

From: CFRG <cfrg-bounces@irtf.org> on behalf of Justin Richer <jricher@mit.edu>
Date: Thursday, 27 May 2021 at 18:14
To: Russ Housley <housley@vigilsec.com>
Cc: IRTF CFRG <cfrg@irtf.org>
Subject: Re: [CFRG] RSA PSS Salt Length for HTTP Message Signatures
Thank you! That is clear guidance and we can use that to set a known value since we are fixing the hash size, in this specific case.

 ¡ª Justin


On May 26, 2021, at 5:38 PM, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> wrote:

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<mailto:jricher@mit.edu>> wrote:

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

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>)t>). 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>gn>.

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>fy>. 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>fy>. 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
_______________________________________________
CFRG mailing list
CFRG@irtf.org<mailto:CFRG@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg<https://protect2.fireeye.com/v1/url?k=0037cec6-5facf624-00378e5d-86073b36ea28-55e61acee15efdff&q=1&e=b4afe96e-fb2a-4ebe-bd17-1b9dd11b902a&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg>