[openpgp] v5 in the crypto-refresh draft

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 04 June 2021 06:43 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 2FC723A2BC0 for <openpgp@ietfa.amsl.com>; Thu, 3 Jun 2021 23:43:02 -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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=S/h4f6xZ; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Q5nzh2fj
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 VJqanNRLTv_l for <openpgp@ietfa.amsl.com>; Thu, 3 Jun 2021 23:42:57 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE54D3A2C1D for <openpgp@ietf.org>; Thu, 3 Jun 2021 23:42:52 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622788970; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=c6Fdd/T3hgXDJyr2I9k5vO5B0bywMYB/KSpPB6vGpco=; b=S/h4f6xZyQQh3+VlPvT+UxSaPWRO6HC/1IkR1b5s6AnJgEI1iHTSJ2ctq69KOt6V+7xVh 5SkObVYspW9R6/VAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622788970; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=c6Fdd/T3hgXDJyr2I9k5vO5B0bywMYB/KSpPB6vGpco=; b=Q5nzh2fjuXiDkVJi072yCdMrdNuxzRzmzxN/7gbJF4xd8c0xkvgMmqhJyp1LoN+VODErO cmfKgIVqvSX6JMMO/zQEZUNGlPyCNK9ZZj5Laj/wgS7GUQA5krL3AoM03jXZTPbGkwUaJoD 2R/Hl94m6Uv7JV8xnrFGl+dJyWgs4wJBy2C7uB2/uS0AShPf0NZLf4RiRNO7cn5OFOf1/U8 DWWO3mQx7OSWuDGrHOrWKYOTwlszrUo3LJ39zKoLbJsOySyBLoiGF0y1UtsS4lMdB59A29m ZGjmF6YAIlGiOb3+XgAHqnoqx1ruAuiwjwQszUMjAoL0IwCAoZvy4CcHInCA==
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 RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id CD0EAF9A5 for <openpgp@ietf.org>; Fri, 4 Jun 2021 02:42:50 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id B792720362; Fri, 4 Jun 2021 02:42:36 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: openpgp@ietf.org
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: Fri, 04 Jun 2021 02:42:35 -0400
Message-ID: <87lf7q6sh0.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/DBYwqR01piQr6xjCGSy2jimASQo>
Subject: [openpgp] v5 in the crypto-refresh draft
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: Fri, 04 Jun 2021 06:43:02 -0000

I've been reviewing the changes in draft-ietf-openpgp-crypto-refresh-03.
I have concerns about most of the "v5" features currently incorporated.

One of the reasons that we need to complete the crypto refresh for
OpenPGP is that SHA1 is baked into the spec in the v4 fingerprint format.

The v5 fingerprint uses SHA256, which resolves that problem.  I have no
problems with that part.

But there are several other parts of the current draft that are
specified as "v5" that have unclear (or even harmful) utility to me and
don't seem to be part of any sort of cryptographic update.  I list them
below, with explanation, but i want to ask the WG for a sense of what
folks think we should do about them (either individually or entirely).
I see three fairly simple outcomes, but i welcome other suggestions.

Possible Outcomes
-----------------

 a) WG consensus that all of these are appropriate: keep them as-is

 b) WG consensus that some of them are misfeatures, or otherwise
    inappropriate for the crypto-refresh: drop the unwanted parts from
    the specification of v5.

 c) WG consensus that some of them are misfeatures but due to
    pre-standardization deployment that produced existing artifacts, we
    can't claw them back: call the new OpenPGP version "v6" and just
    skip over v5 (like IP!)

Note that for both (b) and (c) it's possible that the new version is
basically just "v4 but with a SHA256 fingerprint instead of SHA1".  I
don't think that's necessarily a bad outcome!

Specific v5 changes
-------------------

