Re: [openpgp] Disabling compression in OpenPGP

[Jon Callas <[e-mail]>]

> 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