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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp