Re: [openpgp] Message padding in OpenPGP
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 26 September 2019 23:14 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 0C13C12000F for <openpgp@ietfa.amsl.com>; Thu, 26 Sep 2019 16:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=j6cpbevl; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=hB1UN721
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 S_DwFmlK3nOK for <openpgp@ietfa.amsl.com>; Thu, 26 Sep 2019 16:14:14 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A093512022C for <openpgp@ietf.org>; Thu, 26 Sep 2019 16:14:14 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1569539653; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=AAc+zZOiik6mK5WYgeTxIeH/I6RE8wsYUASB6kfnLcc=; b=j6cpbevlhQ4bs4sJYS3mAg3+WHS1/MjvbDCqJdYPfBTW7xbefggWW8R7 vLYz+/Fzjg+j1ls5wVdtVi+wyQR3BQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1569539653; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=AAc+zZOiik6mK5WYgeTxIeH/I6RE8wsYUASB6kfnLcc=; b=hB1UN721ti+1s8+KufSahXydtywEfV52mtLO2k5PuDx3z56oUqw1/Vhk UqJ3X54MNb3NGD+jYb5NnsbbanA0XU/5sycwrWGOCoPn6Qm7TeqvS2QldU dGtGtiRSofA3BZLbtjSSfn+EqffhtVsm9eDIewCJjYXH06mMhISBacxF/4 dj5uDNJHe7TgjlAz5XvezdAABEz8BwanOxfDOv4B2V4hEH4Dh3bKA1v0ud NtleCaVGbkOeAhGzYJtH5It4Sqnf2/zJU7N9yGMt0AiLWRByjeS4wFr1z9 MXhywX1NHiZeBexOn6omWsJFIs/jdytv+dmkypMksD2r/FTNHeVLyQ==
Received: from fifthhorseman.net (unknown [88.207.38.0]) (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 29B02F9A8; Thu, 26 Sep 2019 19:14:13 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 1A7352078C; Fri, 27 Sep 2019 01:12:53 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Justus Winter <justuswinter@gmail.com>, openpgp@ietf.org
In-Reply-To: <CA+t5QVsZoWEuDWEzGn+mWNsx+giJsq+9pYptt3TfffASBVoGsw@mail.gmail.com>
References: <CA+t5QVsZoWEuDWEzGn+mWNsx+giJsq+9pYptt3TfffASBVoGsw@mail.gmail.com>
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 01:12:52 +0200
Message-ID: <87lfua3b4b.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/UzGv5ih37-4Bl3SKCvEYJDCbcyU>
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: Thu, 26 Sep 2019 23:14:17 -0000
Hi Justus-- On Tue 2019-09-24 19:09:04 +0200, Justus Winter wrote: > To reduce the amount of information leaked via the message length (see > e.g. [0]), encrypted OpenPGP messages should include decoy traffic. > > 0: https://mailarchive.ietf.org/arch/msg/openpgp/rG-X9rp2jlbyACoosnbxRXjCeys Thanks for this thoughtful analysis of different padding mechanisms for OpenPGP encrypted packets. I note that deciding on a padding mechanism ("how do i pad?") at the OpenPGP layer is not the same as deciding on a padding policy ("how much do i pad in a given circumstance?") We've been having increased dicsussion around the IETF about traffic analysis, and from what i've seen the general consensus (e.g. in TLS and DPRIVE) has been: * Size-based traffic analysis is a potentially serious threat to some applications that rely on encrypted traffic. Responsible protocol designers need to consider countermeasures. * The ideal place to apply padding is at the application layer -- or even higher in the stack -- because the upper layers are closest to understanding the typical size characteristics of messages that they emit and receive, and the risks of size-based traffic analysis at those layers. * Some application layer traffic is fairly ossified (the cleartext structures cannot be modified without significant cost), and has no native mechanism to safely pad. And the encryption protocols themselves sometimes leak sizing data in unfortunate ways. So a responsible encryption mechanism that might be used to encapsulate different application-layer traffic, or have its own size-based leakage should include a well-understood padding mechanism. That way, an ossified application layer can exercise the encryption layer's padding scheme to defend against traffic analysis without touching the application data. * Designing a padding policy is likely better done independently from designing a padding mechanism. As long as the padding mechanism is available, then the application layers can declare their preferred padding schemes. * The preferred padding policy for a given application layer may change over time as the use of the protocol changes. Having it designated separately allows adjustment of the policy without having to fiddle with the mechanism. Given the above, i agree with you that the OpenPGP specification should explicitly warn implementers and higher-layer users of OpenPGP to consider the risks of traffic analysis and encourage countermeasures that obscure the size of the cleartext. However, i don't think that the OpenPGP specification should declare a preferred padding *policy* -- that's best discussed in the context of an application that uses OpenPGP, and might well be different for different applications. I'm of two minds about declaring a standard padding *mechanism* for OpenPGP in the main specification itself. If there was one obvious mechanism for padding that was already in wide use, i'd say we should include it in 4880bis. But as there appear to be many possible mechanisms, and there may be subtle tradeoffs between different mechanisms, and 4880bis is already long overdue, i'd recommend documenting a preferred padding mechanism (without trying to impose a preferred padding policy) in a separate draft, including a bit more justification about why this scheme is preferable to the other possibilities. As for your current proposal (using a compressed packet as padding), i'm concerned about the interaction between features -- does it mean that if the recipient has marked their OpenPGP certificate as unable/unwilling to use decompression, that they cannot receive padded messages? Is there a way to mark padding explicitly as padding so that a clever implementation doesn't need to exercise any decompression code just to throw away the padding packet? Would you be interested in writing a more narrowly-scoped merge request for 4880bis that directs application layers that use OpenPGP to consider the risks of size-based traffic analysis, and apply padding-based countermeasures where possible? --dkg
- [openpgp] Message padding in OpenPGP Justus Winter
- Re: [openpgp] Message padding in OpenPGP Ryan Carboni
- Re: [openpgp] Message padding in OpenPGP Heiko Stamer
- Re: [openpgp] Message padding in OpenPGP Jon Callas
- Re: [openpgp] Message padding in OpenPGP Justus Winter
- Re: [openpgp] Message padding in OpenPGP Derek Atkins
- Re: [openpgp] Message padding in OpenPGP Jon Callas
- Re: [openpgp] Message padding in OpenPGP vedaal
- Re: [openpgp] Message padding in OpenPGP Justus Winter
- Re: [openpgp] Message padding in OpenPGP Daniel Kahn Gillmor
- Re: [openpgp] Message padding in OpenPGP Stephen Farrell
- Re: [openpgp] Message padding in OpenPGP Daniel Kahn Gillmor
- Re: [openpgp] Message padding in OpenPGP Stephen Farrell
- Re: [openpgp] Message padding in OpenPGP Derek Atkins
- Re: [openpgp] Message padding in OpenPGP Justus Winter
- Re: [openpgp] Message padding in OpenPGP Daniel Kahn Gillmor