Re: [openpgp] Backwards compatibility vs streaming verification of v6 clearsigned messages

Justus Winter <justus@sequoia-pgp.org> Sat, 27 May 2023 06:52 UTC

Return-Path: <justus@sequoia-pgp.org>
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 76741C151984 for <openpgp@ietfa.amsl.com>; Fri, 26 May 2023 23:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level:
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=sequoia-pgp.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa0Yu1kHu-5F for <openpgp@ietfa.amsl.com>; Fri, 26 May 2023 23:52:51 -0700 (PDT)
Received: from harrington.uberspace.de (harrington.uberspace.de [185.26.156.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3A3C151555 for <openpgp@ietf.org>; Fri, 26 May 2023 23:52:50 -0700 (PDT)
Received: (qmail 13268 invoked by uid 500); 27 May 2023 06:52:47 -0000
Authentication-Results: harrington.uberspace.de; auth=pass (plain)
From: Justus Winter <justus@sequoia-pgp.org>
To: Vincent Breitmoser <look=40my.amazin.horse@dmarc.ietf.org>, openpgp@ietf.org
In-Reply-To: <7c9f97df-f06b-6f87-3776-8f351289cb31@my.amazin.horse>
References: <LaSdaOASqnixctT3XuZHNIeldK2IPqJvHbqo_qkFjdrMBOQ4SKhiWl_76xq2P6l2Wts9rJ6MTTRLfpj9sqyG4_F4etjNcgEt6pmmtuyfsBY=@protonmail.com> <87h6s2hezc.fsf@fifthhorseman.net> <7c9f97df-f06b-6f87-3776-8f351289cb31@my.amazin.horse>
Date: Sat, 27 May 2023 08:52:46 +0200
Message-ID: <87bki66zb5.fsf@thinkbox>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Rspamd-Bar: -
X-Rspamd-Report: R_MISSING_CHARSET(0.5) MIME_GOOD(-0.2) SIGNED_PGP(-2) MID_RHS_NOT_FQDN(0.5) BAYES_HAM(-0.023815)
X-Rspamd-Score: -1.223815
Received: from unknown (HELO unkown) (::1) by harrington.uberspace.de (Haraka/3.0.1) with ESMTPSA; Sat, 27 May 2023 08:52:47 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sequoia-pgp.org; s=uberspace; h=from; bh=XhQ2CEcYGMGHECyeYY9mULtgzrmHYq+wxVcdhnmyUkc=; b=SeS130yzlGCMTpy2qyEz9Eq3D1hP6MfgpGqGJe3w/RMnD6OAH5aKNTvhfihz/SE4Gl7ZsYaQ/p uZf19ADyxl1ZbBvM+i7GO5d4H1fpdodEuOkePGcVkWbhi9hxASt4uROG3l2jeW+haECHMW7ot6aG fwpf9sIKjMryRbUJ0lMJrNeB2NANc88Bw6mEEO/h6gNCZ2X0zx83X6klLm1qT8LWq7xbMGIpCGJK QHP429vRhv+9MULA5O0jDrKn/s65yVws5xpwUcI410gIw+WjM67vtUmATWbfDsaLR7dwusZfwA2D rJsgkpIV5axBsy1o7DcgbZIlx4HFi7oWd+C73sJs10KfX8o2dXHFR4WpheMAfgT81z1uPy4jYkXG r8NavUQhSG77H4n0QWIkUX1UeYvGyYUJIa4ZrBHi4za007LC4h/RXrQPoizIXTlvBi30Z0k417Mr /N6YhXbKc8TLs5tPbZ9e+6oO3Z9932JWdePMBqTt+Ze6orBPOVbkApbTBTHlUq1mIdHTJHnqpcfl nYwHgUUNmA+9TermGG6qTfW/K6/oNfP8aBNKPfukxapUMrkAiz8y1Tr1B2tsjRBqFJM48wJjc0aq EF1814CN1VfCY6wfUZjCqCXWuXXwmyhsrSQV7aijhTfeBGKtDEQD5WDZh1slHiCRyQ1IJ3MZPPyz o=
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/UOoNXoH_rf4sPotvy8ffH1KoNAc>
Subject: Re: [openpgp] Backwards compatibility vs streaming verification of v6 clearsigned messages
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 27 May 2023 06:52:55 -0000

Vincent Breitmoser <look=40my.amazin.horse@dmarc.ietf.org> writes:

> Hey list,
>
>> Does anyone want to propose a fifth option that the WG should consider?
>> Anyone want to voice a preference for any of the above four options?
>
> I got one:
>
> # Drop CSF headers altogether
>
> CSF headers are pointless to the user at best, confusing or misleading 
> at worst. They are easily mangled along transports in ways that break 
> the signed message. We are also now in a situation where implementations 
> say "there must be exactly this one header, or we won't process the 
> message altogether".
>
> That's three bits of being problematic, so we better have a 
> justification for having it in the first place: That justification is 
> efficient processing. Similar to one-pass signatures, we can hash the 
> message right away and therefore verify the signature in a single pass.
>
> While that is for sure a nice technical property to have, I find it 
> questionable that CSF signed messages need any kind of "efficient" 
> processing by today's computing standards - they are meant to be easy 
> for humans to inspect and pass around, so will typically be a few 
> kilobytes in size or maybe a megabyte at most. It will routinely be 
> loaded into RAM in its entirety to display to users.
>
> Getting rid of the whole header discussion altogether, at the expense of 
> less efficient processing, sounds like a good deal to me. Maybe slap on 
> a notice that implementations should warn the user not to use it for 
> 500kb+ messages or so.

We talked about this at the OpenPGP email summit, and we agreed that
this is a good solution.  I have created a merge request where we can
fine-tune the change:

https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/313

Best,
Justus