From nobody Sun Sep 1 04:51:52 2019 Return-Path: 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 59524120046 for ; Sun, 1 Sep 2019 04:51:51 -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=u45o38B4; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Qc1a4+k4 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 DSO0lwTRhX5p for ; Sun, 1 Sep 2019 04:51:49 -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 8BAB6120020 for ; Sun, 1 Sep 2019 04:51:49 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1567338708; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=sJv8tuUhgeAcZaQZAMnINmDqLzQQsSXOU52hDZOWJto=; b=u45o38B4A1JkA6Ls9lnyfdVWHCjVRvcyYVh+5RW7pOQo8i993vIXKs5r qnCGmq8MuUw6BEtYhYgBu9YWPvUbDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1567338708; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=sJv8tuUhgeAcZaQZAMnINmDqLzQQsSXOU52hDZOWJto=; b=Qc1a4+k4iSPxN865rL6NLWK2zLta6bxX9Ryjb8+YRn/GBKgjUHz2c1Jd L96k4TkBpOcXAMOGBHlrngl6CX4AaxeIUtW5CphMU4l6/Hzws3f5AxNe2f WaD/AmJ9SYMQd3UvbrINJn4G/CNXWnhs3IrvKuWZCh6C/O+vPpyKyFXjxY JBCHiWFW901KBky7Jys3Pr4qW1d2UheaoCqfawzkyT3sa2zx4xJTN1MQpt 0Xa5SD7Gbf5m91V8W1E6QvOVCsX3Gn0AeU0S/GC4uXrY0/UZhqtwwgS3U0 T7y9RKnygtmvheD8b2/yuCuR04BH10YCkoDdwWl1JHPLSnc85B/jIw== Received: from fifthhorseman.net (unknown [98.11.149.101]) (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 0D24CF9A5; Sun, 1 Sep 2019 07:51:47 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id BBD5720303; Sun, 1 Sep 2019 07:47:39 -0400 (EDT) From: Daniel Kahn Gillmor To: Werner Koch Cc: openpgp@ietf.org, =?utf-8?Q?=C3=81ngel?= In-Reply-To: <87imqe8rzm.fsf@fifthhorseman.net> References: <87tva1am9t.fsf@fifthhorseman.net> <87blw94tfg.fsf@wheatstone.g10code.de> <87h860ag31.fsf@fifthhorseman.net> <8736hjaovv.fsf@fifthhorseman.net> <1567132742.1695.16.camel@16bits.net> <87lfvb8c8z.fsf@fifthhorseman.net> <87ef13xgb2.fsf@wheatstone.g10code.de> <87imqe8rzm.fsf@fifthhorseman.net> 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: Sun, 01 Sep 2019 07:47:39 -0400 Message-ID: <877e6s8ch0.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2019 11:51:52 -0000 --=-=-= Content-Type: text/plain On Fri 2019-08-30 13:47:57 -0400, Daniel Kahn Gillmor wrote: > If you're generally ok with the protocol mechanism for attestations > proposed here, i'd be happy to share my notes for what i think a initial > interface for managing attestations with GnuPG might look like -- i can > do that on https://dev.gnupg.org/, or on gnupg-devel@gnupg.org, wherever > you prefer. I've made some suggestions over on https://dev.gnupg.org/T4694, and followed up on gnupg-devel as well. happy to get feedback on the suggestions! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWuv2wAKCRB2GBllKa5f +MmsAP9gj6IJDQ6lnYbcXSPE8dd9PxusnCxVXc+oWYCcGFz7oQD/dCvZua8qa5no b22H8c9RGn87nZl4bL/CnOhvHto7uwM= =BowO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 2 02:00:49 2019 Return-Path: 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 9DAC212011D for ; Mon, 2 Sep 2019 02:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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] 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=u6pKgb/+; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=GK09uPIa 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 tZHfjt7UhwD6 for ; Mon, 2 Sep 2019 02:00:46 -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 E358512011C for ; Mon, 2 Sep 2019 02:00:45 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1567414845; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OfO0tCIjXvWce22kO3Us5lJv9m2ELixu3Ej81nPabQw=; b=u6pKgb/+AQnmnfHACntjqGuB7uy/jqC0A6mx/4hmo2+nBVCeyjroJKbp HdYEchQnyntZWFH9nXd4udO+PDujDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1567414844; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OfO0tCIjXvWce22kO3Us5lJv9m2ELixu3Ej81nPabQw=; b=GK09uPIaNNhw/NCVbFYJA2CZl0wTAzxBsDd1thRmx20e0pWLz794F9IY 8MOyifmK3TFG0ASVS82QoOTBRCvcF1ZrFnRIl+5W6ZOQUrq5GXs7gdU1p2 hGpg822DfNEKzBrBF5D3l+9fHIDglYDwLGlkSe/1Y7px5vc5E4AEe3HJEu jY0xfisZbEkNY2k8aw/K7SFYBg3XWO8LzTeBFIjTBtlJqYXX+XdkFVM5Ig rSpmZqTCpdpqpv2m5F/byqgHEnVEH3ZySUzukF2xw3CvNIG93V+eyMkZIl uBeyj/oFcrxWbC0S2oN1+bAQ9xkcfg2dvp6FkL4g8c/KSJNkhxqcwQ== Received: from fifthhorseman.net (unknown [79.140.208.123]) (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 6893BF9A5; Mon, 2 Sep 2019 05:00:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 554EF206CA; Sun, 1 Sep 2019 22:22:11 -0400 (EDT) From: Daniel Kahn Gillmor To: Benjamin Kaduk Cc: openpgp@ietf.org, Heiko Stamer In-Reply-To: <20190831060419.GV84368@kduck.mit.edu> References: <87tva1am9t.fsf@fifthhorseman.net> <20190831060419.GV84368@kduck.mit.edu> 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: Sun, 01 Sep 2019 22:22:10 -0400 Message-ID: <87o90377zh.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 09:00:48 -0000 --=-=-= Content-Type: text/plain Hi Ben-- On Sat 2019-08-31 01:04:19 -0500, Benjamin Kaduk wrote: > It looks like this is in an "IETF Review" registry; please please please > consider making a request for an RFC 7120 early allocation. > I know the risk is probably less of conflicting codepoint squatting in > openpgp than in TLS, but in TLS we managed to have *three* different > extensions squatting on the same codepoint, and it is pretty unpleasant to > resolve. Thanks for this heads-up. While i agree that an early allocation is a good idea, given the defunct state of the WG (which is my fault as much as anyone's), i don't know that we meet the guidelines for IANA early assignment. But your perspective and opinion on as security area AD is welcome -- if you think this is the right thing to do, i'm happy to try to facilitate it. Thus far, I've been trying to keep all proposed updates to rfc4880bis that affect registries/codespace filed in gitlab, where we can track them to try to avoid collisions: https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests The affected registries thus far outstanding that i'm aware of are: * Subpacket Type: - 35: Intended Recipient (https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/19) - 36: Designated Revoker (https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/18) - 37: Attested Certifications (https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20) * Signature Class: - 0x16: Attestation Key Signature (https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20) I think if we want to get them into an IANA pre-allocation, the next step is to have a new version of the Internet-Draft published where the relevant changes are merged, right? Of these three, it looks to me like "Intended Recipient" (MR 19) already has multiple interoperable implementations, and "Attested Certifications"+"Attestation Key Signature" (MR 20) appears to be relatively uncontroversial. "Designated Revoker" (MR 18) has raised the most objections on the list, perhaps in part because it explicitly deprecates the old "Revocation Key" subpacket. Perhaps we should make a new revision of rfc4880bis with MRs 19 and 20 merged, since the jury is still out on MR 19. Then we can use that as the basis for the IANA pre-allocation. Does that seem like a reasonable next step? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXWx80gAKCRB2GBllKa5f +OTtAP48UBD9h/FmEhXIoHMqv1mxekTUOMuRcxtEn0SOoDDqbwD+JNZcLQCJ6KOw gAjvmJiHGSO7nPEJGjbUifmjSog0RwQ= =e45B -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 5 09:49:17 2019 Return-Path: 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 760081200D7 for ; Thu, 5 Sep 2019 09:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 nPSsH911aed5 for ; Thu, 5 Sep 2019 09:49:13 -0700 (PDT) Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33012120018 for ; Thu, 5 Sep 2019 09:49:12 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 09F13A1059 for ; Thu, 5 Sep 2019 18:49:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id S95eJRHpWoBk for ; Thu, 5 Sep 2019 18:49:06 +0200 (CEST) To: "openpgp@ietf.org" From: Dominik Schuermann Autocrypt: addr=dominik@schuermann.eu; prefer-encrypt=mutual; keydata= xjMEXUsNEBYJKwYBBAHaRw8BAQdAcvZdfsvTZD7v4rq1Us0cu90XnQ/bvYInuY2OcgJXfQDN KkRvbWluaWsgU2Now7xybWFubiA8ZG9taW5pa0BzY2h1ZXJtYW5uLmV1PsKnBBMWCAA4FiEE KbMza0V4B/lHwerWTcbrVoIq6EYFAl1LDRACGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA IQkQTcbrVoIq6EYWIQQpszNrRXgH+UfB6tZNxutWgiroRlYqAQCQPF5ifJSsvaHhD4M67OY5 ZUHxF/1R+wbCS5B0dhLSVgEA5Zcqd09UQm9hpNUr4dJek3HrDzwRr83gfw8TwON2owTOOARd Sw0QEgorBgEEAZdVAQUBAQdAsD//Q5nexKUjqI6orIam8X1Anlup8NaLd9lLMcbzFUkDAQgH wo8EGBYIACAWIQQpszNrRXgH+UfB6tZNxutWgiroRgUCXUsNEAIbDAAhCRBNxutWgiroRhYh BCmzM2tFeAf5R8Hq1k3G61aCKuhGVNQBALXiFjDe6LFRixxd4rReZp7qy1NTol2M3r+PQpiQ eD9rAP0fNQsr4NDhkHUpOJX/W1b4U7vWVapxVLjk+/3WpoyJBA== Message-ID: <787b731e-35c9-eeb5-57c1-fc1eeb425e91@schuermann.eu> Date: Thu, 5 Sep 2019 18:49:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [openpgp] Automatic WKD deployment from git to Netlify X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 16:49:16 -0000 Hey, I was in need of a method for deploying keys to WKD that is easy to manage by multiple persons. So this is my simple script for doing this: https://github.com/cotechde/netlify-wkd - It uses Netlify as the publishing platform (free & Let's Encrypt) - Everyone who has access to the git can manage their PGP key(s). - Keys in the git repo are automatically published every time the repo changes by using a simple Python script that is called by Netlify on git push - It uses the openpgpkey subdomain described as the WKD advanced method - It sets the correct CORS and Content-Type header (https://github.com/cotechde/netlify-wkd/blob/master/netlify.toml) Cheers Dominik From nobody Fri Sep 6 00:55:15 2019 Return-Path: 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 C10C612006F for ; Fri, 6 Sep 2019 00:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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_HI=-5, 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=pass (1024-bit key) header.d=gnupg.org 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 M3SZO8T7-CHm for ; Fri, 6 Sep 2019 00:55:11 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6647112002E for ; Fri, 6 Sep 2019 00:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=O9F7z48S1aHRUsXjYSPyS8ddfD7HaJiSRPrJsY0f0NQ=; b=JRomNbJRRbdji8yqkKOsc9POJA uQhNrapUUhv/PrSoxFP9iFwCmYh04xVAVcjdEX4hfmi9LI1NuDB5DCTSgTG9qWu8qUEPE225Xx3Kd 8DchMhB7vOCwiCQhven7F7TIN6SyDkDUMhD6ubPVJ6k1Wof3Ji+2i8/a0YKU8lmdS4DU=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1i695J-0008QT-El for ; Fri, 06 Sep 2019 09:55:09 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1i6909-000242-It; Fri, 06 Sep 2019 09:49:49 +0200 From: Werner Koch To: Daniel Kahn Gillmor Cc: Benjamin Kaduk , Heiko Stamer , openpgp@ietf.org References: <87tva1am9t.fsf@fifthhorseman.net> <20190831060419.GV84368@kduck.mit.edu> <87o90377zh.fsf@fifthhorseman.net> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Daniel Kahn Gillmor , Benjamin Kaduk , Heiko Stamer , openpgp@ietf.org Date: Fri, 06 Sep 2019 09:49:43 +0200 In-Reply-To: <87o90377zh.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sun, 01 Sep 2019 22:22:10 -0400") Message-ID: <87o8zxq2y0.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Shots_fired_spy_FMD_lock_picking_president_radar_stakeout_DREC=Afgha"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 07:55:14 -0000 --=Shots_fired_spy_FMD_lock_picking_president_radar_stakeout_DREC=Afgha Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 1 Sep 2019 22:22, dkg@fifthhorseman.net said: > Of these three, it looks to me like "Intended Recipient" (MR 19) already > has multiple interoperable implementations, and "Attested > Certifications"+"Attestation Key Signature" (MR 20) appears to be > relatively uncontroversial. I have merged these two patches. > "Designated Revoker" (MR 18) has raised the most objections on the list, > perhaps in part because it explicitly deprecates the old "Revocation > Key" subpacket. I didn't stepped into the discussion but I do not see a reason for it. it adds so much complexity to this area and it seems to be out of scope of the original goal of that WG. In fact we already added more stuff than planned and long winding discussion about implementaion details led to the clsong of the WG. The attestation thing is really useful to keep current OpenPGP workflows alive. > Perhaps we should make a new revision of rfc4880bis with MRs 19 and 20 > merged, since the jury is still out on MR 19. Then we can use that as > the basis for the IANA pre-allocation. Does that seem like a reasonable > next step? Will do so. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Shots_fired_spy_FMD_lock_picking_president_radar_stakeout_DREC=Afgha Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXXIPlwAKCRD/gK6dHew1 jXzKAQDU5uJS+w3+XwqWy338E+k1h+QYnlVjtludwc158USJJQEA9Z1NEoicss1v MAdT/fiRkhlHqRtWcnMJmhTWxd3C5gY= =pYtH -----END PGP SIGNATURE----- --=Shots_fired_spy_FMD_lock_picking_president_radar_stakeout_DREC=Afgha-- From nobody Fri Sep 6 04:10:14 2019 Return-Path: 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 56B0E1200B5 for ; Fri, 6 Sep 2019 04:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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_HI=-5, 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=pass (1024-bit key) header.d=gnupg.org 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 YX_Sd2Qcl0Yf for ; Fri, 6 Sep 2019 04:10:11 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F47120099 for ; Fri, 6 Sep 2019 04:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GAAIMigcDItk4ZBoygk3iVFv9fVMfM+vMUCZ950R/3o=; b=c+DfxecHAp9VWi1VThAgRbNq+8 cK8ApIvRgH+hu+v3AXz1UQVF9AVaFcn6ZsLSyd3rWV0EnbhF4FhDAsCGgekEyfBAiNnZgDIvztYkE fHnX6yHRhIlCIs3Gq5dUPH6Nz+4598lyV5mjYIPA1s9mQZM2sBhes9riBkYao3y99Ys4=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1i6C80-0001fP-SE for ; Fri, 06 Sep 2019 13:10:08 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1i6C6t-0003Y1-Ei for ; Fri, 06 Sep 2019 13:08:59 +0200 From: Werner Koch To: openpgp@ietf.org Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: openpgp@ietf.org Date: Fri, 06 Sep 2019 13:08:59 +0200 Message-ID: <871rwtptpw.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [openpgp] [internet-drafts@ietf.org] New Version Notification for draft-ietf-openpgp-rfc4880bis-08.txt X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 11:10:13 -0000 From: internet-drafts@ietf.org Message-ID: <156776293313.21924.15852882982830110780.idtracker@ietfa.amsl.com> Date: Fri, 06 Sep 2019 02:42:13 -0700 A new version of I-D, draft-ietf-openpgp-rfc4880bis-08.txt has been successfully submitted by Werner Koch and posted to the IETF repository. Name: draft-ietf-openpgp-rfc4880bis Revision: 08 Title: OpenPGP Message Format Document date: 2019-09-06 Group: Individual Submission Pages: 128 URL: https://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc4880bis-08.txt Status: https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/ Htmlized: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-rfc4880bis-08 Abstract: { Work in progress to update the OpenPGP specification from RFC4880 } This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Sep 16 15:35:19 2019 Return-Path: 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 192FF12008F for ; Mon, 16 Sep 2019 15:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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, T_FILL_THIS_FORM_SHORT=0.01] 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=yk2n9t4k; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=lZ1o1cYN 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 gC3pKqFjyUVw for ; Mon, 16 Sep 2019 15:35:14 -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 1619312006D for ; Mon, 16 Sep 2019 15:35:13 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1568673312; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=Twwe5y1Tug5pb+qvji0C99U2anhLDMe0kumL1SIbq7c=; b=yk2n9t4kC6lTGGjh5uxyWNdXs/a6GaPYEH3P1fC3bXWi9hKcd7qATttV 71ngxY3AO4GKq7JNh9yTFQ9rw2GjDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1568673312; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=Twwe5y1Tug5pb+qvji0C99U2anhLDMe0kumL1SIbq7c=; b=lZ1o1cYNt88MdQvYOLhnVamjFDS7fytWWI12TuzfK/1WipcjAKHgBKXt vtkO8Bf+4XzDjtJHGQUki2BS6sCtu4OXxpOzXGE9xq3RaQNHMwwsj3GiOk AVtJCPSm1uz/U9qEJwuW1DH30EToTSzpX76w5W6k0XxMpgZx9dFWsq+9fr BxBW07rPV7jMLm1ucg8rgpj8xwA0oIquIsD0KQPqjLgJ8DnRzu41lq+sS4 37XGsfT6ZdBcXt2q0Ri69irwUptyzhOV4rL6qOoRmx88+9TqHy6tzsoOY6 4+uwkohAYfXxGdF8iBHJrk4ZrF3wJKk4fuBA2+5T27NY8xG5eF/JEg== Received: from fifthhorseman.net (unknown [38.109.115.130]) (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 7B748F9A7 for ; Mon, 16 Sep 2019 18:35:11 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9B1F92078C; Mon, 16 Sep 2019 18:35:08 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.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: Mon, 16 Sep 2019 18:35:07 -0400 Message-ID: <87woe7zx7o.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] User ID conventions (it's not really a RFC2822 name-addr) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 22:35:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hey OpenPGP folks-- I'd like to have a clearer undersatnding about the actual conventions for OpenPGP User IDs in the context of e-mail. The standards currently say that the convention is an RFC2822 "name-addr", but (as detailed below), that does not appear to be the actual convention in practice. While we're updating RFC 4880, we should fix the standards to reflect reality. There are two proposals at the end that i'd love feedback on. I prefer proposal 2. Claims about name-addr =2D--------------------- RFC 4880 says the following: 5.11. User ID Packet (Tag 13) A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on its content. The packet length in the header specifies the length of the User ID. RFC4880bis repeats the above, and adds: 5.13.2. User ID Attribute Subpacket [=E2=80=A6] A User ID Attribute subpacket, just like a User ID packet, consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on its content. For devices using OpenPGP for device certificates, it may just be the device identifier. The packet length in the header specifies the length of the User ID. Both of these references to rfc 2822 are problematic. Real user IDs don't look like this, and other implementations won't parse things this way either, so the implementers might be led astray by this documentation. User ID convention is not a name-addr =2D------------------------------------ Here are a few concrete reasons why the convention is not actually an RFC 2822 name-addr: a) name-addr in RFC 2822 is defined to be a US-ASCII field, potentially charset-switched with RFC 2047 extensions in at least the display-name part. But User IDs are native UTF-8. For example, compare the following strings: 1) Bj=C3=B6rn Bj=C3=B6rnson 2) Bj=3D?utf-8?q?=3DC3=3DB6?=3Drn Bj=3D?utf-8?q?=3DC3=3DB6?=3Drnson We expect User IDs to look like (1), even though (2) is technically an RFC 2822 mail-addr. We don't want people to generate user IDs like (2), and we don't want implementations to try to apply RFC 2047 decoding to the contents of a user ID packet to be able to display it. b) name-addr doesn't allow non-quoted internal commas or apostrophes, so the following common User ID patterns are not technically name-addrs either, though implementations generate them, and people use them just fine in the real world: 3) Acme Industries, Inc. 4) Michael O'Brian 5) Smith, John c) in RFC 2822, a is not the same as a "mailbox" -- a "mailbox" is either a "name-addr" (which contains an "addr-spec") or an "addr-spec" on its own. But we have many examples in flight today of user IDs that are just a raw "addr-spec" (without angle-brackets), and those tend to be accepted by many OpenPGP implementations: 6) mariag@example.org d) the "display-name" part of an RFC 2822 "name-addr" is a "phrase" (a series of "word"s, which are either "atom"s or "quoted-string"s). An "atom" cannot contain the "@" symbol, so the display-name cannot contain an unquoted @. However, due to infelicities in common interfaces, we also see a large number of user IDs that simply replicate the addr-spec as though it were the domain name. This is not a valid name-addr, but it is accepted by most OpenPGP implementations. For example: 7) joe@example.net These differences between RFC 2822's name-addr and the actual user IDs in use today suggest that the guidance that they are "by convention" a name-addr is a mistake, and a potentially damaging one at that. It's likely to cause implementers to do expensive implementations of the complex name-addr syntax, which they then have to make exceptions for when they encounter all the real-world counterexamples. At the same time, we don't want implementers to each have their own arbitrary deviations from the convention -- the more uniform we can make the convention, the more likely we'll be to have interoperability. Goals =2D---- AFAICT, there is one main, uncontroversial technical goal for an e-mail-focused OpenPGP implementation when dealing with user IDs: A) extract the addr-spec If the implementation can't figure out the addr-spec, they can't use the certificate to learn how to contact. and if the implementation can't index internally by addr-spec, then they can't find the appropriate certificate to use when trying to contact a given e-mail address. What we really want is for every implementation to do this in a robust and predictable way, including for all of the common non-mail-addr forms described above. Are there any other goals that people think this convention should cover? Some (possibly-contentious) additional goals: B) accepting UTF-8 addr-specs recent RFCs about internationalization accept non-ASCII characters in domain names and local-parts of the addr-spec: https://tools.ietf.org/html/rfc6530#section-10.1 https://tools.ietf.org/html/rfc6532#section-3.2 do we expect user agents to be able to extract addr-specs that look like: =D0=B8=D0=B2=D0=B0=D0=BD.=D1=81=D0=B5=D1=80=D0=B3=D0=B5=D0=B5=D0=B2= @=D0=BF=D1=80=D0=B8=D0=BC=D0=B5=D1=80.=D1=80=D1=84 D=C3=B6rte@S=C3=B6rensen.example.com (These examples are from https://en.m.wikipedia.org/wiki/International_email) C) accepting really unusual addr-specs: the addr-spec definition formally includes some really bizarre structures that (while probably in use on some legacy systems) are a really bad idea. For example, localparts that are wrapped in double-quotes but otherwise contain forbidden characters can be problematic: "Abc@def"@example.com "Fred Bloggs"@example.com It looks to me like RFC 5322 even allows CFWS in the local-part, ugh. Do we expect user agents to do anything sensible with these addresses? A non-goal (does anyone want this?): D) be able to distinguish the "comment" from the "name" in display-name: Despite several implementations appearing to distinguish "Comment" from "Name" in the display-part, it's not clear that anyone *does* anything with that information, so it's mainly clutter and confusion. On top of that, there are probably more useless comments than useful ones, so i'd be happy to let this misfeature die out. Proposal 1: unicode maybe-wrapped addr-spec =2D------------------------------------------ We can address goals A, B, and C with some sort of language that acknowledges reality if we accept the following: * addr-spec from RFC 5322 is augmented by the definitions in RFC 6532 section 3 * there is no structure that we care about in what we would have called the "display-name" part of the supposed name-addr. Then the user ID convention becomes (again, assuming atext as augmented by 6532 =C2=A73): pgp-uid-prefix-char =3D atext / specials pgp-uid-convention =3D addr-spec / *pgp-uid-prefix-char "<" addr-spec ">" Proposal 2: simplify, simplify =2D----------------------------- Proposal 1 is still pretty ugly due to the inherent complexities of addr-spec itself. We can simplify the formal addr-spec greatly if: - we don't allow CFWS or quoted-string in the local-part, and - we don't allow CFWS or domain-literal addresses in the domain, and - we drop all the obsolete variants ("obs-*" labels in RFC 5322 ABNF) CFWS is "comments and folding whitespace". Dropping comments is justified by the argument that comments can go elsewhere in the user ID. Folding-whitespace isn't necessary due to the structure of the user ID itself -- we're not in an e-mail message header. Dropping obsolete parts is justified because they're obsolete. Dropping quoted-string is justified because it's rarely used, and likely to break in reality. And dropping domain-literal parts is justified because no one delivers e-mail to raw IP addresses anyway. Note that yes, this will discard some legitimate (if odd) addresses (e.g. ones with CFWS or quoted-string), and it may fail to recognize some legacy (odd) user IDs (obs-* or domain-literal). But we're describing a convention here, not making a normative statement, and we can do much better than the convention we were describing earlier but pretty much every implementation fails to follow. Using the definitions in RFC 5322 and RFC 5234, as augmented by RFC 6532 section 3, we can implement this simplification like so: pgp-addr-spec =3D dot-atom-text "@" dot-atom-text =20=20=20=20 pgp-uid-prefix-char =3D atext / specials =20=20=20=20 pgp-uid-convention =3D pgp-addr-spec / *pgp-uid-prefix-char "<" pgp-addr-spec ">" Note that every pgp-addr-spec is by definition an addr-spec (though not all addr-specs are a pgp-addr-spec). I believe that proposal 2 is closer to what most implementations do today, and it handles goals A and B. I don't mind it failing at goal C because of how much simpler the matching rule is. Conclusion =2D--------- My preference is to replace the text about User ID conventions in RFC 4880bis with proposal 2, but i'd be open to hearing other suggestions if anyone has them. --dkg PS in researching other ways to solve this problem, i came up with an approach that relies on Unicode character properties, in particular Grapheme_Base and Grapheme_Extend as a way to exclude control chars and other non-printables. This is a more sophisticated/nuanced approach than the RFC 6532 ABNF extensions to atext. But specifying it requires a character class set subtraction operation (you want to subtract "<" and ">" and "@" and " " from the Grapheme_* classes), which isn't listed in IETF's ABNF definition in RFC 5324. And implementing it requires a toolkit capable of discerning and acting on Unicode properties (e.g. the python regex module from PyPi, but not the re module from python's stdlib). That's too bad, because 6532 =C2=A73 effectively makes things like U+200B ZERO WIDTH JOINER allowable within dot-atom-text, which is uncomfortable and weird. But other implementers reliant on 6532 might accept such a localpart anyway. These costs don't appear to be worth the minor gain compared to proposal 2, so i've stopped attempting to document that approach. If anyone wants to take a crack at it though, i'm happy to share my notes. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXYAOHAAKCRB2GBllKa5f +FuUAP9rA/FQm70gQccT7C5lPRCYLZA8aYMmo5IHvVJy2HhiqAEA7lqv6Cxykyh3 rC5ecKbFhYYElefHsdWnJwoY4RHi1w8= =PoVJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 16 18:44:04 2019 Return-Path: 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 A50161200D7 for ; Mon, 16 Sep 2019 18:44:02 -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=XVA+NS1T; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=ryr4E6zi 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 5gIefe8qnyAA for ; Mon, 16 Sep 2019 18:44:01 -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 64B13120026 for ; Mon, 16 Sep 2019 18:44:01 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1568684640; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=olu1JNME7KBfBnfTrHrtE+TOdjTfNE6X/HkkG7RpiIs=; b=XVA+NS1ThOQTW0Mkc05NQDMTgMkENsD0f9icbmlthRzMK82/yzl4dTzb 8kCm8+hkPY81UDTNp1KGyNCNBEsEAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1568684640; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=olu1JNME7KBfBnfTrHrtE+TOdjTfNE6X/HkkG7RpiIs=; b=ryr4E6ziBWAiowHgTuofu6qBM2owMpqRrI/pCI+nzUMAfn2mAW4NyU+T mxfMJqUjpBpxqUotlQnH2ZkvBz0yiZAU90aNLG+YYOUtp+tRyYvp5uAdMK 7+SW3QHowjbvaslWRuGl6A/w11j35MT2/sZtlXvQyPetLip2xXd1lB6lde zSWX46ZoSX6kwMXm4SVk8G/UD5U19B74Vdtq6w2TBZxRvzyllwtyVrgdzQ NThXWqnx3xUlyFE23B1TocCxxTBRamyKfBE4+6/XHhYE7VYQ+krxGtBkgE szZj0jOAfEP9QdeCusiuRUpgGzSNjGoRlzQCOalHq0ZOwMvFAutgXg== Received: from fifthhorseman.net (unknown [38.109.115.130]) (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 2EE6FF9A5 for ; Mon, 16 Sep 2019 21:44:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6919220373; Mon, 16 Sep 2019 21:43:55 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org In-Reply-To: <87woe7zx7o.fsf@fifthhorseman.net> References: <87woe7zx7o.fsf@fifthhorseman.net> 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: Mon, 16 Sep 2019 21:43:54 -0400 Message-ID: <87muf3zoh1.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] User ID conventions (it's not really a RFC2822 name-addr) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 01:44:03 -0000 --=-=-= Content-Type: text/plain As usual, when you try to implement something, you find the missing pieces. :P On Mon 2019-09-16 18:35:07 -0400, Daniel Kahn Gillmor wrote: > pgp-uid-prefix-char = atext / specials The above line appears in both proposals, but it contains a mistake. It should read instead: pgp-uid-prefix-char = atext / specials / SPACE The following python3 code implements proposal 2 using python's built-in re module (i have not tested it with python2, given python2's clunky unicode support). import re specials = r'[()<>\[\]:;@\\,."]' atext = "[-A-Za-z0-9!#$%&'*+/=?^_`{|}~\x80-\U0010ffff]" dot_atom_text = atext + r"+(?:\." + atext + "+)*" pgp_addr_spec = dot_atom_text + "@" + dot_atom_text pgp_uid_prefix_char = "(?:" + atext + "|" + specials + "| )" addr_spec_raw = "(?P" + pgp_addr_spec + ")" addr_spec_wrapped = pgp_uid_prefix_char + "*<(?P" + pgp_addr_spec + ")>" pgp_uid_convention = "^(?:" + addr_spec_raw + "|" + addr_spec_wrapped + ")$" pgp_uid_convention_re = re.compile(pgp_uid_convention, re.UNICODE) m = pgp_uid_convention_re.search(uid) If there's a resultant match object, then the pgp-addr-spec can be found in either m["addr_spec_raw"] or m["addr_spec_wrapped"], depending on whether there are angle-brackets involved or not. Note the atext definition is the extended form of atext. anyway, i hope this clarification is useful. --dkg PS if the above is useful, anyone should feel free to reuse any of the above code in any context under any license. If you do so, and you want to provide an attribution so that complaints can be directed properly, that's fine, but i have no need for credit if you don't want to bother. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXYA6WwAKCRB2GBllKa5f +HkTAPsGOTi0I5+34/ybnCB/KAqemczG5Y8hQnS6SZArpSHswwD/aEpY5HytQ+O+ HtS5FlUgnBLrNFBSaspOfltGTnjtTgQ= =VsRv -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 16 19:25:11 2019 Return-Path: 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 BA77F12085C for ; Mon, 16 Sep 2019 19:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JReZN4doRtyl for ; Mon, 16 Sep 2019 19:25:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CBE1207FC for ; Mon, 16 Sep 2019 19:25:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A795C3897C; Mon, 16 Sep 2019 22:23:21 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 67C92BAE; Mon, 16 Sep 2019 22:25:00 -0400 (EDT) From: Michael Richardson To: Daniel Kahn Gillmor cc: openpgp@ietf.org In-Reply-To: <87woe7zx7o.fsf@fifthhorseman.net> References: <87woe7zx7o.fsf@fifthhorseman.net> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] User ID conventions (it's not really a RFC2822 name-addr) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 02:25:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for all of this. Daniel Kahn Gillmor wrote: > Proposal 2: simplify, simplify > ------------------------------ I like it too. > I believe that proposal 2 is closer to what most implementations do > today, and it handles goals A and B. I don't mind it failing at goal > C because of how much simpler the matching rule is. Agreed. > PS in researching other ways to solve this problem, i came up with an > approach that relies on Unicode character properties, in particular > Grapheme_Base and Grapheme_Extend as a way to exclude control chars > and other non-printables. This is a more sophisticated/nuanced > approach than the RFC 6532 ABNF extensions to atext. But specifying > it requires a character class set subtraction operation (you want to > subtract "<" and ">" and "@" and " " from the Grapheme_* classes), > which isn't listed in IETF's ABNF definition in RFC 5324. And > implementing it requires a toolkit capable of discerning and acting > on Unicode properties (e.g. the python regex module from PyPi, but > not the re module from python's stdlib). That's too bad, because > 6532 =C2=A73 effectively makes things like U+200B ZERO WIDTH JOINER > allowable within dot-atom-text, which is uncomfortable and weird. > But other implementers reliant on 6532 might accept such a localpart > anyway. These costs don't appear to be worth the minor gain compared > to proposal 2, so i've stopped attempting to document that approach. > If anyone wants to take a crack at it though, i'm happy to share my > notes. Wow :-) =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2AQ/wACgkQgItw+93Q 3WXK0wf/TczX1O5mu75pwgf+sm7FarRcZMb1pKJgtn0Hl2YwfEZnQ77avyK8eKoS b1QONLWnqAi5VGaGwqj70dflOo0UyZtFhbqYx8H6HbAS6rBNU+UeNJHYGOh3S67d 7J/ljxwZq/lyaSnuelSY1kbpXa2D96jSEWvmRCcw9qbHbH9LtBuWRpzOv68ZC83O LufNm77MGnVGgaxOwtgEHPl6ENg1LeefT09znpKDNBCrQ+EsBh19GGKu79ydJZRu OssKK6SXYW130p1ZLiovfa/4198m05W2hDqio5GdqvJcKmYcMCBYstlYhB8PcGcE w/kMrBSuG0XZDuA6K68Zfz6I7BdpKw== =K4DG -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 19 11:10:03 2019 Return-Path: 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 D2305120914 for ; Thu, 19 Sep 2019 11:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 jHoRw74UVl5A for ; Thu, 19 Sep 2019 11:10:00 -0700 (PDT) Received: from mr85p00im-ztdg06021701.me.com (mr85p00im-ztdg06021701.me.com [17.58.23.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF2012090C for ; Thu, 19 Sep 2019 11:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1568916600; bh=qqomHgIly8warzbT62DPkjsGCS9dKyLqohOzP/2u6hg=; h=Content-Type:Subject:From:Date:Message-Id:To; b=WLsK0dvvR4F7DTjGQGksJITqwpGRuDaxSRmVhrm7CzBH3tNkfPCmPGLyXqQ1tJNNj 4LfStW3EjCRS3yb7cE8V/uGNXI2FffUlfzLX9CN7tEmPlEFESKByfs4gaLxrJ3+f8g G0GopO672f67xCZThgs8MDvePhoyMpLc14cWdH3Ka2nVv4ztJ2D4jidPy2H3LJGQgk KK5sLVQ0G3tSek2jIpVe3GBYQtwiX2O/IwfgaSIjT6fpFXvv5QJZ4qc/4Y8AB4kjkA KBOXbYf3/n5rtxA2gYStsQadXC6XJ22CCg+skT+mRYStDc0fIns8MXnvK94BVzoCVc l2jyr+RPtLG3w== Received: from [10.125.12.162] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-ztdg06021701.me.com (Postfix) with ESMTPSA id 24414A00C30; Thu, 19 Sep 2019 18:09:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Jon Callas In-Reply-To: <87woe7zx7o.fsf@fifthhorseman.net> Date: Thu, 19 Sep 2019 11:09:58 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3AC1C32D-E2DE-43A0-A35A-1E7420E77980@icloud.com> References: <87woe7zx7o.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=705 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909190152 Archived-At: Subject: Re: [openpgp] User ID conventions (it's not really a RFC2822 name-addr) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 18:10:02 -0000 > I'd like to have a clearer undersatnding about the actual conventions > for OpenPGP User IDs in the context of e-mail. The standards = currently > say that the convention is an RFC2822 "name-addr", but (as detailed > below), that does not appear to be the actual convention in practice. A simple place to start is that RFC 6531 seems to be the present = upgrade/replacement for RFC2822. There have been interim ones and I = didn't spend a lot of time sorting out details. Whatever the present = successor is, let's just call it R. >=20 > While we're updating RFC 4880, we should fix the standards to reflect > reality. There are two proposals at the end that i'd love feedback = on. > I prefer proposal 2. I think I do, too, with your addenda.=20 Rewinding to history and second if not first principles, the User ID = field is ideally free-form text. The most common free-form text is an = email address, and that's described by R, and I think your proposal 2. However, there are a lot of places where people have put human-readable = text in (e.g. "XYZ Group Release Signing Key") that doesn't have a = machine readable context at all. There have also been X.500 = Distinguished Names, Common Names, and so on put there. There have been = other outr=C3=A9 uses as well. As long as we don't end up with it being = *precisely* an email address, meaning that we outlaw just plan text, I = think it's fine. At one time, I really wanted User Attribute Packets (created for having = images as IDs), to have other types of structured data including email = addresses. The reasons for not doing it then (it's a pain, and who's = going to support it) apply today. It's still a good idea, though. If whatever you come up with precludes text with no machine meaning, I = think you hit the flip side of having a defined type of ID: there's lots = of things that already don't meet it, and people will just ignore what's = there because history. Operationally, I think that supporting Just Text merely means that if = the field fails parsing rules (like Proposal 2) then it's Just Text and = we're moving on. Jon From nobody Fri Sep 20 14:03:18 2019 Return-Path: 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 1DFDA120106 for ; Fri, 20 Sep 2019 14:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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] 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=CTxzDJtD; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=2m5ND4I0 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 ca-jJp88A6c1 for ; Fri, 20 Sep 2019 14:03:15 -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 B0450120077 for ; Fri, 20 Sep 2019 14:03:15 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1569013394; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=LcDR2/we6tYBEn49dY8MGo6spOhot8xnE7SVTUa5cAE=; b=CTxzDJtDWsGjLZlqkXplJnrnqSAHXbRR8IHAWncsBr7KAjl+aycoxP/H 5CoR+ob/Igj09APygaVl2i467za7BA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1569013394; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=LcDR2/we6tYBEn49dY8MGo6spOhot8xnE7SVTUa5cAE=; b=2m5ND4I0cVlR/2hqFrWBPMsbxH53I01Lm8qa0iSBXMXPJ8EL++apOMu9 uGItpdNqyejH/amkNEiSVydwXMFzgarbYwEDbeiM7GCXcldFB2vL2BfBE2 KazUpQU09bZ+X7picYZoz/2XkiKMxZTRE1t8CEnQYAFe9m4nNgHJQkFS3j gJz4XV05Tb9e10nm9SLgKNPuEP/AIwrG7OLYe1UR0hTgkwIJwWUsmYTkGw f3Dow4fZWEubc2EJr5RtL5rGkqPHqtgkc3AZeM/kiuoXZ/Gx/t8o3dVegC g2vbzB3IBNNxuuvWiwLnIxsiVeS03YoTEReFWOmLmdOy2I8bXZcTgg== Received: from fifthhorseman.net (unknown [38.109.115.130]) (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 8D53FF9A5; Fri, 20 Sep 2019 17:03:13 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 75F5620439; Fri, 20 Sep 2019 14:20:48 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org, Jon Callas In-Reply-To: <3AC1C32D-E2DE-43A0-A35A-1E7420E77980@icloud.com> References: <87woe7zx7o.fsf@fifthhorseman.net> <3AC1C32D-E2DE-43A0-A35A-1E7420E77980@icloud.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, 20 Sep 2019 14:20:48 -0400 Message-ID: <87impmomm7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] User ID conventions (it's not really a RFC2822 name-addr) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 21:03:17 -0000 --=-=-= Content-Type: text/plain On Thu 2019-09-19 11:09:58 -0700, Jon Callas wrote: > Operationally, I think that supporting Just Text merely means that if > the field fails parsing rules (like Proposal 2) then it's Just Text > and we're moving on. Yep, completely agreed. Nothing in my commentary in this thread is meant to change the fundamental nature of the User ID as a UTF-8 string at its core. The goal is simply to more realistically state what the common convention is for User IDs that are likely to be used in the e-mail context. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXYUYgAAKCRB2GBllKa5f +KlTAQCg8AJKYcnA00OR5yR0yY0zoPr4rh38/c8+vLO7IleREwD+L48/8u7hCmPf xlmCsswAISYCAnaVAduAIEpps0qmmAI= =ovk0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 24 10:09:21 2019 Return-Path: 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 2B1CC12086E for ; Tue, 24 Sep 2019 10:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=pass (2048-bit key) header.d=gmail.com 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 ZCtk-AUg_i-f for ; Tue, 24 Sep 2019 10:09:17 -0700 (PDT) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB0F12080D for ; Tue, 24 Sep 2019 10:09:16 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id t3so2492259edw.13 for ; Tue, 24 Sep 2019 10:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=x1/fsJ/Hx/hyiZA3q/gBgq5TbIw7hqr3MdO/wCsb4yQ=; b=AGh08ECUfJ3foZCSnvTFn2r6v8Hxx4WstoNnZicvU60KsHmKRFJKsQH9oekOv6LeKy FVk95SGlHDMhJcDGZ7LFwEFfdHOSaEJTIBrv9zlaoMpkDulBuVkHzbv+oeJb8nNiTBVk agYj59eeJ10gqK/jglHjWuQ8lBkRnyZXGtMWXiZwxUdEm4OALng42M70mZLP4INQBPvv b+Lhc/glCMikf9HtfuKvbo7z8OQHACh6LuGqKmd4iGjCBKlnvOHyeWRWa469mE5bw9C2 cPzsBuVZEpNEWqTCWD5invwodj12TDWicZHFvkeqltq9wh5SurqXVorx6lB5A3n5W6OO b+Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=x1/fsJ/Hx/hyiZA3q/gBgq5TbIw7hqr3MdO/wCsb4yQ=; b=TKWo2u6G/wShyHlLn9RTSydSn78XsM1xefTsrQCO9JrXNBZYAlGqkbgRx3Gcv9P1Jp ESrYk2NUdY6FoeExS0SXqGsIAjXCS169GaqzTPE+tT0kesSFUy0Z+YjqBPQZw3qZFmLP 1NVKT1R4HdqUQ1QZuiaUG8DSVQp8nALVch/qO6W8LnDaH7BoAbj9c8j6hAnzRA5xGv9N Al1cCHJOQ6HJizkNzcrxhjCUwE/PbBr5H5K4bafyJSsz4CDGyMlgdnyG1SuzjlwiA7uQ Ok4l/BUV0TCgG7JOe5Ya8JzqcItqIBJpJ0YaL/kI/YM/UFL/YT+2iKASKcx7Oyjxl026 yBtA== X-Gm-Message-State: APjAAAWsClLIKPi/ioQLOS0t4vkOgaacSZkqEWJzswh9J++Q0sjzPmTQ 3S7QX3oi3IPqNXFyPCBw3Lb8C8pr158r3zTO5aqALOQd X-Google-Smtp-Source: APXvYqwX50jsbWT8CBdJKveBamsqG4WctltVwgnYSLWzqbCdZmnPGieWIVpDCpqWaiHcfATgjWwdXPLqYbAQTXXfz+M= X-Received: by 2002:a17:906:4ad2:: with SMTP id u18mr3467690ejt.117.1569344955335; Tue, 24 Sep 2019 10:09:15 -0700 (PDT) MIME-Version: 1.0 From: Justus Winter Date: Tue, 24 Sep 2019 19:09:04 +0200 Message-ID: To: openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 17:09:20 -0000 Hello :) 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-X9rp2jlbyACoosnbxRXjCey= s There are a number of ways to add decoy traffic within the boundaries of the OpenPGP protocol, keeping an eye on backwards-compatibility with common implementations: - Add a decoy notation to a signature packet (up to about 60k) - Add a signature with a private algorithm and store the decoy traffic in the MPIs (up to 4 GB) - Use a compression container and store the decoy traffic in a chunk that decompresses to the empty string (unlimited) - Use a bunch of marker packets, which are ignored (each packet: 3 bytes for the body, 5 bytes for the header) - Apparently, GnuPG understands a comment packet (tag: 61), which is not standardized (up to 64k) Out of these options, the compression container is a simple and flexible candidate, that also has very good expected compatibility. We are currently convinced that padding the compressed data stream is the best option, because as far as OpenPGP is concerned, it is completely transparent for the recipient (for example, no weird packets are inserted). Testing some OpenPGP implementations (Sequoia, OpenKeychain, GnuPG) revealed no problems. To be effective, the padding layer must be placed inside the encryption container. To increase compatibility, the padding layer must not be signed. That is to say, the message structure should be (encryption (padding ops literal signature)), the exact structure GnuPG emits by default. An example of such a message is: -----BEGIN PGP MESSAGE----- wV4Di9iOlMDSAzMSAQdALBAMZRuLecJf8LZvPIYhTrqmN6BLN5fEc8m7sPZAPSYw 6lm9Nmm9fo5ogkLknC4E+ME8S9v5lCJVAMZ30OXNX5is/uvdzPh3csS4I2F07Q2C 0lMBznfsZ0N0N+fz3U2jR5kyM68Vj2/W7XrIaiG7DgPe8wGJkzYMVOiXDqzLa/fh sQH/IFpfjJQl0lCCZ2NKnIEG4s8S5eCINZZyipcGnKtrsvVviA=3D=3D =3Dkp0k -----END PGP MESSAGE----- The session key is 58FBB6C39FA3626AA283E47A01690957D0B866392B9CC79E53E943FF410ED6DB. You can view the message on [1], note the two padding bytes "wy" at the end of the compressed data stream. 1: https://dump.sequoia-pgp.org/?data=3D-----BEGIN%20PGP%20MESSAGE-----%0D%= 0A%0D%0AwV4Di9iOlMDSAzMSAQdALBAMZRuLecJf8LZvPIYhTrqmN6BLN5fEc8m7sPZAPSYw%0D= %0A6lm9Nmm9fo5ogkLknC4E%2BME8S9v5lCJVAMZ30OXNX5is/uvdzPh3csS4I2F07Q2C%0D%0A= 0lMBznfsZ0N0N%2Bfz3U2jR5kyM68Vj2/W7XrIaiG7DgPe8wGJkzYMVOiXDqzLa/fh%0D%0AsQH= /IFpfjJQl0lCCZ2NKnIEG4s8S5eCINZZyipcGnKtrsvVviA%3D%3D%0D%0A%3Dkp0k%0D%0A---= --END%20PGP%20MESSAGE-----%0D%0A&hex=3Don&session_key=3D58FBB6C39FA3626AA28= 3E47A01690957D0B866392B9CC79E53E943FF410ED6DB The following patch adds a section to RFC4880bis detailing the process of padding, and recommends a suitable padding policy. diff --git a/middle.mkd b/middle.mkd index ca73704..beb6f57 100644 --- a/middle.mkd +++ b/middle.mkd @@ -2397,6 +2397,26 @@ ZLIB-style blocks. BZip2-compressed packets are compressed using the BZip2 [](#BZ2) algorithm. +### Message padding + +The Compressed Data packet presents an opportunity to add an arbitrary +amount of decoy traffic to OpenPGP Messages. To that end, +implementations SHOULD create a encrypted, compressed message as +usual, and SHOULD use the ZIP algorithm with no compression +(i.e. level 0), and append a number of random bytes to the compressed +data stream according to a padding policy. Note: Not actually +compressing the data stream is important to make sure the size of the +padded message does not depend on the entropy of the plaintext +message. + +Implementations SHOULD use the Padm=C3=A9 padding scheme. Padm=C3=A9 offe= rs the +same protection as the obvious scheme of padding to the next power of +two, but with an overhead of at most most 12%, decreasing with message +size. + +See Section 4 of [Reducing Metadata Leakage from Encrypted Files and +Communication with PURBs](https://bford.info/pub/sec/purb.pdf). + ## Symmetrically Encrypted Data Packet (Tag 9) The Symmetrically Encrypted Data packet contains data encrypted with a Cheers, Justus From nobody Tue Sep 24 11:36:45 2019 Return-Path: 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 59B791208BF for ; Tue, 24 Sep 2019 11:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TwRUqb3BbdHF for ; Tue, 24 Sep 2019 11:36:42 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D350D1208A6 for ; Tue, 24 Sep 2019 11:36:41 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id m13so2938633ljj.11 for ; Tue, 24 Sep 2019 11:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SsMN2y2o/m+WOGVV1tmJPRO3rPfdZoRIv0N8YicSuTE=; b=qzfi3Of3sN9kNZQcCg349xHkrsHvaaCz3k6rUOEtGzbtNFHwX9OJwjfLmveAV6CRQJ GWf5ufVYh1wyrHajjaTlSLfv2Fs1p9I+2gZicYrTCTQYzHkFfvW0Vfz8tRr+B+AthCCp y/kEsEzjiQCa/3oeoYr1tDLa2HMuGzZsijY764y558FVZ4QuL8tvwpdXzLJaUZujfRsc mqX8QceB/Zc60Y2eydBKkOLISMXbOWozZJBpfh1SgGMF61f5jcITkG5f7xMdzqpEAeVf KMymeLvOt4KWaIND1C2hUejrVDyycxVM6C19fABGFPfTZ3das+UPeA5oBABKD1l9rX09 IZVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SsMN2y2o/m+WOGVV1tmJPRO3rPfdZoRIv0N8YicSuTE=; b=PVOTAOz5T939M2x4qIfLmolP5ETqBxuhbBaFW4PrN7MFuAE70hvYBpzQ1zhmK3tP06 0l3ZozFTn9Rmch9ICmH1OuLsmFUtfNQECm8aWQNrm4O3mPWebUniDoXf1MSeBjAL+qxm fPNB20d2VOCNCH7BTn39/7wgZFwIZMVDlsVAikZREVEO+/GqZFCCF4SE13tydUjPup7X tLtQ+nce9L/jOolqYxTgxifHRA+03deGj7YKdYFN2nx7E4XeyZYpCrlkrmdSRKlmtNlN 67AE8MS0uL3eRXVMmuha4+VIELDGsvkOnhvMpZ9gcNDzwdW+tJ9TDseIOjP0ydtTRqyZ k/XA== X-Gm-Message-State: APjAAAXfDWF3k+xH6i2Jds3wIU1OWf1Z9DT8kxS29XT/rigKO8ZzfWxJ RBxea3pfIqHwSHny2C9w2dLvr51WBbsfcagw6A4= X-Google-Smtp-Source: APXvYqyCA2k84eoANAhJVyKT/HR+5L/I1prnnqnAi/NQvSrE/3ABSkWt24v6/LmFk2oyIsuSB9PNFnNry+PIk1GAsSg= X-Received: by 2002:a2e:9059:: with SMTP id n25mr2932636ljg.134.1569350200246; Tue, 24 Sep 2019 11:36:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Carboni Date: Tue, 24 Sep 2019 18:36:03 +0000 Message-ID: To: Justus Winter Cc: openpgp@ietf.org Content-Type: multipart/alternative; boundary="00000000000036c631059350d120" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 18:36:43 -0000 --00000000000036c631059350d120 Content-Type: text/plain; charset="UTF-8" Just encrypt a loop device. Fixed size, already padded. --00000000000036c631059350d120 Content-Type: text/html; charset="UTF-8"
Just encrypt a loop device. Fixed size, already padded.
--00000000000036c631059350d120-- From nobody Tue Sep 24 12:18:21 2019 Return-Path: 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 705C7120942 for ; Tue, 24 Sep 2019 12:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 1T5nk-uQHOW3 for ; Tue, 24 Sep 2019 12:18:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F6C120949 for ; Tue, 24 Sep 2019 12:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1569352690; bh=evqq24GGFiXK61NNiorIxl028pYmKQHPdORAy8GKoJY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Eu3I9iwYXVPrE420OgHdbIdGu+HRYpOXlvy/kXHB3PH22FdxN3PZ8Txe/QiAYnWGC cIsIfaS1j/WMFVepK3ytOX5AAJOxviHfchIrFfWNj92lKjs42OEQt1Db7EKrnjxmT+ pDy5n9SWJnQ1MDCbcOwfUhSiUo7FKU0eB6plD3mI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.30] ([80.132.224.133]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MiJZO-1hikYp1Lss-00fOEh for ; Tue, 24 Sep 2019 21:13:05 +0200 To: openpgp@ietf.org References: From: Heiko Stamer Autocrypt: addr=HeikoStamer@gmx.net; prefer-encrypt=mutual; keydata= mQGiBDdYKNkRBACRdsFzaQn0HChOX38WHXlIYcNZAAxBQxa7gdmPXTUK+tgwQuwAr/XViQxn ExKwyOteRhwHZNSYdoKPlCOJ3c3FWCKAdflINr53NvN/qnnaF+3M1HaluiwVdfHD9a0+k7fd NFZMq2bTpzSCQBsPGipSK0K8ET8UPrXm54pXhqYL2wCgsuMBOv64bmg2zjg6vHSTKADGykcD /Agjoa7y7Cpifk4WEKDKu8nlrE9OFOJppjZ9bdJedrmZq5A/jHr35UOgbZItTmgBiz7bfMLq 7HD05ZQ3BplBmmiE0412f55GadCjN4vvnCdTqZ/ewzWdz/rzQGaJm9IvW6rupuFgrTx0GJhf we7cr6GQQo0nqA0LMCyhGHQASC56A/9NOroBzLM6wl9QlE9lybxd3cxI2UnrfHIu63tklFKF vL1XnjyJ4YR0sDs6/f56JbtEGUKTCI7ZAw+241Va4MrbDVmmsGJjQBcKxNbHDfkkjoJ9NBwr pUo2nMT3BWyKHCfnMqoyT+nN04b0Em1ffbhptKiLJSeY1mcPxvA1h7PrKbQiSGVpa28gU3Rh bWVyIDxoZWlrb3N0YW1lckBnbXgubmV0Poh4BBMRAgA4AhsDAh4BAheAFiEEdvcwETKdJ9uN fD+XT1hOuPsr4U8FAlzqvfMFCwkIBwIGFQoJCAsCBBYCAwEACgkQT1hOuPsr4U8jZQCfbz7N emwAJ2OdrBP9mmsySktb4IQAnRWJOYy4bH3R42nh6KCUkbDXQoNhuQMNBDdYKtkQDACuGU2S WXmjpoyGIX/UHze60OolxBdtKzhvDZHhy1Sz8NNrdkI3ozuYOMxkKZZLTw/iQigVNQfwy+5f AUw6KaH8OPnwInqyeguI6PwG0qQK2cWlSTZDlTW8B2D3Qpjt8sYnnjGEIGKGb7ZAUgODmWYd sS35otyEQT0Un/kRIqjyQcvWgNH++t+LypXUxu0eD0dlD/kx46TP9kqTYsr/8vWWhD2J98x0 ZFrFMN8QDCIhO9x3p+qPyfSiAdnuI4iN1RYsKtC2ikb+cIc5bYysnRots1anAy3Pd5Q8bFtj lzxPPRh90v/Yq5RM/3IgbsbS0zDI0ldznld+DInezLs/EROsITmmbXrhIAHC8TjcXtxWR3ht nFLnIgmQ3Rag0bQesNF4Y5bXSGcw/MxwWcm6EXwcbm7Uc64k8YxXMYyNy+XX/bi1o7r5JdH0 mKUFeXTF9WLrNpF4jBylHk1RNDbR6kp6M87vPJeg/nQh19ItQQxYJGYu9KBhBGhFtDUIAyLT nTcAAwUL/2tHe52rFeCVvZo7RZ5SQy/aclx7hnPsvb3yTXcvg5c7hweOL7Zfsh/XnE3acRO0 YAfGb0LxMFJlfpHgcPuTZEd5rPgJz68GccACBPw8Z8MgQEBE5H/UiAR/HM9AQmEN+wfjeDlv 6ZGElmnY59gYIuCGUVsqw5pwCCsLBs3xlMTyCiNwDHERRao3YTGhaNy9hsCdqNHQcXdSzdF6 OtvfMnXI67QGyiNcbjVwXwQHlGAsxo4O3FMOl138o1Oa00JMSk7td8bClMAp7Hu4zrw533TZ 2Avp+6OFjUAQ4U4hdEDGePNm2hbQinKnUCd30PboqIdZDmYq4SSeNMbWKwy3Etx/a0GX39F/ gnjmveBHSWGGB+wSKcrK3yfXNXMa4OW683m/aH1msS0L0SFwbm2w7XdALp0DCV031x1JoGAn c0mVcstbVM7KNUGnCOA9D4USKHrj/IoZVoapx0b+bWPFHtfLhcm2lSDlq7F140DlQVL1xZmA nPcpLyXMmEmnS2JCZYhGBBgRAgAGBQI3WCrZAAoJEE9YTrj7K+FPcRMAnige4x75lK1p7sbK sdhZb6tv4CJPAKCpDqRn9o7nfvLlouXNaIR1nri7c7kErgRPbbDUEQwA29DKEVd+djjC5B7e jHwAb2EbbVbapdz0JAftKEiTvETd8WqpRRhvhDoGJn+v3ysOp6pKzyOtCFPQoN8559cgqA+e MMrarkufk7NxyFmuq7VILm4VSouUFgDNttHB63nAT/7FnRY/ccvJClL5vrVwMiioBVmXEJTw 8Nnw36tZoerE68uG8jS/cJjypmXhWoSSVQAKjC/ErQ5z/qNzJqAsem+eV/LHUd2BLK+u7r7Q 98ksKUpmEp5xVCox8HF1JwcG7QdJndVUCHHiV2fWDdIM0P8DCbagLZ+jQWMky/BvJL04ejnh t2O1YDyKaz3PzLMKk/Sbf9tIDw1iKJL3PQNNsu3cPOORmGsZQbfX940qiqdfD0+V3gmCjKBg TtFM/lJFkcMC0H1XfwQZBADudRIqqZp6AKkznpu8fmH3ut6C7Gl7ZXib5dNSPFIWfjBxrGnb STNChlYg0AEy5Lsm80oo7ef8VymQ/Vg/EoSVJT4vke5sY669W7lshZVcKVaqUt4/AQD/DO6J 9jyHVVwvopSC9E17qd/9qIHvrY+m/wdaGEdcHwwAsP7Sqj7SdBn/BmeSLJiXqZ+OwhOEbv6B A3ZJExEuIlNm+46tuyi1hxczbZ5ZWfOCpVPTSYBIuyl31OR1S6ef1iAGY8kkFF+3tkmbu+nQ 2dpyyfw20ZnKFkWG0IhZhQZwMANrQ9nuQVEXMc3c1cybuiNTDeIA0wLwlnYkzoPYRk/aXUQj kYvaexfQsfBrbn2qU6YtE/aRybgBoGkuJn6tSwfa4LeMA5S5p8aF/pDKRNm5vt0LpxcqPrSI pzPeHD0Oucwv3ZqfDCTIOENZwBEPSyNz2XEA2b+bnKjggprFLguw5USwpca6F/eeXGArs278 WBdAmncAgdcvcDmjMJuaGke48n1zbDHYlC8NHGTUUvVpiJRZt2KLgIzIEz/5d1tiGUZqhYk2 c9o+lHjbnv4E+L+ITY8yPqyfWHV2aH3tKa7qoBX+EyGCtW9X42gATcj3ZzVBgWD5w3BnbIgW T0dLvieBFn4T25Fy80Md+cwj4yvcRgJsvZgkuR0UjoWDxgvpDACOnRYzI/WqTSBAS1T3vmfU VtjRdUCiYpptR+sNmj//nCRdy3yC8az0WHemmWmhhE4GUT6KqtD0WPBFb9L54hq5qWCzbjcR zPW8BZJAhjynhIp2ljLAskd+50dvpsOE6aL9vAlPySuRg95dFwa+425783Hvp5YIY/LloLtb YXyRH2nBLfmXGSt1JL4oOfCEWgwLENAOXel8+aet8HD7LN8OgP+971lJ5DtCSVs/Vw4I8NdV DlssId0NhoNW062Br5qmgga0fKiU4oU0SGDOWNBGp9oUW+jD0OhIiNIFLrsse8isZrQK1W5q 0zi+guiyBB7ftp5uJHSF7Y0Cc7rKSSFsMj1E+PTKDtHpcK+AFTEDiTlPmCNemNxwmm6LtM54 ybQ8R96psrbahOX2LeYhYTwXasKk9bQ6WTOt9biO9R4y/Z9Yy52LwMXCyHot+V4+TTG9iMe9 ZWYEe1bCMLBEh7E7RYVDWHpYmhW49/U23YdY/AeROldZzSduXZTgz8f64diIYAQoEQIAIBYh BHb3MBEynSfbjXw/l09YTrj7K+FPBQJZJr7xAh0DAAoJEE9YTrj7K+FPLrQAoKRZEWwU0+ME qEgFOCHIZDuFAh7mAKCVdunDvK+/J0blWkCXFNh6AgS8t4ipBBgRAgAJBQJPbbDUAhsCAGoJ EE9YTrj7K+FPXyAEGREIAAYFAk9tsNQACgkQWxEYjUGN7Fd3vwEA7Bu+0FRCGhORinzglpFz SBRAZ3kGjlLeGZI7peOLva8BALuQ6pZCXV2m1fW7HhHQWYY/IRHRgupXiq2l1kfUQ6uvwqYA nAqoUxzoiqZ0wzzBkhAQC/RbccnzAJ9ZuHUDUACXo2yW+8IpiyP6Rlgu7Q== Message-ID: <8e156086-c73f-47bb-e643-4e589ac5e6a0@gmx.net> Date: Tue, 24 Sep 2019 21:12:36 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:q9k16VIhsbNIvR7B0eSbGZuwlts5YWrC9vyjRau+SXwHdkVUiF1 OuMRZMFv1kdorqyj5OrhM2baysQ/JiF3jziT9e1KaZyhXb4Iwrfu4BCkMMUpXHd1VIpB1UC /tAUnF0P7Qb8c9/3V3xx6Env1eN4ZVl27Jg8Hloa7r6QdxYl4fvR7xeMI4RgZmYfR0Z/m5U ORZgBt3Y0RZe6zAh4ktww== X-UI-Out-Filterresults: notjunk:1;V03:K0:bWGmm5+V8GU=:Dq+EZOb5VhhosO3gx7okgV glylZX4Y44g9DGJJ/6p1qFIrcn9yIO00tC8gJAkwhjV2WLRi7vG/0A4QF/hPWJRvvzwqxjRel wbw8xDcspBeWTC/4bCOFep7kWyyY6TagpggR3LnHS3M3Q8rqmgceYMlhfF4oWuTkorSJNpbiF atTdRBWciPKlRvydy4yyogzUOh1c7HxQz3GVWqm+klwbDHBiiU9+g6fXEzJUj2fwl45YFYci4 b3dQ7mxQ5eEMFkkv3B7RjPWfCmR9N1B+wL08/+4wclecQu5nWpnsz6BH5IGQsrNWt+Sr6Az56 I7ocekBcsdFzySKxm0YmEi8XerY34g21yb173xVt5fVtAad9ncEX2HqjHhg4DIWn2IFYBGdF4 PEdGbb8TVamWy0eS5lUJANdtV4QPB50hdOLTuq2KaClc5My9+fOLak+c+unpLGLwnAHenHwEQ XJq5UpYX42xItGazaIOPiCm2mZs5zwP3jcFgV8tOzT9qqTZKheabq9/QIB2VLJ/kMT6GVZ58G pLcUlZRw5696X4OY7xZNkZW5uHIWzOCdE6u4oevphQb5+jl74A5yNZS0zMrHo4XAI65pe0Ayg 8aHha8jfKg9U1jVxhslg8gmsXsfaTfjqa2XRA6jRNg7cJfSjLKI3KdC+qLJNAwHmIWMIfK9CQ vy4SN4zkODXXCokD3G1d55O9UyPFPMdvFswVwWGCFP9yt/JB5fmFQ6Kz2DpzvlFUMhY2TdFd6 Fw51LmUlV86B/gWFm5UX/OSg7Zl+KDuAiPg2TlaRrRtmrZyqRXWWNHhSXZe5E0iMm/82nPBUY tXER3Kmk/bF5/ISID8CCcA+cw6D061eJ03AW1Jf+RvmR/aOKYkGN0tFckz6t2HXFkSrGL17H8 +9Prhh2Cw5RBCJyLIs5x5fAeJ6AfYLr5smEMAespFmB0PBEuRAIGgBUyKzp62ixklHLBCwV4p qlcQwvQfVMnh6fKcnCS68bHz5PvMSnu8ErlDOWMzwQiA1k5IvkYPl9agQMPbzo4iyofWs8+kP Jy5gbOCk8ikusPchLyL9KPnESgSY36bKlYGaZT6F3I8vuxYskhwcoyq1OaW/u94rrr1GdG5DH jpXibWIJ1BdhqvMqkLvdMzHYrHqzCA5xReJ+qBl6WNileOt9EqSqipcdSGzOPu3KCa8EV70uj eyuYWfvlgBHgX600MDFpJWP5Pmwy5UqLfH6Kr0TT7db+PR8II/410W/swlS9phy55nFN2B25i QsNiQ9y+fNL7JnsSd1pwKAjnczvZyakG1qn8iavIbqO7g6VPiLMejsao+nuM= Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 19:18:19 -0000 Justus Winter wrote: > We are currently convinced that padding the compressed data stream is > the best option, because as far as OpenPGP is concerned, it is > completely transparent for the recipient (for example, no weird > packets are inserted). What's about keys that state no support for compression? =2D- Heiko From nobody Tue Sep 24 14:00:24 2019 Return-Path: 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 57C131200DB for ; Tue, 24 Sep 2019 14:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=pass (2048-bit key) header.d=icloud.com 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 w61FxY4RJkje for ; Tue, 24 Sep 2019 14:00:21 -0700 (PDT) Received: from mr85p00im-zteg06022001.me.com (mr85p00im-zteg06022001.me.com [17.58.23.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812FB120020 for ; Tue, 24 Sep 2019 14:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1569358820; bh=8Jcbo8v29a5E2vfaDzxiv2Wy+cXberHGxnA+zmDVH8A=; h=Content-Type:Subject:From:Date:Message-Id:To; b=nskes9A2uX9AN8ATW+P/K+9NgcF18j7AYTBynHntOnTHiLHnFn/ihKlCfjZell82Y QYyyRIQRZ8ylP5qePIssViiGWGqs+unTgfTiGSizN1ivr9BTBImG7tLmXDzoUm32iv C+Vwmo4biDY3bNn3tK5xlrc4HpAsccKRFpUz0cwst4BQ4AiMy/OurSC7oPkhDhOOc9 oqTIiesIt8uEDYAGHMcVgU6q7jv8FyNxB1eTHuS8Z6t66P1UBmqj9sckUSPczv7XD2 kpmPhq2h46+2okJOo35WTdb60qL7JRFiEC7g3qVj9os/C7wS9USTt77+C1rPUHmKG1 7KvHM4Oh/J7bw== Received: from [10.70.126.231] (unknown [38.109.115.130]) by mr85p00im-zteg06022001.me.com (Postfix) with ESMTPSA id 8ADDE9003DC; Tue, 24 Sep 2019 21:00:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Jon Callas In-Reply-To: Date: Tue, 24 Sep 2019 17:00:17 -0400 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> References: To: Justus Winter X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-24_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=961 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909240169 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 21:00:23 -0000 > On Sep 24, 2019, at 1:09 PM, Justus Winter = wrote: >=20 > Hello :) >=20 > To reduce the amount of information leaked via the message length (see > e.g. [0]), encrypted OpenPGP messages should include decoy traffic. >=20 > 0: = https://mailarchive.ietf.org/arch/msg/openpgp/rG-X9rp2jlbyACoosnbxRXjCeys What actual problem are you trying to solve. We've discussed compressed data at length, and there's a general = consensus to my mind that implementations should move away from = compression being the default. There's less of a consensus that it = should go the way of all things, into that good night. But we agree that = compression is at the very least a can of worms. Am I correct in understanding that you're proposing adding in decoy = traffic to pad out compressed data to its uncompressed length?=20 If I'm missing something, what problem are you trying to solve with = this? Jon From nobody Wed Sep 25 02:03:40 2019 Return-Path: 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 AAB3812011B for ; Wed, 25 Sep 2019 02:03:38 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ADQJCrhhjgev for ; Wed, 25 Sep 2019 02:03:37 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B575D120111 for ; Wed, 25 Sep 2019 02:03:36 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id l3so5677103wru.7 for ; Wed, 25 Sep 2019 02:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EJBtt8h51TL41aHOT64vRE4klSnRYN3ZO5lyhKlGn5c=; b=UMYxgJD08GFOT+UMFu7ONX7/pkROKJly9uE9lVMqctGv+cEtvszZq7LyvUpoO2EcR3 Sm4aXLW6rWq0DGV5HtulyJl5Orj5py0hUC1EqRff3slb2dVMJYnlcrXFD1TLqEYuqfTW EP3XyBGzTEgp62OVB5umUrqQsu0KnjJI5CopbSddwX5e8jWJ8r72xKWHHSeS2mF28uBK x6pv5mJF/mqCDIfLcSIxgERQ2PK2WvMIM2ZIywTna7CUoVRZPNCAlRSiQusejg6qe6pA Iy1d9YNlbAlI4IYsgnllU7D/Avhqx8KJ5eACeS7l5V95rVJUIy4f/+3BuonM4aBu6vgJ SlGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EJBtt8h51TL41aHOT64vRE4klSnRYN3ZO5lyhKlGn5c=; b=AAF1hIzkGXDcjhMouUFu+1sedDNrDWoNSEYDN5J8/e7t3YFtz9ItOglYiMXHRALgfH aHYLIy+yRbyPAwOPMao2gWxsTHOE+kbE/2lkI4y/d374vtlFXnzp32ZeBq9KjS3Dddn1 1w+mU5vht45X/EYSr/DqmZ4/tAT+xCulWEOSJifEWUMcG2RCrlZOgb8WPaBcuflH7YZc Gv30EGnF6vep9Q5L/nW9iTxkJNegBOIaDqu2QgsTkLgbHt90PDt09PjC6GUrQ2OD2gvk yZ/zxRmmwe6yc+IWYFDxhiD4gxF6YZQzujM/B/Doews/0Xcssjq+yNr2ZTRGH1Y4M3Ur vYfw== X-Gm-Message-State: APjAAAWhRs4y/XMB8vGy4EGT2YfDlOz34WZRJTRwY25z9ZDx3cRbTXaO ZoX7I4SRQeJJNR7eM0NPLYsar3bydceoHioNLtQ= X-Google-Smtp-Source: APXvYqyUopSYeNgJJcQ0RzcgY8I5t/zX9HHUHZ1aNaTRWU11btWVaWeWe2FMokhgfWjidUlzn8JYbaLIgylMRNAL9YQ= X-Received: by 2002:adf:dc01:: with SMTP id t1mr2141223wri.222.1569402215115; Wed, 25 Sep 2019 02:03:35 -0700 (PDT) MIME-Version: 1.0 References: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> In-Reply-To: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> From: Justus Winter Date: Wed, 25 Sep 2019 11:03:24 +0200 Message-ID: To: Jon Callas Cc: openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 09:03:39 -0000 On Tue, Sep 24, 2019 at 11:00 PM Jon Callas wrote: > Am I correct in understanding that you're proposing adding in decoy traffic to pad out compressed data to its uncompressed length? No. I'm proposing not to compress the data at all, and then add some padding data according to some policy. The compression container is only a means to add the padding within the constraints of the current ecosystem. > If I'm missing something, what problem are you trying to solve with this? There is a correlation between the size of the encrypted message and the size of the plaintext. On first sight, compression helps with that, but that makes the size dependent on the entropy of the plaintext, which also leads to problems as discussed previously. Padding alleviates this problem, the tradeoff being an increased message size. Cheers, Justus From nobody Wed Sep 25 07:32:48 2019 Return-Path: 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 260D61200C5 for ; Wed, 25 Sep 2019 07:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 CX61eriVTITC for ; Wed, 25 Sep 2019 07:32:44 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313321200C4 for ; Wed, 25 Sep 2019 07:32:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E03A5E2042; Wed, 25 Sep 2019 10:32:42 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 12376-02; Wed, 25 Sep 2019 10:32:41 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 937A7E2040; Wed, 25 Sep 2019 10:32:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1569421961; bh=L7BtDwF1ZFppka35PCvDoa+p6zKvIItDKmh4oRVOfZ0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=DAMTIOCVSKH+ljJhskrTvmi0R+AJCa0hxdFZBIA4eIATBQYUHkghrRsjr5JtAw5iM UPBT+lq0RjY30obwCSrQPn5XOEur4qIx7h2u79bfeOnWQ4J8nXR3U5QGusjk8+X9tg FlkmqAQkPm/xLQrUMT+rS4jWMVyPbiRJYnUonpOA= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x8PEWZ9J030268; Wed, 25 Sep 2019 10:32:35 -0400 From: Derek Atkins To: Justus Winter Cc: Jon Callas , openpgp@ietf.org References: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> Date: Wed, 25 Sep 2019 10:32:33 -0400 In-Reply-To: (Justus Winter's message of "Wed, 25 Sep 2019 11:03:24 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 14:32:46 -0000 Justus Winter writes: > On Tue, Sep 24, 2019 at 11:00 PM Jon Callas wrote: >> Am I correct in understanding that you're proposing adding in decoy >> traffic to pad out compressed data to its uncompressed length? > > No. I'm proposing not to compress the data at all, and then add some > padding data according to some policy. The compression container is > only a means to add the padding within the constraints of the current > ecosystem. > >> If I'm missing something, what problem are you trying to solve with this? > > There is a correlation between the size of the encrypted message and > the size of the plaintext. On first sight, compression helps with > that, but that makes the size dependent on the entropy of the > plaintext, which also leads to problems as discussed previously. > Padding alleviates this problem, the tradeoff being an increased > message size. Why not just have multiple literal packets inside the encryption? I.e.: ENC{ Lit1{realData} | Lit2{pad} } Note, of course, that this could provide a covert channel which could leak other data, theoretically. > Cheers, > Justus -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Sep 25 08:24:14 2019 Return-Path: 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 6824512008D for ; Wed, 25 Sep 2019 08:24:11 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 vuibGqmKxvNu for ; Wed, 25 Sep 2019 08:24:08 -0700 (PDT) Received: from st43p00im-zteg10062001.me.com (st43p00im-zteg10062001.me.com [17.58.63.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FE7120025 for ; Wed, 25 Sep 2019 08:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1569425047; bh=a98P8qPdcvjF0bt3c1CfnaASwBvyghrVFXixBaaUCBY=; h=Content-Type:Subject:From:Date:Message-Id:To; b=CkLG+NKOY9pkM/9Jcdb1XH+ZHG0T2cpXnjfVhX5zsOC/53yh7X7l3NpDlqmWHtKK2 RatRfkL10HnDJzdneKaYpb9LWA16IXBF8DKP+a70n1JPTVCyI7Q31dAdfUUlHGQMbQ lE3AZKUZFmuV+jD6Fclu6CVvs7E6esuft1OpbwfyAEWZ2mx7vSjITwpwPLnEASm+ji dFQwBz5uA2iKXtyiukZF0H7PuvvTfMHSKvI+fbLfrJAceHE+vwEtDvQgX25migHeTB WyygwVdJL8O0N/aO9l+hdOD/3g+tX/4c4KN3RJM3e6AnYe6eD6KegLGo1n6ORnebt6 12dRRQmoWZXRg== Received: from [10.70.126.127] (unknown [38.109.115.130]) by st43p00im-zteg10062001.me.com (Postfix) with ESMTPSA id 25CCC6C0608; Wed, 25 Sep 2019 15:24:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Jon Callas In-Reply-To: Date: Wed, 25 Sep 2019 11:24:04 -0400 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> To: Justus Winter X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-25_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909250145 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 15:24:12 -0000 > On Sep 25, 2019, at 5:03 AM, Justus Winter = wrote: >=20 > On Tue, Sep 24, 2019 at 11:00 PM Jon Callas = wrote: >> Am I correct in understanding that you're proposing adding in decoy = traffic to pad out compressed data to its uncompressed length? >=20 > No. I'm proposing not to compress the data at all, and then add some > padding data according to some policy. The compression container is > only a means to add the padding within the constraints of the current > ecosystem. Okay. Thanks. I think that clarifies. (Meaning I'm still slightly = puzzled, but okay.) >=20 >> If I'm missing something, what problem are you trying to solve with = this? >=20 > There is a correlation between the size of the encrypted message and > the size of the plaintext. On first sight, compression helps with > that, but that makes the size dependent on the entropy of the > plaintext, which also leads to problems as discussed previously. > Padding alleviates this problem, the tradeoff being an increased > message size. Well, if you don't compress, sure there is. The size is going to be = + and the overhead is generally easily = computed or guessed. I understand the vague concern, but to me the proposal is security stone = soup. You're throwing some stuff together and it vaguely meets the vague = concern. I think there's a way forward and that might be something like: * Describe the actual threat. I can imagine threats, but I don't have a = handle on what you're trying to do exactly. * Describe how the solution (padding) helps and give quantification as = to how it helps. There are plenty of places where padding doesn't help, = it just shifts a bunch of things around. There are also places where = padding ends up hurting. I've seen this in constant-traffic networks = where the padding makes traffic analysis easier (hand waved explanation: = the padding makes it easier to recover a timing side channel and that = side channel allows you to statistically remove the padding; you end up = knowing the aggregate of padding to a statistical confidence level, and = on a data stream, that's good enough.) * Look at what might be second-order effects and discuss them at the = least. Costs in terms of networking and storage vs benefit need to be in = here. A few years ago, I was looking at a very similar problem, and that was = removing sized-based traffic analysis from cloud storage systems. We = looked at padding things out, and in many cases padding didn't really = help. We looked at padding with thresholds -- e.g. round everything up = to the nearest chunk size, where a chunk is something like a power of = two in the 4K to 1M range. It turns out that a lot of information gets = leaked anyway. For example, you can easily guess that something is = likely to be a selfie, because they're all in a reasonably narrow band = of sizes. The larger your chunk is, the better you blur, but the obvious downside = (that now you're writing a lot of extra data in the vast majority of = cases) has such an effect on wasted networking and storage space that A = Reasonable Person would likely decline to pad. Padding small enough for = the concern to be insignificant gives a correspondingly insignificant = benefit. We ended up doing some chunking, but we knew that the benefits = were so small that we didn't even really talk about it. It was far too = easy for someone to think they were getting a huge benefit that they = weren't getting. (A similar situation is the way people overestimate how = much private browsing or even Tor help them.) Summing up, it's interesting, but I think a cost-benefit discussion = should follow, along with at least a hand wave of metric-ish things. Jon= From nobody Wed Sep 25 08:35:47 2019 Return-Path: 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 90D2B120025 for ; Wed, 25 Sep 2019 08:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai 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 3fcHV5FFMhG9 for ; Wed, 25 Sep 2019 08:35:43 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A5F120013 for ; Wed, 25 Sep 2019 08:35:43 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id 819F3A0B8C for ; Wed, 25 Sep 2019 15:35:42 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=YS9HPyio2sxTFlGaC30VXOGpA6K9XAxddIoY/Sbh+fE=; b=SNBc7BcVdYwGXYHSlbF5P7BA16J7basAPkTDjnAj5v71RJpyhDQsq2LIK5sBwYlT2rqf2UTuBo8S7cZalzGMS30Q9h0PklgCZKqpthZPCHnFGcS5bXoTBihC74MNRDlLoAP1PLZAlV28epjmeRF/UG47GfSkoKbNxnt68w8THr7oxv9DNM6ci8zNxgQg2Ipau127zucU2vBdQYZf+029rpIuIcUs2axgSgwn7eRKDfd5JCU8H2Ywh2p6bIsrLmKQEv+I3Oe3ObW1dUUV+juoSvXWn7NCDS+mQ6yiVxSyQwp5PzhC60iGnYyAmMmL9JwV5xaLtsiLCYjnfvSEoJXZig== Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS for ; Wed, 25 Sep 2019 15:35:42 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 14A78200F9; Wed, 25 Sep 2019 15:35:42 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 25 Sep 2019 11:35:41 -0400 To: openpgp@ietf.org From: vedaal@nym.hush.com In-Reply-To: References: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20190925153542.14A78200F9@smtp.hushmail.com> Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 15:35:46 -0000 On 9/25/2019 at 5:04 AM, "Justus Winter" wrote: >There is a correlation between the size of the encrypted message >and the size of the plaintext. On first sight, compression helps with >that, but that makes the size dependent on the entropy of the >plaintext, which also leads to problems as discussed previously. >Padding alleviates this problem, the tradeoff being an increased >message size. ===== It really doesn't matter once the message is past a certain length. Whatever correlation there might be with the plaintext and message size, once the message is long enough, attackers can't do more than speculate about the plaintext content. For very short messages, it's enough if the sender just presses the spacebar at the end of the message until the plaintext is the desired size. (And even then, only if the sender feels that there might be some vulnerability with the size of the plaintext, which is usually not the case. ) In any event, it's enough if there is a cautionary note in the rfc about the correlation between plaintext size and encryption, and suggest, that if this is an issue for the sender and receiver, then a workaround could be to simply add some padding at the end which doesn't interfere or obscure the content of the plaintext. vedaal From nobody Thu Sep 26 13:16:14 2019 Return-Path: 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 55DEA1200C5 for ; Thu, 26 Sep 2019 13:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=pass (2048-bit key) header.d=gmail.com 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 x9Ttf4b8yqip for ; Thu, 26 Sep 2019 13:16:10 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3B91200FE for ; Thu, 26 Sep 2019 13:16:10 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id r4so405720edy.4 for ; Thu, 26 Sep 2019 13:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=86TTsAWz3BpWw0LPPF55g16JZ1v/RSWl6CAZvvH1s5c=; b=ssX1efajlxqRbiGxgmgbM2b7RvScdgkgggLdyFwMztYuA4mOhtX7igYtef9Giare+Z nTrahhF0JiMAh6Q33a+XX5zyU9XyeR3GXTF90sSbDFHzFsPyuv7gupAwZFR5Kl0Fmy9H wK3LE3bsezdcb12UcO+5eMgQxvnB+xJEgUpU4N6M2McAj5nmy+EuQbQs7J3Uj8oVkZDt HIGQ+fMv3fOWe3svf31GSwyXTu/fvTqnZ+IeMgrn4hfulSVx4ZPuy2rBiiLKbG0vipdZ zQvbHiT1HwpgLFWCqS6yZu4A/JfOFmkLPT6VR6C43+fdVY0cPK9zJ9IoSru1rm2PVEz6 SsMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=86TTsAWz3BpWw0LPPF55g16JZ1v/RSWl6CAZvvH1s5c=; b=iaAN+D5cr3Tp/uuuV7HzRC132Tu8w9T4BmyE/4Xi6ei7rnklml5JXkx493CZzplOQW aOUDVW/jh4gMuGyQ5jCZXVtMsCb8IWO2ftffeqA0+Dk9AzOitiPTkNltUeBymv2NPP9t zPjO7XkmCcTkvzRsW/zMmJdUJORdtaaFndeVyouymlPcUuhcVMk8GqUOWVUOoQcWIQfC 7rSGzDEH8WpWEztnPVuykJxLpCohvi37B7NskA4xA+j5mxFN/KzUytKL+/luPyskMLgj cQybzQAp69A32Brq/SpgmS1NhG7MQNHpE1hk8+JC/0dHV90Qp14NDU+sRMm7u1BLoMzh MNNg== X-Gm-Message-State: APjAAAWUwIa4Jioad0g74oU86P20MnU5FiyjIFF+6ZUEV0CO+3iqOr2w bAwh5Tb8XSyjweItmk3yOO0odyGsnp3GkhWDQIM= X-Google-Smtp-Source: APXvYqw9OoZZJ5aZ97Yn0UXWhpCExNi0E3e3dUDf0IFa8OBPKXo900U6V7n7WPH3hLUgU+Kw8iTxfI+dNzRwjJLSJmk= X-Received: by 2002:a50:fa09:: with SMTP id b9mr693839edq.165.1569528969104; Thu, 26 Sep 2019 13:16:09 -0700 (PDT) MIME-Version: 1.0 References: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> In-Reply-To: From: Justus Winter Date: Thu, 26 Sep 2019 22:15:58 +0200 Message-ID: To: Derek Atkins Cc: Jon Callas , openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 20:16:13 -0000 On Wed, Sep 25, 2019 at 4:32 PM Derek Atkins wrote: > Why not just have multiple literal packets inside the encryption? I.e.: > > ENC{ Lit1{realData} | Lit2{pad} } Because that is not a well-formed OpenPGP message. Cheers, Justus From nobody Thu Sep 26 16:14:19 2019 Return-Path: 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 ; 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 ; 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 ; 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 To: Justus Winter , openpgp@ietf.org In-Reply-To: References: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 23:14:17 -0000 --=-=-= Content-Type: text/plain 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXY1F9AAKCRB2GBllKa5f +MqQAP9Tb+++/TCwFsR0QJCD8XG1hqVFOCHwYkbEaXCB70x1JgD9F3CKQnFfBOfw EGuDGatqlQWrKAjZ5rjjLUN1kYD7/g0= =X2q7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 26 17:42:19 2019 Return-Path: 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 9A59B1200B5 for ; Thu, 26 Sep 2019 17:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 R9p49w5o2OHY for ; Thu, 26 Sep 2019 17:42:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7BD12002E for ; Thu, 26 Sep 2019 17:42:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DAADCBE20; Fri, 27 Sep 2019 01:41:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlloElG_GlNL; Fri, 27 Sep 2019 01:41:57 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 46844BDCF; Fri, 27 Sep 2019 01:41:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1569544917; bh=TkZ116/0v8+CqYCVqPDZuMzUA71TKaT4dhigChJvcD8=; h=To:References:From:Subject:Date:In-Reply-To:From; b=FCre/6s7UdqOsAfMRSXXVPX8ULQVNncTb6FJ+Cw4zdR3BWArzt0VcP7Qd+z3UVf8o pWAGWcYKfnw3h66dJiG6iUbtW6DiEbxHkKt1PSpKhyACLcVdB4hmtT9s53c0GaPxBW 3pArqw02485tqoGfrWy51uPxqw2siUlgHNn525Ic= To: Daniel Kahn Gillmor , Justus Winter , openpgp@ietf.org References: <87lfua3b4b.fsf@fifthhorseman.net> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <74a4ed22-a2ba-73cf-f665-f720b7f18d7d@cs.tcd.ie> Date: Fri, 27 Sep 2019 01:41:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <87lfua3b4b.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G6QqFChtzQeYZyIOMiWdx8PPMYT6TEBtQ" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 00:42:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G6QqFChtzQeYZyIOMiWdx8PPMYT6TEBtQ Content-Type: multipart/mixed; boundary="FkZAdJ3Dnv6ZNnxNDnMwbHXnz9ap2Qvhz"; protected-headers="v1" From: Stephen Farrell To: Daniel Kahn Gillmor , Justus Winter , openpgp@ietf.org Message-ID: <74a4ed22-a2ba-73cf-f665-f720b7f18d7d@cs.tcd.ie> Subject: Re: [openpgp] Message padding in OpenPGP References: <87lfua3b4b.fsf@fifthhorseman.net> In-Reply-To: <87lfua3b4b.fsf@fifthhorseman.net> --FkZAdJ3Dnv6ZNnxNDnMwbHXnz9ap2Qvhz Content-Type: multipart/mixed; boundary="------------E4C13815BB5C6B17AB34B43C" Content-Language: en-GB This is a multi-part message in MIME format. --------------E4C13815BB5C6B17AB34B43C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I agree with all the rest of your message:-) But not this bit: 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. E.g., in the case of mail, if a message from a small sender with a big DNS name arrives at a receiver that does SPF and DMARC lookups, packet sizes emitted by the mail receiver might expose information about the mail sender despite any padding of the SMTP/TLS traffic. That is likely a bit of a contrived example but I'd worry that arguing that all "padding policy" be set by layer-4+ might go wrong in some cases. I do totally agree with a strategy of defining padding mechanisms everywhere we can and then learning over time how best to use those though, so I think it'd be fair to consider my comment here is a bit of a nit-pick. (But I sent the mail anyway:-) Cheers, S. --------------E4C13815BB5C6B17AB34B43C Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------E4C13815BB5C6B17AB34B43C-- --FkZAdJ3Dnv6ZNnxNDnMwbHXnz9ap2Qvhz-- --G6QqFChtzQeYZyIOMiWdx8PPMYT6TEBtQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2NWtMACgkQWrL68XsX K+rKUQ//bOWHVvN3xrNNh2XzTtEZk7c3JVq1LyIrzwS0gu9HRYcuooV0iNzW61Fq nyxHPa7YGPzGIRxk+BOWiwdFl7X0aQQSEg7fKbFSoYOR5xsrmQjmehjkPJjXtL1b Pc778wFaORni7m70u8me8g2+4OOorRt0RauVUYboMvmL8KkVC56s58JsN5MvYj+W w3xYzyUy1YUW3fKVRIuZ1D2nRooK+Q48hFe4qC6zDf0+miUldrGROdlfdEz6I+Xg 1dGRihCeIwm/Wl3vgRSuq44/3TULKAfB7D7VDiKNPfspE0XyX4QGmFyJn6HCI+YK jkLBInYsFCMgT7cB9aNLmLXKU04acjtlyekNu2Hr53X794tkxEYhpOaFXvdlhjQt k8X1n3V8eq+wFh39TgWMlacNu0NZYHIDs5tNaq309C/oqgnyTLd+vdMqKNf7RWsZ 9UTTRP15fcrFKSYaY+mQzYRQKCc2UC9D5ZmBfRLfXriSqDMhXvhhwCHXU0kKdnwe dpUB7F/vKxbTOxSEKQP5XcU0+yrMyz1ql1mDIYyaOT7ZK9fxgt/KE+9Z+seU5+wc Fwi8M6kYf8vJ+zNRxsqaq5ByCtEsQeLge1A3bFp9MJyF9+G3iJxwkKGuKKGZz5Zj pjEq6KuJ+4ST2hw0OqK7roXL8Zp3lVY+0zq6XIvL8V5kX6kOJ8Q= =WhaH -----END PGP SIGNATURE----- --G6QqFChtzQeYZyIOMiWdx8PPMYT6TEBtQ-- From nobody Fri Sep 27 03:43:10 2019 Return-Path: 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 ; 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 ; 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 ; 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 To: Stephen Farrell , Justus Winter , openpgp@ietf.org In-Reply-To: <74a4ed22-a2ba-73cf-f665-f720b7f18d7d@cs.tcd.ie> References: <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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 10:43:08 -0000 --=-=-= Content-Type: text/plain 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXY3nrwAKCRB2GBllKa5f +NaWAQCBJmNoaKd/ecWAs52SZLrJh5L1yw0TMR1rVpS76k0iYAD/e5C5Xc7s6fq9 Eud5gHnY1MddRqgYD5X3HfUx1zFEtAQ= =g3dx -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 27 04:18:18 2019 Return-Path: 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 1D9A9120801 for ; Fri, 27 Sep 2019 04:18:16 -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=pass (1024-bit key) header.d=cs.tcd.ie 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 outL4J792nhn for ; Fri, 27 Sep 2019 04:18:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8181200B7 for ; Fri, 27 Sep 2019 04:18:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 255D4BE2F; Fri, 27 Sep 2019 12:18:11 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks3fT2G5_Tcv; Fri, 27 Sep 2019 12:18:10 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D22BFBE2C; Fri, 27 Sep 2019 12:18:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1569583090; bh=LGaTG+UovjAxS9qiuDmnJwY2UUOUbvLKEnQxfXeguL0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=IbHx2n46kPaumkOzV8v2iqgC0ix8wJJG83/C0q8oO61ehQzGtcLJG/WIvHWPncxJk +wBCJhOZJZdGFphtyqNf1y0AGfOlsODMydtyL2ZoOGGEI/7XVF9gsQs41HMaBmTH7N 4mkx7dUYCPU2OMZZoFeyarEJV1OOIpn2qmQufJMg= To: Daniel Kahn Gillmor , Justus Winter , openpgp@ietf.org References: <87lfua3b4b.fsf@fifthhorseman.net> <74a4ed22-a2ba-73cf-f665-f720b7f18d7d@cs.tcd.ie> <87blv62f68.fsf@fifthhorseman.net> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 27 Sep 2019 12:18:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <87blv62f68.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="u0xvAr696lMsgmHQRGO3Il0mAucK4DgFb" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 11:18:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u0xvAr696lMsgmHQRGO3Il0mAucK4DgFb Content-Type: multipart/mixed; boundary="mXxLeTGHRdS5zq2BdTB9Yi1ngGV73Q9mp"; protected-headers="v1" From: Stephen Farrell To: Daniel Kahn Gillmor , Justus Winter , openpgp@ietf.org Message-ID: Subject: Re: [openpgp] Message padding in OpenPGP References: <87lfua3b4b.fsf@fifthhorseman.net> <74a4ed22-a2ba-73cf-f665-f720b7f18d7d@cs.tcd.ie> <87blv62f68.fsf@fifthhorseman.net> In-Reply-To: <87blv62f68.fsf@fifthhorseman.net> --mXxLeTGHRdS5zq2BdTB9Yi1ngGV73Q9mp Content-Type: multipart/mixed; boundary="------------C8F1D95A5F9BD5A2365D67C9" Content-Language: en-GB This is a multi-part message in MIME format. --------------C8F1D95A5F9BD5A2365D67C9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 27/09/2019 11:42, Daniel Kahn Gillmor wrote: > 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. >=20 > i agree with your concerns, Stephen, though maybe not the specific > wording. :) I mean, DNS *is* application layer traffic, right? Yep, you're right - I should've said "DNS and other application layer traffic." >=20 > But you're right, as we move toward multiplexed application layer > protocols within a standard encryption layer (e.g. DNS over HTTPS on th= e > 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 applicatio= n > layers involved. >=20 > 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 paddin= g > capabilities) and the union of all the traffic that is expected to be > encapsulated by that layer. That's better yes. I'm not sure it's correct yet though, but I don't know how to properly characterise it myself as tricky corner cases abound. For example, a browser that does DoH to a local-ish recursive might be slightly better off padding HTTPS traffic differently from that same browser when the DoH server is more topologically remote. But that's definitely taking us out of the scope of PGP. Good topic for pearg [1] though I guess. Cheers, S. [1] https://irtf.org/pearg >=20 > --dkg >=20 --------------C8F1D95A5F9BD5A2365D67C9 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------C8F1D95A5F9BD5A2365D67C9-- --mXxLeTGHRdS5zq2BdTB9Yi1ngGV73Q9mp-- --u0xvAr696lMsgmHQRGO3Il0mAucK4DgFb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2N7/EACgkQWrL68XsX K+rYeRAAzX0tBA5fYDMkM7liXNz+qTr/vG3So2O6YzpuBoCJvJ0jjHtf/V01c4Po 9oKyccCWr4g3lwPmD+G+M1LB9akgCePy8GXvkRIL8rY9dRJS5AhDrTWcwMWRyAyL APp4VAfqHTtje42B/qDqbLKmBF7XXKoTb9Jwp91e83bPSkpa/h/X0W0y3KihQ8vP meLrR8RwBGQ81YvE0MWRJ3nEWcRwEkv87L5jbtfUwl/e/N7fuJVXOetIT4E6T5rm eQmbSB+v0GkyQocLjCOjiui5uTehJkvK88z3878SuZE5L+MPJ1LVTP4St3SgXUzN B3P3OLWRoowNYDgHWhoMFzIQIHRn6KzidEcmIhEMf+Tlb/dBE16JWiZleXBsdSde m5BZpOODip2BdFK5mV4Q/QiTUQTi7dfsvZRSda2HVNRVZ5Wlyhlz1IlrNCF7/OP8 uwKSPzbr+cPWxdypmX3ioDeHryhEsbL5aqJcHezPMicrZbOj7JEgCqtbV1pblBfQ MzoW8CnFd3GFeBpon+mv84G20penkOSmXgfEMWkcISOP28nRP4D6SGAase6rDqBY 2tKmcJBFpMThcNf+i8VxvyinqM4rguPgio2C9fIeRU7ZH4ym/uXJsH46XvjgruDT vdGKbnp9o2iOL86trxzq2mfjIReeH7sUSJcg1V2712QKEEMrhAQ= =apLJ -----END PGP SIGNATURE----- --u0xvAr696lMsgmHQRGO3Il0mAucK4DgFb-- From nobody Fri Sep 27 06:45:11 2019 Return-Path: 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 9C8C112008F for ; Fri, 27 Sep 2019 06:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 Vg44ghTUO4A0 for ; Fri, 27 Sep 2019 06:44:56 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77B0120832 for ; Fri, 27 Sep 2019 06:44:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 92393E2042; Fri, 27 Sep 2019 09:44:49 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 27702-03; Fri, 27 Sep 2019 09:44:46 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id E7665E2040; Fri, 27 Sep 2019 09:44:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1569591886; bh=kIdj+k7a5Br4Fob9ottAn0brfpuls6mSgMWcPQvhpeI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=IoHu1MlJ84QVbx+r3ryhMI2aQL3QD0hbi35/Edagv0ypKI5bEP9ds36UA4rLJpoA6 x0z/ej6HSA901L+9yWDObBC1sC2HEjW1o09mMgh7NNR5He3c6QOQE2iCzvWRdieHzg kIb5wnoKGmqnquoqM+Ko10vpSMM4vtgsYm/A0iBM= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x8RDicGL008473; Fri, 27 Sep 2019 09:44:38 -0400 From: Derek Atkins To: Justus Winter Cc: Jon Callas , openpgp@ietf.org References: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> Date: Fri, 27 Sep 2019 09:44:37 -0400 In-Reply-To: (Justus Winter's message of "Thu, 26 Sep 2019 22:15:58 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 13:45:02 -0000 Justus Winter writes: > On Wed, Sep 25, 2019 at 4:32 PM Derek Atkins wrote: >> Why not just have multiple literal packets inside the encryption? I.e.: >> >> ENC{ Lit1{realData} | Lit2{pad} } > > Because that is not a well-formed OpenPGP message. Neither is anything else you are currently proposing. 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. > Cheers, > Justus -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Sep 27 07:03:46 2019 Return-Path: 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 810A4120025 for ; Fri, 27 Sep 2019 07:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=pass (2048-bit key) header.d=gmail.com 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 igOYLYaO_0aN for ; Fri, 27 Sep 2019 07:03:42 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA48120052 for ; Fri, 27 Sep 2019 07:03:42 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id p10so2461861edq.1 for ; Fri, 27 Sep 2019 07:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x8lc6xlSZxUqRMmtTWFUG/eziJzOU6+nWTbeDktdWbU=; b=Ezz6qbqct1/LfMGa1i1RV2drM5qlbrTxHEZCzUcOZ2LybEY1QOodBhuslyjT2EmPVA xMkKxZmM3eFEqSWt3t3WHmTXP3mPHqY7R9h18O2qYXa8rhEsD4U7o5yHNNYUz+EDtkV0 Ma2add5JY5tTch2bcGKhaae4Yh3yZKo02T6O2pwUEz4gZuQ+aImj1HMGXAXerl+jmWaS rSbpLROTQwUm7DX1fwy5Ii7fMt5wyymCFoNh6aK2MKppVbPkN2GUS+mhIQI00Cwco5BR ak3NMHi418bCP0c62PG7wLyfEBMiLJrBLodXup0xWCm24/0sv3FC0zWq/aY/7PHiiUnD lzyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x8lc6xlSZxUqRMmtTWFUG/eziJzOU6+nWTbeDktdWbU=; b=O7r47iTxfkTjM33N1r0caXJAH8PTu5BHtJP1/XVlJ2ZM3y2IDsClP4TBiuDFv7YfIr mNOmDwlgmUAZEE1a/+JrCMmYUpNSKU8/XI87oPKHNuBz3g1HioJabyN2EpF0NJFPfpRL 6R4Bdbo4Xg7DUG1wThmUgFcxQfswi688sykLsfsX3QDPGgYvBhLt/FgfgIPXh6C8aesv Q/vPd5Q+TdnH75xV+nb8bO5GpYjYQeiCZTrD92YQj8V+nii+Eu0lN15OpTIzMdlsxVrs y3BQXFuKH67U/iiLJgDRUsHWzHnvs0KPz+MnUI4bAbJ7+7XARoH1cdQ3Puiiji9TbenU APNw== X-Gm-Message-State: APjAAAXWbGbrfkBTN9ZyEZ2m0/Y2EBm5tjnZAOGZtEzp9zA/HKmDioBu 20BSjZW6YwJnitWqkbCZuVv8paymoenOWS39ZfE= X-Google-Smtp-Source: APXvYqyVv1i8mmmmhayp3QEXCB5DrrN1xomm7lCGTQMN4blkpltepKaUkvCO9TxmWiloiMOivjqorHyyq7Az5j+uWCk= X-Received: by 2002:a05:6402:383:: with SMTP id o3mr4736890edv.205.1569593020948; Fri, 27 Sep 2019 07:03:40 -0700 (PDT) MIME-Version: 1.0 References: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> In-Reply-To: From: Justus Winter Date: Fri, 27 Sep 2019 16:03:29 +0200 Message-ID: To: Derek Atkins Cc: Jon Callas , openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 14:03:44 -0000 On Fri, Sep 27, 2019 at 3:44 PM Derek Atkins wrote: > Justus Winter writes: > > On Wed, Sep 25, 2019 at 4:32 PM Derek Atkins wrote: > >> Why not just have multiple literal packets inside the encryption? I.e.: > >> > >> ENC{ Lit1{realData} | Lit2{pad} } > > > > Because that is not a well-formed OpenPGP message. > > Neither is anything else you are currently proposing. That is incorrect. Please do go back to my original message and re-read it carefully. > 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. I was explicitly *not* proposing a new packet type. And I do not believe that extending the spec is as easy as you make it seem to be, and extending the spec doesn't help existing implementations. > 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. I bet that your parser from 1995 will correctly handle the padding mechanism I proposed, as long as it is able to deflate compressed data packets. Please do actually try that, I'd be very happy to get some feedback. Cheers, Justus From nobody Fri Sep 27 07:15:28 2019 Return-Path: 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 ; 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 ; 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 ; 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 To: Derek Atkins , openpgp@ietf.org In-Reply-To: References: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.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 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 14:15:26 -0000 --=-=-= Content-Type: text/plain 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXY4ZcgAKCRB2GBllKa5f +NeaAP9u/zzdwQI3VMdKQ2cpvrSZ8pVqg0iAgSzpYKo6dmEllgEAxjc17tIIZWYz smzricrCpWuhU931GZ3wyIDGXlJLdAs= =t7Kx -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Sep 29 04:03:47 2019 Return-Path: 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 DD9AD12008B for ; Sun, 29 Sep 2019 04:03:45 -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=kfUuXpQe; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=zTbRRQtN 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 1hEjKAHVbcAS for ; Sun, 29 Sep 2019 04:03:44 -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 2AC63120024 for ; Sun, 29 Sep 2019 04:03:44 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1569755022; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=gpohSKX0H+XoryPKpef24tGBkcLNw2DYNT5wXnUJfjM=; b=kfUuXpQeoZXXAzDy6SBfZklJ5QK6TrG9aX6/TQgeZ/qVhSWX6MCqlXQf bruotcLOB3536sPqQMzNabiA7FGuDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1569755022; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=gpohSKX0H+XoryPKpef24tGBkcLNw2DYNT5wXnUJfjM=; b=zTbRRQtNm/zEQMSNPQzzILIM/Z51iVOwZOAvRLHfLn2qxs+MYxkRCcPL 1Tn3HQYHyQWflo7qJlsvEkDIqcBH2f8Rm1d8T+K5fv1Gt5eYUz9B4B2ahi TEfu5Ze1CEg37fiNUelFglDYMV+WitIDg62BhO3AFFcDxvy99i1UK/ZYJO QBClrXgeRqbNdyClsdaC6SYIMW3VzrP+9K4d7T2bhpXNsLQMVKpLMoc0wO ooDLM8asaVfkp2Mt9JP2mF7T8QrVzyoFHcdx6zc2OPd6dBXEDU/tAk1njA lTgtkFdNCMHYZcs5OZD2Z9zMpnl8Kpm+9mRlDxGwdY6f9REY/h1nTQ== Received: from fifthhorseman.net (dh207-24-182.xnet.hr [88.207.24.182]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id F2632F9A5; Sun, 29 Sep 2019 07:03:41 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 392A62058F; Sun, 29 Sep 2019 13:03:25 +0200 (CEST) From: Daniel Kahn Gillmor To: openpgp@ietf.org, Jon Callas In-Reply-To: <87impmomm7.fsf@fifthhorseman.net> References: <87woe7zx7o.fsf@fifthhorseman.net> <3AC1C32D-E2DE-43A0-A35A-1E7420E77980@icloud.com> <87impmomm7.fsf@fifthhorseman.net> 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: Sun, 29 Sep 2019 13:03:25 +0200 Message-ID: <878sq71i0y.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] User ID conventions (it's not really a RFC2822 name-addr) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2019 11:03:46 -0000 On Fri 2019-09-20 14:20:48 -0400, Daniel Kahn Gillmor wrote: > Nothing in my commentary in this thread is meant to change the > fundamental nature of the User ID as a UTF-8 string at its core. > > The goal is simply to more realistically state what the common > convention is for User IDs that are likely to be used in the e-mail > context. I've opened this as a merge request on the draft: https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/23 --dkg