Re: [openpgp] Disadvantages of Salted Signatures

Stephan Verbücheln <verbuecheln@posteo.de> Mon, 11 December 2023 17:40 UTC

Return-Path: <verbuecheln@posteo.de>
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 38F6CC14F60E for <openpgp@ietfa.amsl.com>; Mon, 11 Dec 2023 09:40:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=posteo.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xFHbrO7paKZ for <openpgp@ietfa.amsl.com>; Mon, 11 Dec 2023 09:40:20 -0800 (PST)
Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA5CC14CF17 for <openpgp@ietf.org>; Mon, 11 Dec 2023 09:39:39 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id CE965240028 for <openpgp@ietf.org>; Mon, 11 Dec 2023 18:39:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1702316377; bh=hSPW2aF4ThqmK0H7PE9XfEkDDvHYM0kD1tIcxoSWH7o=; h=Message-ID:Subject:From:To:Date:MIME-Version:From; b=chYrMdJECoUNBI9e01NyATIWTqfiWslIgZJKPiEJOikdGb8zDnW9Tt+iFWlAvYv+A fmyRjgzthlyiM6MnSvy4N3mgI0+AeBr+KvPVGfJYozOE9uusTOfELTQf74+IJCTbIf mh240Z47xSFUEp8ylwqJz1ZTRkwPb+ks1vYEH2oI0lwc2Ci/mKvl6TMmbyVo01iFj+ FUZIp8gdXJByHAdjsN06HWXcxNwkJO4H7opbctoX8Bpn/uIwC63zz9QByirCRpbi0U u4TCBLDf8Nd0Kj1x4IhfWMp7odqlIXYeDbVeowdaA9iLfB3zb56/WcpIEiJIPJqUFv H6Wa6j3YGT61g==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SppsP2LQkz9rxH for <openpgp@ietf.org>; Mon, 11 Dec 2023 18:39:37 +0100 (CET)
Message-ID: <38e1831d22960dd66cd5411622b75bbbba90fba3.camel@posteo.de>
From: Stephan Verbücheln <verbuecheln@posteo.de>
To: openpgp@ietf.org
Date: Mon, 11 Dec 2023 17:39:36 +0000
In-Reply-To: <EDD338F3-8942-45C2-B124-74156D66E036@andrewg.com>
References: <077dd27cef0c7d3968967fc4c3a880081b8bd9dd.camel@posteo.de> <8b5f251f-ae52-4937-9500-ddedb9fbef73@cs.tcd.ie> <709995498037ba59fb1a14d75ffa819702566d83.camel@posteo.de> <df7f0b41-f998-4f0e-b07e-67231031e54b@cs.tcd.ie> <a38abd9349683c1c0762daa8b203bc8578fc4853.camel@posteo.de> <EDD338F3-8942-45C2-B124-74156D66E036@andrewg.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-tDRQEK/7qYUkpKiOwTB4"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/e73FoHsO_hfGdqYFZz8XRJoPf3Q>
Subject: Re: [openpgp] Disadvantages of Salted Signatures
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 11 Dec 2023 17:40:24 -0000

Hi Andrew

On Mon, 2023-12-11 at 09:46 +0000, Andrew Gallagher wrote:
> I do not understand the stated interoperability issue. OpenPGP
> ensures interoperability with optional features by requiring the end
> user to advertise their ability to handle them using flags on their
> public key; without those flags other implementations MUST NOT use
> optional features in their correspondence. This has been the case for
> almost three decades now, and it has worked remarkably well.

There is not really such a thing as an “optional” feature. It is
optional for me to use it, but it is not really optional for a useful
PGP implementations to support it.
Interoperability is not just one person encrypting a message for
another person at a given time. PGP is more complicated. PGP keys are
used for a long time with multiple identities, subkeys etc. PGP-
encrypted data is stored even longer than the expiration of the keys.
When I want to read my decade old e-mail archive, I need my PGP
implementation to support every algorithm that any PGP implementation
from any device in my past has ever used.

> We lost that war twenty years ago. An entire generation has grown up
> for whom webmail == email. A small working group revising a niche
> (sorry, everyone!) standard is not going to make a dent in that.
> Given that end-user adoption of OpenPGP is voluntary, the default
> alternative to OpenPGP-enabled webmail is plaintext webmail. You need
> to meet people where they are.

Most people are not willing or able to do key management and that is
fine. They should better use one of the available end-to-end encrypted
messengers. PGP is for a niche indeed. But this niche matters a lot
more than people think.
PGP is used by security researchers to encrypt bug reports. It is used
by developers to sign Git commits and release tarballs. It is used by
Debian and Co. to secure package repositories and software updates. It
is used from Apple to Debian to sign official announcements. It is used
by Debian folks to identify each other.
A lot of people depend on these ecosystems, even when they are not
using it themselves for their personal e-mail.

Regards
Stephan