Here are the outstanding parts of "v5" that differ from "v4" as of
draft-ietf-openpgp-crypto-refresh-03 as far as i could tell.  If you see
others, please reply to this thread!

 0) v5 public keys have a 4-octet scalar that is the size of the
    algorithm-specific fields. 

 1) v5 secret keys have the same scalar described in 0, plus two
    additional length fields: a one-octet scalar field for the length of
    the S2K metadata, and a four-octet scalar field one for the secret
    key material.

 2) v5 certifications ("key signatures") hash a four-octet length of the
    subject key; v4 certifications hash instead a two-octet subject key
    length.

 3) v5 data signatures over a literal data packet hash an additional 3
     fields (or 6 zero octets for a cleartext or detached signature):
      - the one-octet content format,
      - the file name as a string (one octet length, followed by the file name),
      - a four-octet number that indicates a date.

 4) v5 data signatures hash the trailing length value as an eight-octet
    scalar, where v4 uses a four-octet scalar.


Detailed Discussion
-------------------

(0) and (1) appear to be duplicative of information already known by a
parser: in particular the packet length itself.  This appears to be an
opportunity for error/inconsistency.  What should implementations do if
that value differs from the length remaining in the packet itself?
    
The textual justification for these changes appears to be:

>> Note that the version 5 packet format adds two count values to help
>> parsing packets with unknown S2K or public key algorithms.

If the implementation doesn't know the public key or S2K algorithm, its
only real recourse is to skip the packet anyway, so it's not clear what
advantages these length fields offer.

-----

(2) appears to prepare for keys larger than 65536 octets.  This looks
like post-quantum planning to me, but we are not including any PQ
schemes in the specification, and it's not clear that this change on its
own would be sufficient to support such a new scheme (especially because
there doesn't seem to be any CFRG consensus on what PQ scheme to endorse
yet).

-----

(3) looks like it's trying to protect metadata that has not historically
been protected by OpenPGP.  However, it's also not clear how these
fields will be used; presumably existing security-conscious
implementations treat these fields as only-advisory anyway right now
when trying to (for example) extract cleartext into the filesystem.  But
even if they're signed they might get ignored -- for example, just
because the filename is cryptographically verified as "/etc/passwd"
doesn't mean that an OpenPGP decryption utility should extract to that
sensitive location.

For tools that want to embed filesystem information into the signed
data, it's of course possible to sign a tarball.  In that approach,
existing v4 signatures end up already covering the same metadata (and
more).

This change also has a consequence that it's not possible to transform
an embedded/inline signature into a detached or cleartext signature, or
vice versa, because detached or cleartext signatures have no place to
store the content byte, filename, or timestamp.  I've seen several use
cases where translating a signature between inline/embedded format and
detached or cleartext formats can be concretely useful.  In one example,
Debian's apt repository's Release, Release.gpg, and InRelease files
contain the same data and should be able to share cryptographic
signatures.

Furthermore, it's not clear how these fields should be populated in the
event that the signed "OpenPGP Message" is anything other than a
"Literal Data Packet".  For example, if the signature is made over a
Compressed Data Packet, and that Compressed Data Packet contains a
Literal Data Packet, how should those fields be populated when
generating or verifying the signature.

If we want a way to embed this kind of format/filesystem metadata into a
signature, it would be trivial to define a subpacket including this
information and include it in the Hashed Subpackets region of a
signature, which would retain the ability to translate between
detached/cleartext and inline/embedded signatures.

----

(4) appears to be an accomodation for signing data larger than 4GiB.  v4
keys can of course currently still sign data larger than 4GiB.  But as
the current draft clarifies, v4 signatures can still be made over data
larger than 4GiB because "The four-octet big-endian number is considered
to be an unsigned integer modulo 2^32."  It's not clear to me how this
existing approach with v4 could be practically abused; why not just
leave it?


Conclusion
----------

Open questions for the WG:

 - Did I miss any other currently-adopted v5 changes?

 - Are there deployed systems/artifacts that use these fields that we
   need to worry about interoperability with?

 - Are there concrete reasons to keep any of the specific changes
   mentioned above, despite the counterindications described above?


Regards,

        --dkg