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

Benjamin Kaduk <kaduk@mit.edu> Thu, 27 May 2021 23:24 UTC

Return-Path: <kaduk@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 15CF13A17F0 for <cfrg@ietfa.amsl.com>; Thu, 27 May 2021 16:24:07 -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 RMlQSTRmZNdc for <cfrg@ietfa.amsl.com>; Thu, 27 May 2021 16:24:03 -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 CB7573A17EC for <cfrg@irtf.org>; Thu, 27 May 2021 16:24:02 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14RNNs7G020467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 May 2021 19:23:59 -0400
Date: Thu, 27 May 2021 16:23:54 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian Smith <brian@briansmith.org>
Cc: Russ Housley <housley@vigilsec.com>, IRTF CFRG <cfrg@irtf.org>, Justin Richer <jricher@mit.edu>
Message-ID: <20210527232354.GY32395@kduck.mit.edu>
References: <1EED8807-C5C5-461F-BE60-34C44791849E@mit.edu> <1BF68544-CB14-4A60-88BB-4E80E2D9A094@vigilsec.com> <CAFewVt54d6NGEYOX6Tx=gMf+p9NqTVkb9VkRxr+VZL5eDSmhmA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFewVt54d6NGEYOX6Tx=gMf+p9NqTVkb9VkRxr+VZL5eDSmhmA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/YbD-bkeDvVNQKuQUxAmuazFGZPc>
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 23:24:07 -0000

On Thu, May 27, 2021 at 04:15:32PM -0700, Brian Smith wrote:
> Russ Housley <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.
> >
> 
> I recommend that you follow the example of TLS 1.3 [1], which is compatible
> with that recommendation in RFC 4055:
> 
>       RSASSA-PSS [RFC8017
> <https://datatracker.ietf.org/doc/html/rfc8017>] with mask generation
> function 1.  The digest
>       used in the mask generation function and the digest being signed
>       are both the corresponding hash algorithm as defined in [SHS
> <https://datatracker.ietf.org/doc/html/rfc8446#ref-SHS>].
>       The length of the Salt MUST be equal to the length of the digest
>       algorithm.  If the public key is carried in an X.509 certificate,
>       it MUST use the RSASSA-PSS OID [RFC5756
> <https://datatracker.ietf.org/doc/html/rfc5756>]. [...] The algorithm
> 
>       parameters MUST be DER encoded.  If the corresponding public key's
> 
>       parameters are present, then the parameters in the signature MUST
> 
>       be identical to those in the public key.
> 
> 
> Some crypto libraries (e.g. mine) only support this exact form of PSS
> signatures, both generating and verifying. I am not sure if the rationale
> for TLS 1.3's strictness is given anywhere, but it underwent significant
> discussion before the above strict form was agreed upon.
> 
> [1] https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

The sentiment that comes through in the TLS list archives is that PSS has a
lot of parameters and that means places for implementations to mess up if
they're allowed to vary freely.  If you nail down as part of the protocol
that there is only one way to do things, correct (and testable)
implementation is much easier.

-Ben