IETF Logo Mail Archive

[openpgp] Backwards compatibility

Paul Wouters <paul@nohats.ca> Wed, 18 October 2023 13:01 UTC

Return-Path: <paul@nohats.ca>
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 35BA8C14CE4B for <openpgp@ietfa.amsl.com>; Wed, 18 Oct 2023 06:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.404
X-Spam-Level:
X-Spam-Status: No, score=-4.404 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_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 (1024-bit key) header.d=nohats.ca
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 TWQ1bNdQks1o for <openpgp@ietfa.amsl.com>; Wed, 18 Oct 2023 06:01:53 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 1343DC14CE40 for <openpgp@ietf.org>; Wed, 18 Oct 2023 06:01:52 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4S9WFp46k0z37f; Wed, 18 Oct 2023 15:01:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1697634110; bh=B5X2njn7Jfqpx/40eDQiU8At+RyweOgkuPdP+T6O96U=; h=From:Subject:Date:Cc:To; b=pJL5N8yJSC9G8ikYN3VkF7rAds7BICK1i2vW80uaMBIeXxg7PWE3QyT9xiZzpHodu Ec2bbTB4iGIMBadDCSpslhZttz2LMbYJkoHg9JLWlmVjjKRjVzg+2HuILxkNfp8I6/ Wlx/+0VnbvTgo/mwxsKfEKGuaOTacYoKzRfN8gdA=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id XCZJ19NVM52Y; Wed, 18 Oct 2023 15:01:49 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 18 Oct 2023 15:01:49 +0200 (CEST)
Received: from smtpclient.apple (unknown [193.110.157.208]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 926E31096F91; Wed, 18 Oct 2023 09:01:48 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Wed, 18 Oct 2023 09:00:17 -0400
Message-Id: <CBAF59DC-8F4E-4E1B-979B-6838D4F662E0@nohats.ca>
Cc: openpgp@ietf.org
To: Werner Koch <wk@gnupg.org>
X-Mailer: iPhone Mail (20C65)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/moMPKZj83kmr5x2Zd9uGGUqxIS8>
Subject: [openpgp] Backwards compatibility
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: Wed, 18 Oct 2023 13:01:57 -0000

> On Oct 18, 2023, at 04:10, Werner Koch <wk@gnupg.org> wrote:
> 
>  Willfully destroying
> backward compatibility

Can you explain in what way the document does this? It tries very hard not to touch older versions so that previously encrypted and signed data can still be validated and fresh communication between older version and newer version clients can still be done using the older version of the protocol.

The new v6 formats drop some dangerous old features but those will only apply to data generated in v6 format.

> and adding extra complexity is not what such deployments need.

But without some “added complexity” those deployments are vulnerable to various real world attacks. The document needed to address those and tried to do so with the least added complexity, discussing these issues at length with multiple vendors.

There is still an IETF Last Call and issues can be raised if we made an error. But you would need to describe the specific issues and the issue with the proposed solution in the document.

Paul

v2.23.0 | Report a Bug | By Email