Re: [openpgp] Message padding in OpenPGP

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 27 September 2019 10:43 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 7C791120800 for <openpgp@ietfa.amsl.com>; Fri, 27 Sep 2019 03:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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=9yCrWXeE; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=RGM/o+Wv
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 ImI7shCHqh73 for <openpgp@ietfa.amsl.com>; Fri, 27 Sep 2019 03:43:06 -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 1C8D612001E for <openpgp@ietf.org>; Fri, 27 Sep 2019 03:43:05 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1569580984; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=jKEeiA6Q1NScP3DVD0t7BjfOpDFLXXkgpK3dzrWocP0=; b=9yCrWXeEUMo2eyHGDznoOrQfA1J63nxjJEF1dmlSLJWDNwugl5IPR3YG DOGhe9H6GqLsc/vtjsGSTSXyKVnhCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1569580984; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=jKEeiA6Q1NScP3DVD0t7BjfOpDFLXXkgpK3dzrWocP0=; b=RGM/o+WvX0ni7D/qQN2gbdpCWqbNfaIMyt7e6GemtsrTzdqZl2SuBjav 2JH8FM1IAQWRK/zwvAfn3XH5fcU3IdWlRRm4E6qodN+a+qpfVmEmlNMWSq RrASVu+5FiKWbst9Uq9UQ3KeE63ZPZFFnX3IkpisSvnBecR0dkqmPVcDLq iafB//2VyCOFBf3/0ZUAXdxUfYYUgP0T3r4q5WzPh5In9uHt/Tn1akKkDD 5TRrCTlvcOh5xTQ+FzIO+lmkh4JXLhQEdNLki6y4ftY4XGG/LZaOKYqKAP 10aOxzhcj4vYSTST9Skpd9VtZjAqwZIFsy2QrGpXhEGzg+UoV8P+YA==
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 B69E0F9A5; Fri, 27 Sep 2019 06:43:03 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 1A6B4205C9; Fri, 27 Sep 2019 12:42:56 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Justus Winter <justuswinter@gmail.com>, openpgp@ietf.org
In-Reply-To: <74a4ed22-a2ba-73cf-f665-f720b7f18d7d@cs.tcd.ie>
References: <CA+t5QVsZoWEuDWEzGn+mWNsx+giJsq+9pYptt3TfffASBVoGsw@mail.gmail.com> <87lfua3b4b.fsf@fifthhorseman.net> <74a4ed22-a2ba-73cf-f665-f720b7f18d7d@cs.tcd.ie>
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 12:42:55 +0200
Message-ID: <87blv62f68.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/ADLZYfHAZaFR27tE2EcT6I0frvE>
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 10:43:08 -0000

On Fri 2019-09-27 01:41:55 +0100, Stephen Farrell wrote:
> On 27/09/2019 00:12, Daniel Kahn Gillmor wrote:
>> The ideal place to apply padding is at the application layer
>
> That's not clear to me. It may be true or it may not.
> (Perhaps that's just me being suspicious of terms like
> "ideal" though:-)
>
> As a (possible) counter-example, application layer code
> is perhaps not (yet) well positioned to deal with padding
> of both DNS and application layer traffic, all at once.

i agree with your concerns, Stephen, though maybe not the specific
wording.  :) I mean, DNS *is* application layer traffic, right?

But you're right, as we move toward multiplexed application layer
protocols within a standard encryption layer (e.g. DNS over HTTPS on the
same endpoint that is serving "normal" HTTPS traffic as well), the
padding designs needed to mitigate size-based traffic analysis require
some sort of systemic reasoning about the combination of the application
layers involved.

So maybe the better way to say this is that padding policy should be
designed and set based on the encryption layer's properties (and padding
capabilities) and the union of all the traffic that is expected to be
encapsulated by that layer.

       --dkg