Re: [openpgp] Packet lengths and padding
Andrew Gallagher <andrewg@andrewg.com> Tue, 27 June 2023 16:38 UTC
Return-Path: <andrewg@andrewg.com>
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 C92AFC151096 for <openpgp@ietfa.amsl.com>; Tue, 27 Jun 2023 09:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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=andrewg.com
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 AVxKNkfafVN6 for <openpgp@ietfa.amsl.com>; Tue, 27 Jun 2023 09:38:40 -0700 (PDT)
Received: from fum.andrewg.com (fum.andrewg.com [135.181.198.78]) (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 8E4E1C151532 for <openpgp@ietf.org>; Tue, 27 Jun 2023 09:38:39 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:fc93:5820:7349:eda2:99a7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by fum.andrewg.com (Postfix) with ESMTPSA id 0995D5F392; Tue, 27 Jun 2023 16:38:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1687883917; bh=CfWIceYBtaIMb/UNzcVD8w29EnhjYax+5hXpd6qiI24=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=dhI20sXHT3dA2BWP+lZzib8o9zimfgd/u+KO0ky1IQZ6iEvYfX8troIhmI4HJGlYt o3s8fy9nRuA90PbKiEBownEQCYLEjbE99HTWhB7auwA1PPi2CjQRm0ibAok5UzzZ3l t7NvFN9BTBH292dkFybjdZYScoycrmEqZhr4juaCm2LczGBfLghB2x+XwaX/uig6wa a5N3pqS/JBAPV4ooA18U39w4VnVyuc7NawJUtUSS+FULN8tNl2/R9QNOn7ayVAKdIe YZh3y1MXwDVYtXZ5KDQAzpd4XzMel1t+Kp3Y5E6zV/ekq5rF6gzIz9YHkd8uaYS/VQ cOVkJmYAiSuBw==
Content-Type: multipart/signed; boundary="Apple-Mail=_7F0C2193-B409-46C6-A1A8-26DE26D65D40"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Andrew Gallagher <andrewg@andrewg.com>
In-Reply-To: <874jmskhzs.fsf@wheatstone.g10code.de>
Date: Tue, 27 Jun 2023 17:38:18 +0100
Cc: IETF OpenPGP WG <openpgp@ietf.org>
Message-Id: <BC727289-52E9-43F7-A34D-B2179B361FAB@andrewg.com>
References: <C67E6CEA-D6EF-44D9-8673-1D16A674E519@andrewg.com> <87leg5js2y.fsf@wheatstone.g10code.de> <D7446D68-35DE-4653-9404-180567968BE1@andrewg.com> <874jmskhzs.fsf@wheatstone.g10code.de>
To: Werner Koch <wk@gnupg.org>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/QYD_NH2JHRI5tb6oL-dM6GWyiQQ>
Subject: Re: [openpgp] Packet lengths and padding
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, 27 Jun 2023 16:38:44 -0000
On 27 Jun 2023, at 17:05, Werner Koch <wk@gnupg.org> wrote: > > On Tue, 27 Jun 2023 09:59, Andrew Gallagher said: > >> Do you mean packet tag 21, or non-standard length encodings? > > Yes, that padding packet from the new draft. Gotcha. Packet tag 21 is in the critical tag namespace, therefore implementations that don’t support it MUST reject the whole sequence. This seems an odd design choice, since padding packets MUST be ignored on receipt by definition. If they had been allocated in the non-critical tag namespace this behaviour would have been implicit, and (theoretically at least) backwards-compatible. I’m not convinced that rejecting sequences containing padding packets provides much increased protection against covert channels though, since anyone can append a tag-63 packet containing arbitrary data and implementations MUST ignore it (whether they actually do so is another matter!). And then there are fake timestamps, bit-fiddled images, unhashed signature subpackets... A
- [openpgp] Packet lengths and padding Andrew Gallagher
- Re: [openpgp] Packet lengths and padding Werner Koch
- Re: [openpgp] Packet lengths and padding Andrew Gallagher
- Re: [openpgp] Packet lengths and padding Justus Winter
- Re: [openpgp] Packet lengths and padding Werner Koch
- Re: [openpgp] Packet lengths and padding Bart Butler
- Re: [openpgp] Packet lengths and padding Andrew Gallagher
- Re: [openpgp] Packet lengths and padding Andrew Gallagher
- Re: [openpgp] Packet lengths and padding Andrew Gallagher
- Re: [openpgp] Packet lengths and padding Michael Richardson
- Re: [openpgp] Packet lengths and padding Andrew Gallagher
- Re: [openpgp] Packet lengths and padding Werner Koch
- Re: [openpgp] Packet lengths and padding Paul Wouters
- Re: [openpgp] Packet lengths and padding Daniel Huigens
- Re: [openpgp] Packet lengths and padding Andrew Gallagher
- Re: [openpgp] Packet lengths and padding Werner Koch