Re: [openpgp] Session-Key-Reuse and Intended Recipient

Justus Winter <justus@sequoia-pgp.org> Tue, 06 June 2023 15:12 UTC

Return-Path: <justus@sequoia-pgp.org>
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 69399C151B26 for <openpgp@ietfa.amsl.com>; Tue, 6 Jun 2023 08:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.693
X-Spam-Level:
X-Spam-Status: No, score=-6.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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=neutral reason="invalid (public key: not available)" header.d=sequoia-pgp.org
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 TGCrya6BrD1U for <openpgp@ietfa.amsl.com>; Tue, 6 Jun 2023 08:12:20 -0700 (PDT)
Received: from harrington.uberspace.de (harrington.uberspace.de [185.26.156.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 F0671C1519B1 for <openpgp@ietf.org>; Tue, 6 Jun 2023 08:12:18 -0700 (PDT)
Received: (qmail 20062 invoked by uid 500); 6 Jun 2023 15:12:15 -0000
Authentication-Results: harrington.uberspace.de; auth=pass (plain)
From: Justus Winter <justus@sequoia-pgp.org>
To: Kai Engert <kaie@kuix.de>, "openpgp@ietf.org" <openpgp@ietf.org>
In-Reply-To: <77d8aee8-19b2-ef0d-f49d-5e9c7cd1e44f@kuix.de>
References: <77d8aee8-19b2-ef0d-f49d-5e9c7cd1e44f@kuix.de>
Date: Tue, 06 Jun 2023 17:12:14 +0200
Message-ID: <87y1kw62wh.fsf@europ.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Rspamd-Bar: ----
X-Rspamd-Report: MIME_GOOD(-0.2) SIGNED_PGP(-2) BAYES_HAM(-2.137237)
X-Rspamd-Score: -4.337237
Received: from unknown (HELO unkown) (::1) by harrington.uberspace.de (Haraka/3.0.1) with ESMTPSA; Tue, 06 Jun 2023 17:12:15 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sequoia-pgp.org; s=uberspace; h=from; bh=3zjITy1qfzrN7YzZUVsGP/zHeBj8lTJlKWGDxDXYAK4=; b=F34JoRFibPg23ranKeM40A1o53B5hCSIA019bC6kqnvoY+MDHTxTFVCvE85wEj5zqTnsuOGW8G SeapBfyHYjheEwQuZpI11av577kQBk378BRnAiRjDXiZevB5FUvvms/bBoW8jmk3KTmO0C+BdbGs HRR/oMcMfw/+q3qYdHNKQggP2hsYsqWOagIiM08XZduuELuHSulJQIr11rpnhUyf5ZcfgHd0sNZs 6LyKcUWtBUYkpZxzXmRgEjetGryI3aJbpwqjuUM3NBqplDeARH6175HjodPDlfDwJ4MZSvIhgdV3 1G6stcgjJvufl9/6tH4NKOdkj0UFnRU74zQtlWL1jjE88nfBqL+GuWVkKnZ15gtV4swZ5dnUJEbn GEDr53NPqATdU0dPUOKjFbMibxmkFJSfPIAf6BBMWGNbU3d/eCX5/sNPrCASzXEWiAl2OgtTcxVw PU0rJMM90k8NRWEshyF5y2VT69eIOc5Xze9DLii7l9T5yTzKx6zS/WwlwZgwpV+t/PKF6rjDgJnD dMTIECFeNhf/BAW3ZFdAuTOSJm/IepMOT2oYTQvp4yYnXGaiNwKFYmm7Cd7PHH8PzGxcfJiYwYhp 7bEojFvHCX0e/cT506nThd8ENoitemBdA94vn+HVJbPzWYt7n3mh1GWZ97sr9VSQGS0BuKFBHBhM k=
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/sgVRiWLqHo5ykxyW36Y56EnJ-H4>
Subject: Re: [openpgp] Session-Key-Reuse and Intended Recipient
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: Tue, 06 Jun 2023 15:12:25 -0000

Kai Engert <kaie@kuix.de> writes:

> At the recent OpenPGP for email summit [1], we had a session in which we
> discussed the practicality of the Intended Recipient Subpackage (IRS)
> for PGP/MIME email. It was mentioned that it's recommended to use
> protected headers in such messages. With that, the intended recipients
> are already known. Having equivalent information twice, e.g. both
> protected headers with the TO/CC fields, plus IRS, might be
> unnecessarily complex, and MUA implementations might prefer to avoid the
> IRS.
>
> Based on that, would it make sense to make the following two changes to
> the crypto-refresh document, in the places that mention IRS ?

Your first change refines a SHOULD, the second refines a recommendation.
So in both cases, implementations can do what you want (not use/ignore
the intended recipient subpacket) while being in compliance with the
document as it is now.

In the interest of not delaying the standardization process further, I
would very much prefer you rescind your suggestion.

Best,
Justus