Re: [openpgp] Hashing literal (meta)data fields

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 12 October 2022 07:14 UTC

Return-Path: <dkg@fifthhorseman.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 BBBFAC152575 for <openpgp@ietfa.amsl.com>; Wed, 12 Oct 2022 00:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=5u6fdFb7; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=SJ+h2gms
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 OgEzxGV5Jqer for <openpgp@ietfa.amsl.com>; Wed, 12 Oct 2022 00:14:51 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A730BC14F733 for <openpgp@ietf.org>; Wed, 12 Oct 2022 00:14:51 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1665558889; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=4eRyPVCNkDz6Djfl9J7x5EhuRogrvQQACu88TEjkFoE=; b=5u6fdFb7cLLiuslmm0+ezFJU1bMQtMn2ch7DrO1v7Ogs2vn9kFwmyx6bx8vxLJTBrahvv w2fhSaD2itOFxvkAQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1665558889; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=4eRyPVCNkDz6Djfl9J7x5EhuRogrvQQACu88TEjkFoE=; b=SJ+h2gmsmU35Lt+6sVVAaRX/piukNYHvv7piIXI+uaNPtKbqd4ZvOJ3lrB1qG7n7B8n7X L2A55Ew7KE0g3YSjOI65LxJ3iYPdiO+LvXuj6oEf6PY5wrxSdBDUBiT4i8l754pl1RHkbYM qxHfFpiafL9sFVy2V6Lb3SsB08CVBRC0aktcZx0n3cFFEUHs6gg/c2aEAgmhaOxsZrLj7BH RSaksuvdCSCLh/2iopuFBaz2d4FkZSysccBqxiFtH1DhmPAC7PptKasN0u3jJl31HW5SCVS Bl0F8PfahPlmje1Wbh6AbKtrCr3Bp4uVxErkDgEg4ADsXZphh3mO0VlNaY3Q==
Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 37FBDF9B1 for <openpgp@ietf.org>; Wed, 12 Oct 2022 03:14:48 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 6963A2193E; Wed, 12 Oct 2022 03:14:46 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: IETF OpenPGP WG <openpgp@ietf.org>
In-Reply-To: <x-TTXFnrRTUXYg6jCqww9hBjSKYQKxUDGU47PBt3WQxZDh75N-zvrUT1Qu45lY5Eg4gHHlKPHYTxGGFGh_vbaSccBpHUW9FIATapMgd2dNA=@protonmail.com>
References: <QiAK3LsKi6K_UDPKI3S2vWACTHIL2CWil-AmjadkkA9XQrrdoDSuAT5UwwQCqseLMaStR4XuM04rfSoTSzXZEsNLIp3Z8_7C7Xu4Nxab1eE=@protonmail.com> <87lepmvlwn.fsf@thinkbox> <x-TTXFnrRTUXYg6jCqww9hBjSKYQKxUDGU47PBt3WQxZDh75N-zvrUT1Qu45lY5Eg4gHHlKPHYTxGGFGh_vbaSccBpHUW9FIATapMgd2dNA=@protonmail.com>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Wed, 12 Oct 2022 03:14:45 -0400
Message-ID: <87ilkp5x96.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/7aj0l-GPHSr_SIQZXnlzuDjAFCI>
Subject: Re: [openpgp] Hashing literal (meta)data fields
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: Wed, 12 Oct 2022 07:14:56 -0000

I'm going to number the features/concerns that Daniel identified
upthread about signing these literal data packet metadata fields,
because i think they offer a useful frame for the discussion:

Daniel Huigens wrote:

> (1) it's not clear how to populate the fields in an encrypt-then-sign scenario
>
> (2) they make it impossible to be able to cleanly detach and reattach signatures
>
> (3) when those fields are sometimes signed (v5) and sometimes not (v4), it's difficult to act on them safely

With no hats on, I am not convinced that the proposed hashed literal
data meta packet solves any of these points.

it clearly doesn't address (1) or (2), and for (3), it only makes it
*possible* to add this metadata to v4 signatures, but of course it's not
guaranteed that it'll be there.  What should a consuming implementation
do that wants to use these fields?

If we're going to provide a secure mechanism that offers this metadata
securely in some packets and not others (that is, admit that (3) is
unsolvable), it seems easier tackle that with the notations that Justus
proposes below, and accept that the verifying implementation should
ignore the stuff in the actual literal data packet fields and look only
in the relevant notations that happen to be in the hashed subpackets.

On Tue 2022-10-11 12:11:45 +0000, Daniel Huigens wrote:
> [justus wrote:]
>> Instead, one could simply add notations to the signature to specify say
>> creation time, modification time, and filename. With this scheme, one
>> can better specify the semantics, lift the file name length restriction,
>> it doesn't require specifying how to hash the metadata, and it isn't an
>> all-or-nothing thing. As a bonus, if you detach the signature, the
>> information is still available, so you can make use of it, and
>> re-attaching the signature is possible and easy.
>
> Yeah, I agree, that might be better, indeed.

I agree, this approach seems to at least clearly solve (2).  I don't
think it does much to address (1) unless we start experimenting with
pruning the grammar (along the lines of what Paul Schaub was proposing
in the last week), but i think that's pretty far out of scope for the
current WG charter.

    --dkg