Re: [openpgp] Should signatures be rejected if the embedded hash prefix does not match?

Paul Schaub <vanitasvitae@riseup.net> Thu, 02 March 2023 15:24 UTC

Return-Path: <vanitasvitae@riseup.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 4A95AC152EE5 for <openpgp@ietfa.amsl.com>; Thu, 2 Mar 2023 07:24:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net
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 HhDWeGcrIE89 for <openpgp@ietfa.amsl.com>; Thu, 2 Mar 2023 07:24:16 -0800 (PST)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 42D30C14F74B for <openpgp@ietf.org>; Thu, 2 Mar 2023 07:24:16 -0800 (PST)
Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (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 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4PSFJH4tN8zDqJM; Thu, 2 Mar 2023 15:24:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1677770655; bh=1DSLhf04P1RIXCwVx15pBal9VEF+y/ZBBaAkvEKUwEc=; h=Date:From:To:Subject:In-Reply-To:References:From; b=OmNbefwf2aGI+JYrEumjkaW0G+JP1P0W+QdfpUOHUxGLF7NDv0LmJuefeji6TWgWD BX1/GTmaR4vkC5QUvJPw443QcKvTENaNQJ5vL0uP4Jdelg2Icj6iZB23swSMezqb1+ rHo2mSuekOLwVCZS/bf4KuWx5Pp8QETg+eq0sZqk=
X-Riseup-User-ID: FA6010A200BD0DA4C2BB08C12F5E92435962A7254CB3653094DC174FA0E1C320
Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4PSFJG46Mcz5vgM; Thu, 2 Mar 2023 15:24:14 +0000 (UTC)
Date: Thu, 02 Mar 2023 16:24:08 +0100
From: Paul Schaub <vanitasvitae@riseup.net>
To: openpgp@ietf.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
In-Reply-To: <87y1ofqm83.fsf@fifthhorseman.net>
References: <87lekkts65.fsf@fifthhorseman.net> <d759691a-c447-f66d-b839-f1b87e6b89af@andrewg.com> <87y1oj5ltj.fsf@europ.lan> <edeb91b0-6e7e-fa35-c571-d16dff433871@andrewg.com> <87v8jn5e4k.fsf@europ.lan> <55c56429-e1b1-97d3-5ad3-c54a69428143@andrewg.com> <87sfer588g.fsf@europ.lan> <b2a78baa-4636-9353-e079-232d580806a0@andrewg.com> <87o7pe69m6.fsf@europ.lan> <6lLcuziqTC31StjVfWBQYzemBHmXkVQG_LV6cIQ1lQU7qtOTr-HKCRHzxSY5LXsFU_BnnElSN0zry-RGK8TtC5cM_Ab4KsuWSPON8-82ZOM=@protonmail.com> <ebd88ec4-787b-fea7-f822-e6b514343dba@andrewg.com> <87wn41ru96.fsf@fifthhorseman.net> <87cz5sbsv3.fsf@europ.lan> <2ae335f9-b36a-f5e1-8668-b94a805b709e@andrewg.com> <87lekgs64c.fsf@fifthhorseman.net> <fb3a9276-f948-73dc-af81-46dfa9b02209@andrewg.com> <87a60vbi7n.fsf@europ.lan> <5ba74a57-c039-5ab8-45bc-30ae681bc8c8@andrewg.com> <877cvzbet0.fsf@europ.lan> <c8bc1904-dcaf-6ab9-1f16-85a0a2761c6f@andrewg.com> <87y1ofqm83.fsf@fifthhorseman.net>
Message-ID: <BCE2A915-AE8C-49A7-892E-39D15D54C462@riseup.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----A3LDWO9F4C6WN80OIZ0V3H2094Z1B1"
Content-Transfer-Encoding: 7bit
Autocrypt: addr=vanitasvitae@riseup.net; keydata= mQINBFfz1ucBEADXSvUjnOWSzgW5hXki1xUpGv7vacT8XqqGbO9Z32P3eFxa4E9JvveJmx+voxRW pleZ/L6XCYYmCKnagjF0fMxFD1Zxicp5tzbruC1cm/Els0IJVjFVRLke3SegTHxHncA8+BYn2k/V nTKwDXzP0ZLyc7mUbDl8CCtWGGUkXpaa7WyZIA/qmvUqh7671Vr4vJlq0kFbUibsFblZjk9uydHv vqaVpmBzbr/gWDyirHXwPl5lCnWpORjT7tc8hjyt+dxpmnGdqlDIcqUjdCWoN6NxffLtKz/XpJ+d BvA8rXT/QaPSaVCGo0DbgybvRF1HvX30udx4FF9fFsVAbYP1mvZx4fHy+Z1rJJhODZv1YpH7YY1b mG02vfFkwpW4AyAdsONA+n/XdMCsA006/pljNd3GxjcqB5D6BhpdUvcgUslkuELsVYWbEyhxKzzJ vZNjQ/iHsaThooy9SFHc71PgYdyEL/WzoGr421GwpCL6BuE0rlumgaTmjoU/9ydLO6zpbV4RYDgt saGQxOxVc0y1Lj8CWTi/XYIVRnmqrjGmubRV7q8pTxrgoyk2zwQ+twyxp/8ZRHzl5ISiDLKSDlcM K1oa7NqyL+MCwiswpaObk56HxgF2ZwEbJZYCwetxyTK7HX4/WV0V6TaPzS7dHAsb6t1Aq8IS1JdG jWKRPkjkhR95nQARAQABtCVQYXVsIFNjaGF1YiA8dmFuaXRhc3ZpdGFlQHJpc2V1cC5uZXQ+iQS+ BBMBCgKoAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAFiEEf5EW/qkKWYOTbHz6oCfbLz4eEYoF AmAMGzk1FIAAAAAAEgAacHJvb2ZAbWV0YWNvZGUuYml6ZG5zOmphYmJlcmhlYWQudGs/dHlwZT1U WFQ+FIAAAAAAEgAjcHJvb2ZAbWV0YWNvZGUuYml6aHR0cHM6Ly9mb3NzdG9kb24ub3JnL0B2YW5p dGFzdml0YWWQFIAAAAAAEgB1cHJvb2ZAbWV0YWNvZGUuYml6eG1wcDp2YW5pdGFzdml0YWVAamFi YmVyaGVhZC50az9vbWVtby1zaWQtMjA5MzY4MTU0NT02Mjg5YWEzYmQ4YTUwMWEzNjMyMmEwZjg5 NGY4ZDFkOTcxOGRlZDAzNjE2MDM5ZjFjZjQ4YjJhNDFlZTM1OTIwjxSAAAAAABIAdHByb29mQG1l dGFjb2RlLmJpenhtcHA6dmFuaXRhc3ZpdGFlQGphYmJlcmhlYWQudGs/b21lbW8tc2lkLTE5OTE0 MTgyMD1mNGE4ZmY4NDAwNDM5M2E4N2Y3MDEzYzYwMDY1YmRjODliMTE2OWViY2ZiODA2MGM0Zjk2 NjliNDNiYTBjODE0kBSAAAAAABIAdXByb29mQG1ldGFjb2RlLmJpenhtcHA6dmFuaXRhc3ZpdGFl QGphYmJlcmhlYWQudGs/b21lbW8tc2lkLTE0Mjk2NzcxMjU9ZThhN2IxMjM2Yjg1MGI0NjdhNTA5 MmMwYmRmZWE4NmE1M2UzNjg0MjgzYTFkNWZlMjZlZjU4NzJkZDBhZWY0MUgUgAAAAAASAC1wcm9v ZkBtZXRhY29kZS5iaXpodHRwczovL2NvZGViZXJnLm9yZy92YW5pdGFzdml0YWUvZ2l0ZWFfcHJv b2YACgkQoCfbLz4eEYrCxQ//Wjn7sEx+1rWCxVIQG9qqYJkMrSMvsyjeDZJrKLD5o5XIVQhjL/9g t3hBkYiOftarTXmmMD+xLAAS1netQTvgAJuLb1gypKqB8wG+4Po7e7ZO9XTLkjqjMZSTA/ZyJw2V fGdw40oGl8NEZrVUMiDiCEYzv8CXgBoEwiE0BA4lLUWKh9dnuonuMornsFjx7W5R+DQoKE+//G7b XCuErLwO6wHPs9K3xLwoG2Kyy3wyr57DystEVtnQX+XlWC9251VJpHWaZJOhG+YqCLZEeMizuGUQ TBGv51YY71JpbSjE1tXKAyU/+ksSfVH1T3i0DEMteCZoNgvY01fDKRrm4EouzLV0depe6Qo9LynL Y9mG7YUkwtTT6aX6zaRNsDYHN7uyVE66IY8mD1bOi8JBhUNqbx5p8YMwLpDf3cdcf6DGrb0tGDYu 6V/g0m2iw7glVs7LN55F3kWVmRSInu9uJWojMY3yN6Xwyv800oJyhyTCavLW7ckCvCA1KpH5S/4J 4fjjpuaV9nomvApZBFy4pVF+tca5PjpiagVJomOOVMBNRXFxS5A2QWVDpuJuZ3MSYVoqlVJBR/yB ecSMuHvwruR3HzVz1yYhTgau6Ura7MZBQu3dSArK3Kth/kQ7CqdusMOEBhEXByVthGO89RlKVNag Kji7vaA67F1FYODJr0hzRie5Ag0EV/PW5wEQALNTc5Gh0TR1rtmIkJPJU3LXIhY8jJVR/1ctvMmU n6R1q7ezAs4ZGitT2LFpZyYnzpQp788g1tuqLi6mz0edZc0RbPVCA9Xc4OEQrjzLNE8JSH3FAmwU XN5atwJ/eNbBMA9PoILhqINaCLptq3oAH7Z20qEI/9fjqGWc9M6ng5B6K0HAg03NxH2LC47MIhYq IqDj1oD4xug0mt/cX9O2Ha1tAzsKSfzPjAlaD8URKm1wv6AmFEPOYeFeumvGDGK5pHh86tZLl+x1 7qCSrV/Ft7xwoj6P7FP8Be+G9KA4rJH3l8DGmaEYVT5GBgRCIQDup/balrbks8VpjFh/0w8PIdhj OoQmuu2D1bok587TXa/BUfQ91haXIs6WzSRY+hwXK3zuiMA+TSvIeX4qhXiEACH6NTy/PDgvIw1Y 7HBdGKCXgoiPLERYz/9cvzG2GiiEeHwPj26IHlv5JRniPG6ePXRkGvvHJ64A3J8zUtU14dWXGqG/ R/gwx3Ugjd+4R7X66BQwQq+ikUOeVswU3Ufs5om2Q45BmOE9LmkIxUABrITzRnK+t6wklsmZyJ8d R+FlsJ7FKrk7e0/qrdEwDn3fvbIYD6s/3SypJBfO5gbUuNt3RnQ6egWSebeJaZfCxokrpPaf3JKA eDBE/tYi42lPhRAixciIPeb+hpNTmBcXg55xABEBAAGJAn4EGAEIAHIFgl/4kEMJEKAn2y8+HhGK RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXVvaWEtcGdwLm9yZ2FgE3f7bnBndxQ4h2+ACXWf TabWwHHHGpI9ZqZhZTBJAhsMFiEEf5EW/qkKWYOTbHz6oCfbLz4eEYoAADAdD/0Szb4rHGgdyItG SzLOsEDrGJCfztXOH5vGo5s/meZYBIYFW3hYZrKiRyIJP54uFHHRwLCiAcH3FcWT80fpx9YOQiHf xNpmVwnAoufOmfI8p/G9+Fcf62HSVZKsgS9zrUvhDjAUTrwOVbDVqyFZtAaxqsxI5tJilLkZXaWc ozUcw9m3iEyZDgpNR/1arfmwl5sW9mpG/tOmwdDaihvpI0b5Qp0sAb2fkcol1aznnqI+Dg4BsrWt FvkbZ6GvgF6a+SROrgXN2fr4Gaw53agYA/0mVF4zQv/2NzOqsX44vOHvB15hc7mXHJks8B/jqejJ YeF4j4asZi+fwCaBPEMQlJwm+JhDXJ3xnZp5Zlhq2wKTZHZm94Vw16WQic0WIHT7VBLlief5pZtP e/f2xfG9BzdHghtOlaqDYvp0jW3rYe3/+ILHqutA6XCWn+JRlbPQII1xTRlksmZh7hcDPlKXx2Yk V36a24pQe2QYX4cfXdDGe5bshQGtSHQo2926Xb2TD0ksfMaFuKG3LhMVWsicyc9RwnlsK98GLs1e EpFm0pt2FjgXyvRGhnNkaIE7vPXrJsgsFtrrJXEq52Eug6dJQnAtQl7CpWSlldhmYG2QFCPsO0+9 VE+A8Pz+Kjr7iiH6rw9kidGX6CqFdaGuWDR6qbCVJpnPlF5n02YHz9eMcwVMlQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/_c9uOuKwwSq0VS9MsXah04qVuUY>
Subject: Re: [openpgp] Should signatures be rejected if the embedded hash prefix does not match?
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: Thu, 02 Mar 2023 15:24:20 -0000

!213 sounds sensible to me.

Paul

Am 2. März 2023 15:09:00 MEZ schrieb Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
>On Thu 2023-03-02 13:36:57 +0000, Andrew Gallagher wrote:
>> It does not matter whether you think RFC4880 allowed lenient behaviour 
>> or not. What matters is that enough other people thought that it did, so 
>> there are now permanent facts on the ground that you are powerless to 
>> undo. Neither of us LIKE this scenario. I'm just not prepared to punish 
>> github users for a historical error that a) they had no hand in, b) has 
>> no known security implications, and c) nobody, not even github 
>> themselves, can now fix.
>
>To be fair, Github *can* fix their v4 signatures and their certificates
>going forward.  It does not appear that they have done so.
>
>Surely there are invalid OpenPGP signatures (not just malformed due to a
>bad digest prefix) scattered throughout git repositories everywhere just
>because people make mistakes (or the keys that issued them are now
>revoked, etc) and modification-aware systems like git don't really let
>people undo things of this nature.
>
>Having some implementations that are strict about v4 signatures might
>provide some pressure on Github to correct their signatures (and their
>public key) going forward, and if the result is that those
>implementations can't (or won't) validate legacy signatures, that's just
>a larger pool of invalid signatures for those implementations.
>
>> I withdraw my proposal.
>
>Can we get a consensus read from the group about whether the proposal as
>it stands in !213 is acceptable?
>
>The proposal adds this single sentence to the crypto-refresh:
>
>    When verifying a v6 signature, an implementation MUST reject the
>    signature if these octets don't match the first two octets of the
>    computed hash.
>
>I'm not asking for a consensus about whether this is *everything* you'd
>like to see (this conversation has made it clear to me that there are
>strongly-held opinions within the group about desired-yet-conflicting
>additional clarifications about v3 and v4 signatures).
>
>I'm asking whether you approve of this particular addition, as it
>stands.  I don't think i've heard any objections from the group about
>mandating this strictness for v6 signature verifications.
>
>Please send a short note if you approve.  If you don't approve, please
>let the list know; and if you could explain your objection, that would
>be great too.
>
>          --dkg