[openpgp] Changes between rfc4880bis and crypto refresh (was: a new draft overlapping the WG draft)

Daniel Huigens <d.huigens@protonmail.com> Wed, 28 September 2022 09:10 UTC

Return-Path: <d.huigens@protonmail.com>
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 8C985C14CE26 for <openpgp@ietfa.amsl.com>; Wed, 28 Sep 2022 02:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 (2048-bit key) header.d=protonmail.com
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 EbBcN_B6A38F for <openpgp@ietfa.amsl.com>; Wed, 28 Sep 2022 02:10:49 -0700 (PDT)
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (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 7B106C14CF14 for <openpgp@ietf.org>; Wed, 28 Sep 2022 02:10:49 -0700 (PDT)
Date: Wed, 28 Sep 2022 09:10:40 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1664356246; x=1664615446; bh=gM0F1btRH/QpW7YPSy8osfK3LuqwoNrLOt4fynapIBU=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID; b=t2T9mHQSeE88Uw8wTn2MRBDYbwZz1mu9EwCu4ao+T1ofxUigtFMTFNv0g2jMLiatj oYvz9SvIYgYLwc9Jb0s+uO2Kr7jG5A8R08GA6V7w9mF9FrHfjRx5PynSaqiCKqcGy7 MZcW2lGtiRYcBZGNCoBz7tscaqrfxFCkRdA3cC+0hnsw+DjZHzqJ43cbYJBkcuVbfI ODinzwUixViQ9T2ApbpetsZ3U4VqqRSQ54XeSajm33zlVbi1A+LoJagM7p+Htc2lKP zywuW/ne+Fge2tbhfCh1r7BdE2rqAl2sviGLuy80a90vQPM1VQE6SFGrqen4zrLvOd op91OIch+mffA==
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
From: Daniel Huigens <d.huigens@protonmail.com>
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Kai Engert <kaie@kuix.de>, "openpgp@ietf.org" <openpgp@ietf.org>
Message-ID: <I19sAm-WYhkCMEIgIYkxhimNYz1lajgkTfjM7RQAYs6UOL2yzotAN5bdiV_TYkRj68qOfitm0ph_CK7SJcItwimnkVbl37Fb0AW-bouHYBY=@protonmail.com>
Feedback-ID: 2934448:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/aqBy97lj2P4DVxTds0eKZDVdmms>
Subject: [openpgp] Changes between rfc4880bis and crypto refresh (was: a new draft overlapping the WG draft)
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, 28 Sep 2022 09:10:53 -0000

Hi all,

I went through the diff and made a list of changes.


The crypto refresh specifies:

- Argon2
- Curve448
- GCM

- AEAD-encrypted messages using Sym. Encrypted Integrity Protected Data
  packet version 2 (with KDF to bind keys to AEAD modes)
- Feature flag for Symmetrically Encrypted Integrity Protected Data
  packet version 2
- Preferred AEAD Ciphersuites subpacket (for signaling support for AEAD
  + symmetric algorithm combinations)
- AEAD-encrypted private keys add the public key to the additional data
  (to protect against the vulnerabilities documented on kopenpgp.com)*

- Require implementing OCB (instead of EAX)
- Discourage using IDEA, TripleDES, or CAST5
- Require implementing Curve25519, and encourage implementing Curve448
- Deprecate DSA, ElGamal, and weak RSA keys

- Salted V5 signatures and the "SaltedHash" armor header*
- Deprecate Revocation Key subpacket in favor of an escrowed
  Revocation Signature

- Padding packet
- Require using UTF-8 and encourage Literal Data Packet format u (UTF-8)
  instead of t (text)
- Deprecate Literal Data Packet special filename _CONSOLE
- Discourage generating and checking the optional ASCII armor checksum
- Discourage old packet tag format

- A length field before the S2K specifier in V5 encrypted private keys
  and V5 SKESK packets, to aid parsing*
- V5 PKESK which specifies the recipient fingerprint rather than Key ID

- Specify unknown packet handling
- Various clarifications, recommendations, and guidance for implementors


RFC4880bis specifies:

- AEAD-encrypted messages using AEAD Encrypted Data packet (without KDF)
- Feature flag for AEAD Encrypted Data Packet (packet 20) and version 5
  Symmetric-Key Encrypted Session Key Packets (packet 3)
- Preferred AEAD Algorithms subpacket (for signaling support for AEAD
  algorithms)

- Restricted Encryption key flag
- Timestamping usage key flag

- Attested Key Signatures
- Attested Certifications subpacket
- Key Block subpacket (to include the public key making the signature)
- Registry for Signature Notation Data types

- Literal Data Packet format m (MIME)
- V5 signatures include the Literal Data Packet metadata in the hash
  (filename and date)*
- Literal Data Meta Hash subpacket (for certifying the filename and date
  of the Literal Data packet in V4 signatures)


* The items marked with an asterisk entail a difference in the wire
  format for the given packet (and version), causing an incompatibility
  between implementations of the crypto refresh and rfc4880bis. So those
  are perhaps the most important to come to an agreement on, in my view.

I may still have missed some things, but hopefully that's a mostly
comprehensive list. Please let me know if you see something missing.


I'll refrain from commenting further on individual changes in this
particular email, to keep it somewhat objective, but personally I think
we should try to keep the good ideas from both. From the beginning, the
process of the design team has been to merge stuff from rfc4880bis that
there is consensus on into the crypto refresh, and I think we could
continue doing so, if there's still energy in the design team to do so.

Best,
Daniel