From nobody Fri May 28 23:59:39 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 0311C3A07F5 for ; Fri, 28 May 2021 23:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ylCvSCrYSv0y for ; Fri, 28 May 2021 23:59:33 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB303A07F4 for ; Fri, 28 May 2021 23:59:33 -0700 (PDT) Received: by mail-wr1-x434.google.com 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; d=gmail.com; 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; d=1e100.net; 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 [10.0.0.5] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id m7sm10622055wrv.35.2021.05.28.23.59.29 (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: <05F41524-47A1-4E19-AD78-291DEA921618@gmail.com> 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-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: Sat, 29 May 2021 06:59:38 -0000 --Apple-Mail-BEF43801-9375-4422-911A-DA9E15627975 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 28 May 2021, at 15:45, Justin Richer wrote: >=20 > =EF=BB=BFOn May 28, 2021, at 9:05 AM, Salz, Rich wrote:= >>=20 >> Perhaps reconsider PSS. https://www.metzdowd.com/pipermail/cryptography/= 2019-November/035449.html is excellent reading. >>=20 >=20 > I appreciate the reference, thank you for that. It=E2=80=99s enlightening,= but something to note: We aren=E2=80=99t :just: defining RSA-PSS, we=E2=80=99= re also defining a flavor of RSA 1.5, a flavor of HMAC, and a flavor of ECDS= A, 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 ex= pensive for short messages. Although that cost is pushed out to the client, w= hich is preferable, if that client is sending a lot of small API requests th= is can be a very large overhead.=20 I have some serious reservations about the use of signatures for this use ca= se at all. There is no privacy considerations section in the draft, but sure= ly making user=E2=80=99s HTTP requests signed has serious implications for t= heir 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 =E2=80=9Cend-to-end integrity and a= uthenticity=E2=80=9D then IMO a MAC is more appropriate than a signature (wh= ich provides much stronger properties), perhaps in combination with an authe= nticated KEM like HPKE [2]. [1]: https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-pu= blish-your-dkim-secret-keys/=20 [2]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke#section-5.1.= 3 =E2=80=94 Neil= --Apple-Mail-BEF43801-9375-4422-911A-DA9E15627975 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 28 May 2021, at 15:45, Justin Richer <jrich= er@mit.edu> wrote:

=EF=BB=BFOn May 28, 2021, at 9:05 AM, Salz, Rich <rs= alz@akamai.com> wrote:
<= br>
Perhaps reconsider PSS. &nbs= p;https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html i= s excellent reading.
=

I appreciate the reference, t= hank you for that. It=E2=80=99s enlightening, but something to note: We aren= =E2=80=99t :just: defining RSA-PSS, we=E2=80=99re also defining a flavor of R= SA 1.5, a flavor of HMAC, and a flavor of ECDSA, each with fixed parameters i= ncluding sizes and curves and the like.

<= /div>
No EdDSA? RSA signatures are not very performant for this kind of s= ign-once-verify-once use-case, because the signing operation is comparativel= y 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 r= equests this can be a very large overhead. 

I h= ave some serious reservations about the use of signatures for this use case a= t all. There is no privacy considerations section in the draft, but surely m= aking user=E2=80=99s HTTP requests signed has serious implications for their= privacy? Especially if the signing key may be unique to an individual. I th= ink this will have similar privacy issues as DKIM [1].

<= div>If the intent of the draft is to provide =E2=80=9Cend-to-end integrity a= nd authenticity=E2=80=9D then IMO a MAC is more appropriate than a signature= (which provides much stronger properties), perhaps in combination with an a= uthenticated KEM like HPKE [2].



=E2=80=94 Neil
= --Apple-Mail-BEF43801-9375-4422-911A-DA9E15627975--