Re: [openpgp] openpgp Digest, Vol 30, Issue 7

Robin Wilton <wilton@isoc.org> Wed, 04 November 2015 01:05 UTC

Return-Path: <wilton@isoc.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995201A87D1 for <openpgp@ietfa.amsl.com>; Tue, 3 Nov 2015 17:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 bv0FBAZXeajB for <openpgp@ietfa.amsl.com>; Tue, 3 Nov 2015 17:05:20 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0060.outbound.protection.outlook.com [207.46.100.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAD61A87AF for <openpgp@ietf.org>; Tue, 3 Nov 2015 17:05:20 -0800 (PST)
Received: from SN1PR06MB1838.namprd06.prod.outlook.com (10.162.133.16) by SN1PR06MB1744.namprd06.prod.outlook.com (10.162.132.142) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 01:05:18 +0000
Received: from SN1PR06MB1839.namprd06.prod.outlook.com (10.162.133.18) by SN1PR06MB1838.namprd06.prod.outlook.com (10.162.133.16) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 01:05:16 +0000
Received: from SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) by SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) with mapi id 15.01.0312.014; Wed, 4 Nov 2015 01:05:16 +0000
From: Robin Wilton <wilton@isoc.org>
To: "openpgp@ietf.org" <openpgp@ietf.org>
CC: "openpgp@ietf.org" <openpgp@ietf.org>
Thread-Topic: openpgp Digest, Vol 30, Issue 7
Thread-Index: AQHRFnJKpRDO8K23PkuVXBXY2TgVg56LDNY7
Date: Wed, 4 Nov 2015 01:05:16 +0000
Message-ID: <86CB1513-F594-4A9B-A3B6-17ECB9CA9EB6@isoc.org>
References: <mailman.92.1446580813.31211.openpgp@ietf.org>
In-Reply-To: <mailman.92.1446580813.31211.openpgp@ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org;
x-originating-ip: [133.93.68.247]
x-microsoft-exchange-diagnostics: 1; SN1PR06MB1838; 5:Bt02eP6jYn+n0FHIt6/Yo2+QIZa/yP0Y1nwvXyg8mNdfXDS3HEKtvPhibm8HpaAb25Fs1dPLUeytwF2gyv5quuqhw6n4tgHOkDwsAKjnUqc5Q1f021jDaMJP5c7F7ak7AG+P+XzsRisQwAG4QEb7IQ==; 24:9J6bszPsbV5uwmrVjN+7e19M8bd2rp3+e67vbEzmvCPnLPR+KAREezGXyrCy51C3VIxm+2fFlRrhZ07vF9Dn7XeF2vCU0BTUfdJkloXjmy4=; 20:G8XA5A0qMUfJ7omJcdnP0hHf9MooGd6AKsMvdzZWXD8nzKouLz5xDg28eyfFfRYBJCZYE2BBfDWnshlaGy3AOw==
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:SN1PR06MB1838;
x-microsoft-antispam-prvs: <SN1PR06MB1838A75DB1AEADBA1D6A9887BF2A0@SN1PR06MB1838.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR06MB1838; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1838;
x-forefront-prvs: 0750463DC9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(18543002)(24454002)(189002)(27574002)(5403001)(199003)(10533003)(164054003)(50986999)(106356001)(450100001)(40100003)(110136002)(87936001)(66066001)(83716003)(5001960100002)(77096005)(76176999)(106116001)(122556002)(92566002)(15975445007)(19580395003)(54356999)(19580405001)(2950100001)(2900100001)(5002640100001)(105586002)(101416001)(189998001)(10400500002)(36756003)(97736004)(81156007)(2351001)(102836002)(82746002)(33656002)(5004730100002)(5007970100001)(561944003)(99286002)(15974865002)(86362001)(5008740100001)(2501003)(11100500001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR06MB1838; H:SN1PR06MB1839.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 01:05:16.0087 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB1838
X-Microsoft-Exchange-Diagnostics: 1; SN1PR06MB1744; 2:iMBIVnRUs2VzYZbDAFTp2x22a51PpiWdN24Cf6bOLbB7aPTaW8RNTudr9qnc7Y/YXIbggPHdKjPGTfKj+R/3oU5l02U+RwCb/X9vEFV1Y/WO+MSV5naBrDplhj5jvF+jH3pqOosKgwrCC9bMLi5hN2vD1eWN7UMYn1QytvqAaSw=; 23:VidHAXLtFEmlVKwBdcfSS/R5Ort8+AWSouQ5HPsWmGj5WyXvNqhJHHekiDeGzBAS0mUkoYhZgfQiIXG7VjQC2I0IsMkK2UKI+uL5xuxeWYeFubsrVx4Rl0nej3V4cSA9OyhaVVmjqYO5jQcVWfKWnvGHddEqUEHJ+eRj8EG0PNNGOcPZHNJKd9JyMcDApg1j
X-OriginatorOrg: isoc.org
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/qjTkzkrvOBfaSq8wA2OVDQ1M1qk>
Subject: Re: [openpgp] openpgp Digest, Vol 30, Issue 7
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2015 01:05:22 -0000



On 4 Nov 2015, at 05:00, "openpgp-request@ietf.org" <openpgp-request@ietf.org> wrote:

> Send openpgp mailing list submissions to
>    openpgp@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://www.ietf.org/mailman/listinfo/openpgp
> or, via email, send a message with subject or body 'help' to
>    openpgp-request@ietf.org
> 
> You can reach the person managing the list at
>    openpgp-owner@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openpgp digest..."
> Today's Topics:
> 
>   1. Re: Reducing the meta-data leak (Derek Atkins)
>   2. Re: Reducing the meta-data leak (Neal H. Walfield)
> "Neal H. Walfield" <neal@walfield.org> writes:
> 
>> Hi,
>> 
>> At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly,
>> suggested that we should try and hide more meta-data.  For instance,
>> instead of listing the recipients, someone decrypting a message would
>> try each of their available secret keys in turn.  Werner pointed out
>> that these probes are a pain for people who use a passphrase protected
>> key and I mentioned that it is a pain for people who use a smartcard,
>> in paritcular, those who use more than one smartcard.
>> 
>> What about using a bloom filter for encoding the recipients?  This, of
>> course, doesn't eliminate the meta-data leak and it can lead to false
>> positives (= gratuitious passphrase prompts / smartcard prompts), but
>> it should reduce the metadata leak a fair amount, I think.  Thoughts?
> 
> There was an extension at one point where you use the string 0x00...00
> for the keyID and that forced you to test all your secret keys.  There
> are certainly times where that is warranted; there are other times where
> it is not.

Right. What struck me about the proposed approach was the difficulty of using it in the other problematic use-case DKG described during the meeting - where someone has sent you a 5Gb cipher text (or, worse, a stream) and you have to decrypt some or all of it before you can tell whether you're using the right key or not.

I suspect the answer is to recognise that not all metadata is equal, and that it may be appropriate to have different levels of protection (including zero) for different items of metadata.

For example: if "recipient" is sent in clear, it simplifies the task of identifying the right key to use, but it would then be up to the communicating parties to decide whether they should use other means to protect their identities... The remaining metadata (such as algorithm identifier and parameters) could potentially be protected by other means. 

R 


> 
> I wasn't at the meeting (in person or virtually) so I'm not sure I
> completely understand what the use-case is where the above solution
> doesn't work?
> 
>> Thanks,
>> 
>> :) Neal
> 
> -derek
> -- 
>       Derek Atkins                 617-623-3745
>       derek@ihtfp.com             www.ihtfp.com
>       Computer and Internet Security Consultant
> 
> 
> At Tue, 03 Nov 2015 09:30:48 -0500,
> Derek Atkins wrote:
>> "Neal H. Walfield" <neal@walfield.org> writes:
>>> At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly,
>>> suggested that we should try and hide more meta-data.  For instance,
>>> instead of listing the recipients, someone decrypting a message would
>>> try each of their available secret keys in turn.  Werner pointed out
>>> that these probes are a pain for people who use a passphrase protected
>>> key and I mentioned that it is a pain for people who use a smartcard,
>>> in paritcular, those who use more than one smartcard.
>>> 
>>> What about using a bloom filter for encoding the recipients?  This, of
>>> course, doesn't eliminate the meta-data leak and it can lead to false
>>> positives (= gratuitious passphrase prompts / smartcard prompts), but
>>> it should reduce the metadata leak a fair amount, I think.  Thoughts?
>> 
>> There was an extension at one point where you use the string 0x00...00
>> for the keyID and that forced you to test all your secret keys.  There
>> are certainly times where that is warranted; there are other times where
>> it is not.
>> 
>> I wasn't at the meeting (in person or virtually) so I'm not sure I
>> completely understand what the use-case is where the above solution
>> doesn't work?
> 
> Bryan Ford proposed getting rid of all unencrypted meta-data.  In
> particular, he wanted to get rid of the recipients / number of
> recipients.
> 
> There are some practical difficulties with this approach,
> which I mentioned above.
> 
> My proposal is a blue sky idea to avoid having to try to decrypt a
> message with every secret key while (hopefully) making it more
> difficult to get at the list of recipients.
> 
> Neal
> 
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp