Re: [openpgp] Disabling compression in OpenPGP

Jon Callas <jon@callas.org> Wed, 19 March 2014 21:38 UTC

Return-Path: <jon@callas.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 CC49F1A0724 for <openpgp@ietfa.amsl.com>; Wed, 19 Mar 2014 14:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lzYFXI5-mKVl for <openpgp@ietfa.amsl.com>; Wed, 19 Mar 2014 14:38:03 -0700 (PDT)
Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id B8E611A07A1 for <openpgp@ietf.org>; Wed, 19 Mar 2014 14:38:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 478AD4F9B94F; Wed, 19 Mar 2014 14:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at merrymeet.com
Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5O5RzytekUM; Wed, 19 Mar 2014 14:37:52 -0700 (PDT)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 20DCC4F9B938; Wed, 19 Mar 2014 14:37:52 -0700 (PDT)
Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 19 Mar 2014 14:37:52 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 19 Mar 2014 14:37:52 -0700
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Jon Callas <jon@callas.org>
In-Reply-To: <20140319205517.GA6566@savin>
Date: Wed, 19 Mar 2014 14:37:50 -0700
Message-Id: <A0C19881-6D00-40AF-80D6-372FF3A94E96@callas.org>
References: <CALR0uiJG6GcngWMUkg6NrP7_4uwf8+QDn6aMF-qonOpRMLdo3w@mail.gmail.com> <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <CALR0uiL0-Xp8E=F3idtzBkmRNLk7K_M_cqMt+i2HdNqaNkwn=w@mail.gmail.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <DE00E9BD-1D37-4750-B156-BBDC4B59DB7F@callas.org> <20140319205517.GA6566@savin>
To: Peter Todd <pete@petertodd.org>
X-Mailer: Apple Mail (2.1874)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/-TiAQhg1DjlbchMknnjYVVVJK1Y
Cc: David Shaw <dshaw@jabberwocky.com>, "openpgp@ietf.org OpenPGP" <openpgp@ietf.org>, Jon Callas <jon@callas.org>, Alfredo Pironti <alfredo.pironti@inria.fr>
Subject: Re: [openpgp] Disabling compression in OpenPGP
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: <http://www.ietf.org/mail-archive/web/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, 19 Mar 2014 21:38:06 -0000

> Having a completely unknown plaintext is the best case; having
> plaintexts that are not completely unknown to the attacker is both
> common, and reasonable to defend against.
> 
> If I knew that the plaintext was either 1KB worth of uncompressable binary garbage,
> or 1KB worth of text, it'd be pretty easy for me to figure out if I was
> looking at garbage or text.
> 
> Gregory Maxwell's example of the Wikipedia vote's privacy being broken
> by compression-by-default shows this is a real world risk that users are
> not thinking about.

But it proves nothing here. It's a really, really interesting exception case. We're talking about a default. We're also talking about the protocol definition, and not implementation software.

Compression is on by default because it improves security. It meets that goal. It is, however, a default. Defaults can be changed. Moreover, there's a way to work around the issue in the existing standard. Make the vote-submission key not support compression. Poof, it works.

There are many, many other cases where it is *assumed* that compression is on by default, and that's the desired behavior for both security reasons and non-security reasons (like you want the object compressed as well as encrypted!)

When you design systems and software, one of the things you need to consider is defaults. Another is exceptions. But there's also installed base. 

Changing a standard is hard, and that's a feature, not a bug. The weaker that a standard is about something, the harder it is to change. Changing an implementation is easier, because it's just software. But there's also the issue of not only the defaults but the installed base.

If you went, for example, to someone who did an email plugin that did not expose compression and argue that they should not compress by default, you have an interesting case. I think it's still unproven, but it's interesting. I can even see the worth of turning compression off in a lot of cases. However, there are still many people who consider default compression a feature and *rely* on it for their system.

If you went to the gpg people and asked for "-z 0" (which turns off compression) to be the default, it would be a very bad idea because there's 20+ years of presumption that compression is on.

Moreover, it's very easy for anyone to opt out of compression. Put no compression in the key as a pref. 

Making a change to the standard requires a really good reason. Let's face it, even if it were easy to do, and we changed it from a SHOULD to a MAY, that would almost certainly result in no change to software because there's an expectation that it's the default across the user base and has been for twenty-some years. Changing the default in software is a really bad idea, absent a really big reason. If it went all the way from SHOULD to MUST NOT, you'd end up with lots of software even ignoring the new standard -- again, absent some compelling case.

Remember, the word SHOULD in a standard is guidance to an implementer that to do X unless there's a good reason. Any time there's a good reason, the implementation can do whatever it wants. That's it, it's merely guidance.

I'm going to repeat what I said and say that you need some actual security analysis that goes beyond finding a cool exception case. But I'll add that you might be better served by going to the people who make software and systems. It's very easy for them to do what you want. Heck, I've even made a system that does what you want, myself. (It wasn't for your reasons, though. It was because implementation constraints made it drop compression.)

	Jon