Re: [openpgp] Deprecating compression support

Jon Callas <joncallas@icloud.com> Thu, 21 March 2019 22:37 UTC

Return-Path: <joncallas@icloud.com>
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 0E25C129A87 for <openpgp@ietfa.amsl.com>; Thu, 21 Mar 2019 15:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 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, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_MED=-2.3, 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 6kYT2-tmlWNj for <openpgp@ietfa.amsl.com>; Thu, 21 Mar 2019 15:37:51 -0700 (PDT)
Received: from mr85p00im-hyfv06021301.me.com (mr85p00im-hyfv06021301.me.com [17.58.23.188]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87301279A5 for <openpgp@ietf.org>; Thu, 21 Mar 2019 15:37:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553207869; bh=9jjeJzRv4OtyzqHKJ7+KpFN8P5g5XO4Rnc+sozOFIjo=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=tMwmvC5seKJhsM8CKFO8kxzbj7/I/ZKA6nefwElQ03BoyHGbSXeZBbkNb0BbG/04B CuhXH0ZWFTccfTyILkvJj6qn5WFGU83EMPH+k3Dh/kLrnnYK6ntwCYgFNHC6i3rFA4 RlDz6xLcXN9XtSSlLa3E4u0edV5fMtxt1q89uLGsBrdY3qRtTwJqcA38CKYmjm1DPe tGfv8MqFHeZNDRmO2VjmeLBI1AJVa6rbBOv18hCunwpRU/1qItRVEq5OOPhcv8Kqmj CVoVGqUs8FSjpUOg3fFj/3qMXMec4AUOe69rdOyle1luNt8kJqFW63CG1cTtQW3zLG 5c2XwVh7tM+Zw==
Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-hyfv06021301.me.com (Postfix) with ESMTPSA id 9EB0F40119; Thu, 21 Mar 2019 22:37:49 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Jon Callas <joncallas@icloud.com>
In-Reply-To: <CAAS2fgQdUdV5hmffPrsv=PR87rx+JuXH5NNkhKgcOcMxEnm8xw@mail.gmail.com>
Date: Thu, 21 Mar 2019 15:37:46 -0700
Cc: Jon Callas <joncallas@icloud.com>, "openpgp@ietf.org OpenPGP" <openpgp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E3D5147-2360-4F78-9AA6-02603AB1C095@icloud.com>
References: <871s3475dy.fsf@europa.jade-hamburg.de> <14617627-542E-4672-B83C-1B5E87561B50@icloud.com> <CAAS2fgQdUdV5hmffPrsv=PR87rx+JuXH5NNkhKgcOcMxEnm8xw@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-21_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903210157
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/dUKeCgpN4FwjYEpcOzLgR2PmoYU>
Subject: Re: [openpgp] Deprecating compression support
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 21 Mar 2019 22:37:53 -0000


> On Mar 20, 2019, at 5:30 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> 
> 
> https://mailarchive.ietf.org/arch/msg/openpgp/rG-X9rp2jlbyACoosnbxRXjCeys
> 
> I buy the combining encryption with compression being useful
> argument... but at the same time, openpgp compression is increasingly
> far from the state-of-the-widespread-art (e.g. xz) and there probably
> isn't much interest in updating it to chase the state of the art
> compression (and for short human texts, I think recent machine
> learning progress look like they're resulting in significantly higher
> amounts of compression, -- just no one has productionized that work
> yet).

I almost brought up that case, as I find it interesting and compelling, but it’s not the case we’re dealing with here, and I thought it would be some combination of trollish and a straw man, so I didn’t.

This is a case where there’s an issue. For those wanting a TL;DR, someone created a text ballot that got encrypted with OpenPGP and sent in an email. Because the encrypted ballot a single question and compressed to a different size, so you could tell who someone voted for by the size of the ballot (all other things being equal). [1]

This is a problem that’s worth looking at. (Also, I feel like I am a broken record here.) There is an existing workaround for this issue, and that’s to put a no-compression preference on the key people encrypt to. 

I believe this is yet another reason why the implementations might want to move towards compression off by default. 

That wasn’t what was said at the time — at the time, the debate was that because of this problem, compression should be banned in the standard, which is not only more problematic (as we’re seeing now, there are a lot of people who depend on it), and the slower way to handle things. 

I am quite sure you’re frustrated, and I am too. I agree that we ought to phase out compression, and there are a number of reasons for it. This is one of those reasons. I’m sure that I frustrate you, too, because I consider that case to be a minor reason. We are, however, on the same side on outcomes. Let’s concentrate on the outcome we agree with.

	Jon

[1] Getting rid of encryption does not completely solve the ballot problem; you still need to design the ballot properly. Here’s the counter example: Consider a ballot where someone writes in either “Alice” or “Bob.” This ballot leaks the choice because Alice’s votes are two bytes longer in length. A ballot that ships “[ ] Alice [ ] Bob” and asks to put an X between the appropriate brackets is much better ballot construction. It’s still possible to get that one wrong, too, either by accident or on purpose.