Re: [openpgp] incomplete/confusing guidance around "Hash" Armor header for cleartext signing framework

"brian m. carlson" <sandals@crustytoothpaste.net> Thu, 18 March 2021 23:00 UTC

Return-Path: <sandals@crustytoothpaste.net>
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 C00793A0D25 for <openpgp@ietfa.amsl.com>; Thu, 18 Mar 2021 16:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net
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 3pmhcmgc5kie for <openpgp@ietfa.amsl.com>; Thu, 18 Mar 2021 16:00:15 -0700 (PDT)
Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F773A0D24 for <openpgp@ietf.org>; Thu, 18 Mar 2021 16:00:14 -0700 (PDT)
Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id D44436046C for <openpgp@ietf.org>; Thu, 18 Mar 2021 22:59:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1616108384; bh=z0bKVHnhnLhWVusrHOdLwcJomowaxxIal1nFiy50MeM=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=gY2npM2Peh0ki53H784I/WJM4FObtqorZbUg1ByxMrl9k8l/GkM9CxsG1fSEe6ekj aYTsJCXM43iCj93jrbsTW2mGQRSYcm57+4snPLxQIbTa7lT82XQMWfuHeMdj/nnE7S bwtZhRegM/i8TH5GJOHmCBJ23uyukE3YVagDS6Mn32K2l7682fRnvxTVET/V9B87V8 ejA9Jl4KnZhx7whMuB7g3eglHcx44t+e45MQx/EGZxMaEnFjzeazCyWuj1pDlXtLy3 S9MCxNYA1D+cwqsPkz63Pmc/dyF07CIUneh34D8WlKHf2vV8CbzeQVqel1QwSWSKWB wfmodpB2ZcMCmxixNAUKOv1/Jf/h5YFe1Dq4s1WCRzfzGD4U9WcYYiW1SZj+eV5mlk 8F7QR2nMCe6cqfteyS6Yl2D/onA8070OZB26YoFVO0Vj1NZkdSDrFQmB5ePdCkr4f6 r5/uFyCjfYC/v4qzHxXcart1v/RMLRg/MtM4TCbZBtaEquxYur3
Date: Thu, 18 Mar 2021 22:59:39 +0000
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: openpgp@ietf.org
Message-ID: <YFPbW9BLDdCn4E7I@camp.crustytoothpaste.net>
References: <875z1p7vva.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q6m+d16gvOV2OWUV"
Content-Disposition: inline
In-Reply-To: <875z1p7vva.fsf@fifthhorseman.net>
User-Agent: Mutt/2.0.5 (2021-01-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/4gIbgVodeczxRbdji-qS5b_d_kM>
Subject: Re: [openpgp] incomplete/confusing guidance around "Hash" Armor header for cleartext signing framework
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, 18 Mar 2021 23:00:17 -0000

On 2021-03-17 at 13:28:09, Daniel Kahn Gillmor wrote:
> (no hats on, just noticed a textual problem and wanted to record it on
> the list)
> 
> The current draft (and RFC 4880) seems internally inconsistent about the
> mandatory nature of the "Hash" armor header in the Cleartext Signing
> Framwork section.
> 
> In particular, it defines 'one or more "Hash" Armor Headers' as an
> official part of what a clearsigned message looks like, but then it
> discusses what it means when such a header is absent.  (and, when the
> header is absent, it says it uses MD5, yikes -- that makes this relevant
> to the crypto refresh).
> 
> Additionally, though multiple headers could be present, "If more than
> one message digest is used in the signature, the "Hash" armor header
> contains a comma-delimited list of used message digests."
> 
> Finally, what should an implementation do if the hash header doesn't
> match the digests found in the actual signature?
> 
> This text should be reworked to make the expectations clearer, both for
> those generating such a message and for those consuming it.  And it
> should *not* encourage the use of MD5.

I agree that MD5 is right out.  If we expect implementations to need
this to process a message correctly, then it should be mandatory, since
if someone really wants to use MD5, they should be fine declaring that
up front.  Practically, though, nobody will want to use MD5 for that
purpose, because a signature with MD5 doesn't tell you anything
interesting about the integrity of the message, so everyone will need to
declare a hash.

In my implementation, I would personally choose to instantiate only the
provided algorithms, and as such, I would return an error if the values
did not include the required algorithms, failing the operation.
Alternative implementations might choose to instantiate all digests and
just pick the ones they need at the end, at the cost of additional
computational power.  I don't have a strong preference as to what we do,
but I would like to leave the former possibility open because it
drastically simplifies fast one-pass streaming implementations,
especially if the clearsigned data is large.

I also agree with Werner that Charset is no longer interesting and we
should just use UTF-8.  The encoding practically needs to be
ASCII-compatible so that the delimiters and dash stuffing work, so other
Unicode encodings are out, and generally non-Unicode encodings are
considered obsolete.  That does exclude the possibility that someone
uses a mostly text-compatible binary body there that gracefully handles
newline conversions, but I feel like that's unlikely.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US