Re: [openpgp] Padding packets

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 20 June 2022 18:41 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 5E956C14CF0F for <openpgp@ietfa.amsl.com>; Mon, 20 Jun 2022 11:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.315
X-Spam-Level:
X-Spam-Status: No, score=-1.315 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_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=GCEtJvfn; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=A9F5tI+R
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 8K7QjIMki1W6 for <openpgp@ietfa.amsl.com>; Mon, 20 Jun 2022 11:41:10 -0700 (PDT)
Received: from che.mayfirst.org (unknown [162.247.75.117]) (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 D4D4CC159492 for <openpgp@ietf.org>; Mon, 20 Jun 2022 11:41:09 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1655750468; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=t2nlI7Q7J1poQSXLca0JSJJYy2ho9MeSjNCyJtTkjsM=; b=GCEtJvfnxVXyiz3FqxRrFGyJrOdKHiJzKUh75Wdb8fNwMDZMYVveqJptH2qVAqWOey6Bw gvvJ70qOrcfKhK5CA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1655750468; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=t2nlI7Q7J1poQSXLca0JSJJYy2ho9MeSjNCyJtTkjsM=; b=A9F5tI+R3FVgIQIqK4LGiRuMmCx8EUizSsgvtMynCNPX7ZntJWwQmdNwlhFvnLuzmi1O4 wBqCoVm4HrCCFc/Fcn3XP23TP2l8PjZPA3ZkFStCu8nOdnHlSunn+jvb/qMOI9FgXsWZih5 fslkYNKOiGKzjIjlUMzW0mCE+/V5uZ9ON5CqqSeYDTWMsklkQm6iGE5q0GCxtr1e+TlT/Qe xoggLts+eLQAnJ3tcb376n30x0+sbYMOdVb49jz1/tFm4F8cvcd9UsOG+77LXFMR95ZRaHV 1OB8zvnSGSWDuerHfUxRvVwpJUPNjiMR1hHNmS1tt6koyU9YywfZVFzINQNw==
Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D4CCCF9B0 for <openpgp@ietf.org>; Mon, 20 Jun 2022 14:41:07 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id B7316204E3; Mon, 20 Jun 2022 14:40:14 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: openpgp@ietf.org
In-Reply-To: <o17TAfJTeOZkYp5X-XwNQwnTrCaiKEGnn1ZAL1qLB5CTGKntjwv6dpCIah44pAdH8nHXa4ivte_MMtqXuKP3uhobW5kJk9E6rAEWneD11yA=@protonmail.com>
References: <87wndi88ri.fsf@wheatstone.g10code.de> <83cce07c67f67c19b06c0c4239b6f335512a9a6f.camel@16bits.net> <o17TAfJTeOZkYp5X-XwNQwnTrCaiKEGnn1ZAL1qLB5CTGKntjwv6dpCIah44pAdH8nHXa4ivte_MMtqXuKP3uhobW5kJk9E6rAEWneD11yA=@protonmail.com>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Mon, 20 Jun 2022 14:40:13 -0400
Message-ID: <87czf36uwi.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/rhONdxmTJ8vvZYphHpE7R7H27dU>
Subject: Re: [openpgp] Padding packets
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, 20 Jun 2022 18:41:14 -0000

On Fri 2022-06-17 12:52:50 +0000, Daniel Huigens wrote:

> I agree that deterministic incompressible data is better than random
> data in this context.
>
> I've created a merge request based on your and Brian's suggestion:
> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/203.
>
> Between the two, I went with AES-128-CTR as it seems more efficient to
> me than SHA-256, and should provide the properties we want.
>
> I went with an all-zero key instead of the hash of the previous packet,
> as I didn't see a need for binding the padding to the preceding packet,
> and always using the same (deterministic) padding seemed fine to me,
> however, let me know if you disagree or see a need for that.

I'm a little bit confused by how this proposed change interacts with
non-critical (but as-yet-unspecified) packets.

Currently, it looks like an implementation that doesn't want to use this
particular form of high-entropy data can squat on an unspecified
non-critical packet type, and reasonably expect implementations to
ignore it safely.  The result is that a hidden channel exists anyway.
(there are probably many many other ways to introduce hidden channels in
OpenPGP as well, but this is one obvious way -- non-critical notation
subpackets in a signature packets is another one, as is something based
on sequences of marker packets)

So afaict, the only functional change in this implementation is:

 - make it so that a padding packet might cause a rejection if both
   implementations don't agree on how it was calculated, and

 - risk multiple padding-packets being visible in the case of a
   compression routine wrapping the data (whether at the OpenPGP layer
   or outside of it.

With no hats on, these seem like strictly worse outcomes to me for
interoperability and for privacy.

If the specification wants to provide recommendations for structuring a
padding packet to demonstrate that no hidden channel exists while
avoiding the compression concern, i'd be fine with that.  for example,
it could recommend starting with 4 octets of randomness as a seed for a
deterministic algorithm, encouraging those 4 octets as being derived
from the digest of the previous packet, and storing those 4 octets
directly in the start of the padding packet.  Then, some implementation
that has good reason to object to a risk of a hidden channel could
determine (a) that the seed was correctly calculated, and (b) that the
rest of the padding packet is derived from the seed.  Such an
implementation could produce a warning that mysterious data is present,
if either of those checks failed.

But mandating that *all* receiving implementations reject the entire
sequence if any padding packet doesn't have specific content strikes me
as preparing the ecosystem to deal with a lot of self-inflicted wounds,
without much in the way of benefit.

   --dkg