Re: [openpgp] RSA-PSS and RSA-OAEP for v5

"brian m. carlson" <sandals@crustytoothpaste.net> Sun, 28 February 2021 19:26 UTC

Return-Path: <sandals@crustytoothpaste.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ADC3A1B30 for <openpgp@ietfa.amsl.com>; Sun, 28 Feb 2021 11:26:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.199
X-Spam-Level:
X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, 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 (3072-bit key) header.d=crustytoothpaste.net
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 e_ROBaxPuxhL for <openpgp@ietfa.amsl.com>; Sun, 28 Feb 2021 11:26:38 -0800 (PST)
Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6AB3A1B2F for <openpgp@ietf.org>; Sun, 28 Feb 2021 11:26:37 -0800 (PST)
Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 8A39D60DF4 for <openpgp@ietf.org>; Sun, 28 Feb 2021 19:26:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614540396; bh=2XXsHJAMtRAdM0pXDqGSL+83aI3+AYxjIgPP67m1Rf4=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=kZQrB4WKApBcb4lM6cDQNS8hT6EBtOh5a+bxYc9sFgI8o0YAb36I+bbgq1B8EZ9dh iQ9pPJeVkd2zSNfrjLwDOjWXpOV7waHA+DQIX3Ooc0OPedw+T9RbuzqrCfXCREQZK1 oZIj9ywaJ2N7seG2PeNL2wt4sLRM5SY9O9fBoibQaKgSe+M3ar7yV9ebXOoi5u84ha 2IbFCVkv5arGjQZnXhKY2uKlMakebrgyrGOTTh0r4aBtTG/20iGG06czfyDevFpWkl J8gUIB0xHWoUK+tX/Z50/tbFbBcPczXvY5R0OqzAhBXO+kc90vk0KIhkSPfzZ7NQUO 9SfRSip5Sv33vHH6CCGBFoXqXNZbYz+0XDUykekS5LYW9G9cS1r/n9OekthBj690ET SndKglpmfv23YwGoGZLIlS4ZIFzcqtLM+yMx0W1G/5rGGvSiBOznv8hycSi2NdNgva S6AUhjliSVqD/S+0XHpR4ZgSCurGaG71vEy6d0GIWZe4plSX869
Date: Sun, 28 Feb 2021 19:26:32 +0000
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: openpgp@ietf.org
Message-ID: <YDvuaAXgwEDffYbt@camp.crustytoothpaste.net>
References: <YDrbaRiQ34MstP30@camp.crustytoothpaste.net> <87ft1g9goo.fsf@wheatstone.g10code.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="XG0ThXIv5p7QDXhD"
Content-Disposition: inline
In-Reply-To: <87ft1g9goo.fsf@wheatstone.g10code.de>
User-Agent: Mutt/2.0.5 (2021-01-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/o-AGzUOJERx1uERni1VkTEl1LLs>
Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Feb 2021 19:26:39 -0000

On 2021-02-28 at 18:43:19, Werner Koch wrote:
> On Sat, 27 Feb 2021 23:53, brian m. carlson said:
> 
> > I'm interested in seeing if we can require v5 SKESK packets with RSA use
> > RSA-OAEP with SHA-256 and MGF1-SHA-256 and require that v5 signatures
> 
> That would add a lot of additional complexity for no good reason because
> RSA will over short or long anyway be replaces by 25519 and 448.

I believe that the current plan was to make RSA must-implement, but
maybe I'm misremembering.  If we instead made EdDSA, ECDH, and
Curve25519 must-implement and RSA optional, then this becomes clearly
less important.

If we continue to suggest in any way that people use RSA keys, then we
need to consider this.  If we make RSA keys completely optional, then
it's probably fine to just omit this.

> > I realize this requires implementers to add additional code, but I think
> > the increase in security is worth it given the number of CVEs we've seen
> > for padding vulnerabilities.  We can tell implementers to avoid this
> 
> and replace them with bugs in the way more complext PSS and OAEP.

I'm not sure how these wouldn't be a problem anyway given crypto
libraries already implement them.  Presumably such bugs would have
already surfaced in their existing usage and interoperability.  For
example, any crypto library used by TLS 1.3 almost certainly implements
RSA-PSS correctly because otherwise it wouldn't interoperate, since all
RSA signatures in CertificateVerify use PSS.  S/MIME already supports
RSA-OAEP, so presumably that's already correctly implemented as well.

Are you suggesting that existing implementations have other latent
interoperability bugs that aren't exercised by TLS and S/MIME?  Or that
there's something special about OpenPGP that makes it more likely to be
a problem here?  Or that implementers are likely to avoid using
well-known existing cryptographic implementations in favor of their own?

> I see no reason for it and doubt that this can be viewed as part of the
> WG's old and new charter.

The charter specifies this:

- Revision of mandatory-to-implement algorithm selection and deprecation
of weak algorithms

I think it's very clear, based on a history of CVEs, that as practically
implemented, PKCS #1 padding is weak compared to PSS and OAEP.  We
should specify padding algorithms that are not weak as part of MUST and
SHOULD algorithms.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US