Re: [openpgp] Message padding in OpenPGP

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 27 September 2019 14:15 UTC

Return-Path: <dkg@fifthhorseman.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 3A51B120043 for <openpgp@ietfa.amsl.com>; Fri, 27 Sep 2019 07:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=LmiqbNVS; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=OusbIq2n
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 m6K2kbHD_nQf for <openpgp@ietfa.amsl.com>; Fri, 27 Sep 2019 07:15:24 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78719120025 for <openpgp@ietf.org>; Fri, 27 Sep 2019 07:15:24 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1569593722; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=3nzI8a+Q6mnt7UWI4yRnFM5KlCGCjdaQY1uI/9g1TnE=; b=LmiqbNVShscUX8qHcYiNmeXvvFUNL1B0jV+GDyCuH2bHcYFaRxu3nXH+ kjyUs+RiGTzYDKuagdOC4SmF8OP3Cw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1569593722; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=3nzI8a+Q6mnt7UWI4yRnFM5KlCGCjdaQY1uI/9g1TnE=; b=OusbIq2nBk2dfC0NR6Epq/kTmrspQCP/yNpSfmxG1T0G1hkl4ZqCbZ1Q c/Jhli+XlHXhbv2xzyITMqLKBDmPUqCj+hchCi13iYmbh7gFxKUvWJGxax Cz1Whwd1azGofYTGszPdMAQEtEgG2fdqknDdtF8XdnjSFMsjsGKn7apWMd mLTo2StLFTRd6zk1qEsV56xkZGznM3ziiPji1TPrKKpmnGeTRJcpW8ikz0 uBLRwZTX3IStpPv1n6p6e8kHoGjdS7Fbi6QDktIjfDaiTNAFenLQ6TNUzj uq/qibsvk1OnaZbqvopHRjh9dbPA68LWKdKLu8j5AQIJpC9qsBUR5w==
Received: from fifthhorseman.net (dh207-60-218.xnet.hr [88.207.60.218]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 5D181F9A5; Fri, 27 Sep 2019 10:15:21 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id ACF6C205C9; Fri, 27 Sep 2019 16:15:14 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Derek Atkins <derek@ihtfp.com>, openpgp@ietf.org
In-Reply-To: <sjmtv8xhn0a.fsf@securerf.ihtfp.org>
References: <CA+t5QVsZoWEuDWEzGn+mWNsx+giJsq+9pYptt3TfffASBVoGsw@mail.gmail.com> <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> <CA+t5QVs7aoyBotbApmGQBGO9otLeB9knccAV8w9MacjrcE_51w@mail.gmail.com> <sjmblv8igzi.fsf@securerf.ihtfp.org> <CA+t5QVvBxvhrDLuXiy6uM93HEp5rtOhwb3yQYr=v9FNKodCnjg@mail.gmail.com> <sjmtv8xhn0a.fsf@securerf.ihtfp.org>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw==
Date: Fri, 27 Sep 2019 16:15:14 +0200
Message-ID: <87wodt25cd.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/AtJWVfs_xttiU2NfAEdoc3psk4M>
Subject: Re: [openpgp] Message padding in OpenPGP
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: Fri, 27 Sep 2019 14:15:26 -0000

On Fri 2019-09-27 09:44:37 -0400, Derek Atkins wrote:
> Neither is anything else you are currently proposing.

Are you certain about that?

It looks to me like Justus has proposed several different
implementations that meet the grammar specified in
https://tools.ietf.org/html/rfc4880#section-11.3, which is almost
exactly the same as the grammar from 19 years ago in
https://tools.ietf.org/html/rfc2440#section-10.2 (the only difference is
the introduction of the SEIPD in RFC 4880).

> If you're going to extend the spec to add a new packet type you might
> as well extend the spec to allow this, which is easier.  And honestly
> many parsers (at least the parser I wrote in 1995 which AFAIK is still
> in use by at least one implementation) will actually parse this
> structure properly.

We have a documented grammar that has held up for nearly two decades --
even if some parsers are more flexible/permissive than the grammar
itself, changing the grammar could invalidate any existing strict
parsers.  In a security-sensitive context, we know that strict parsers
are safer than permissive parsers (see for example https://efail.de).
Let's not discourage strict parsers.

If we want a backward-compatible padding mechanism (i think we do,
though i'm not sure it's appropriate to document it in 4880bis), then
changing the grammar itself should probably be pretty low on the list of
options.

        --dkg