[openpgp] [RFC4880bis PATCH] Drop "Compatibility Profiles" section.

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 24 March 2021 02:12 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 519A23A1D62 for <openpgp@ietfa.amsl.com>; Tue, 23 Mar 2021 19:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
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=nGue3kTJ; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=VOil2J4e
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ImjrTIgOyCqy for <openpgp@ietfa.amsl.com>; Tue, 23 Mar 2021 19:12:24 -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 DB8DE3A1D61 for <openpgp@ietf.org>; Tue, 23 Mar 2021 19:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1616551941; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : from; bh=hP7PVeFH6G+iLjcd1ruTPs3zA6+QgCAqXrmzaDaLgo0=; b=nGue3kTJtJwD5bKJeG0l887lRKmVhgqTWKj52u1e4lsSNPOMsSx4UHKLu0dBGLg4lU0JD /kF+3ZlEmX9iDMoDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1616551941; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : from; bh=hP7PVeFH6G+iLjcd1ruTPs3zA6+QgCAqXrmzaDaLgo0=; b=VOil2J4e0hl4lE4pzoIBFfht5Ra4BKJlj6qLCLKpnLRU7x4W/sgKmpPGy8Moyf8257UTO EOYPWZYqVkpjG9xcpNG0rmPeTTARJh6/KLAtQ7R5D4josVVfNXap2BUDnK+7SE34cn6ZG+V we2Q9FstjWlecotf43U62FBv8myM9Df9cHd/814PAem3/reukyv+HGUgqaq6HX/fn+nflZx gARxeuGNOVmv/P6KvmFyVjLm03xqMOKknU4D7MjZ49mwE9AfOgGSYPj/eKu2LGr+BCNPewr jNoyuUDIzp8kPsgB4bDjMLu/jTAQhI8UVeVVt8Z5S6t0HAmfO2afVYT78OPw==
Received: from fifthhorseman.net (lair.fifthhorseman.net []) (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 40EA2F9A5 for <openpgp@ietf.org>; Tue, 23 Mar 2021 22:12:21 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id D54DB203F0; Tue, 23 Mar 2021 22:12:13 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: IETF OpenPGP WG <openpgp@ietf.org>
Date: Tue, 23 Mar 2021 22:12:13 -0400
Message-Id: <20210324021213.333485-1-dkg@fifthhorseman.net>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <87wnu86mep.fsf@fifthhorseman.net>
References: <87wnu86mep.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/8MAC07hO1OU9Of3-sPR5lvQY6Ns>
Subject: [openpgp] [RFC4880bis PATCH] Drop "Compatibility Profiles" section.
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: Wed, 24 Mar 2021 02:12:30 -0000

This section was imported from RFC 6637, but it is confusing,
incomplete, outdated, and duplicative.

It is confusing because it is called "Compatibility Profiles", a
general name, but it only references algorithms in combination with
various Elliptic Curve choices.  This made more sense when it was part
of RFC 6637, but doesn't make as much sense in a replacement for RFC

It is incomplete because it offers no attempt at "Compatibility
Profiles" that use non-ECC asymmetric crypto. We could rename it to
"Elliptic Curve Compatibility Profiles", but that would just leave the
document as a whole without additional guidance for non-ECC

It is outdated because it refers to Suite B, which has been deprecated
by its authors (see RFC 8423).

And it is duplicative, because it places additional constraints on MTI
requirements that we're working on actively as part of the
cryptographic refresh of RFC 4880.

The simplest thing seems to be to drop the section entirely.

Further work on algorithm implementation/deployment requirements might
suggest creation of new, up-to-date compatibility profiles that cover
the cryptographic suites likely to be used together, but if that work
happens, it should be done in consultation with the CFRG.  It should
be clearly documented, narrowly-targeted, up-to-date, and
non-conflicting with whatever MTI requirements we land on.
 crypto-refresh.md | 43 -------------------------------------------
 1 file changed, 43 deletions(-)

diff --git a/crypto-refresh.md b/crypto-refresh.md
index 9fbb6eb..eb8250c 100644
--- a/crypto-refresh.md
+++ b/crypto-refresh.md
@@ -212,12 +212,6 @@ normative:
     date: March 2007
       NIST Special Publication: 800-56A Revision 1
-  SuiteB:
-    target: http://www.nsa.gov/ia/programs/suiteb_cryptography/
-    title: NSA Suite B Cryptography
-    author:
-      org: National Security Agency
-    date: 2010-03-11
     title: The Twofish Encryption Algorithm
@@ -2904,7 +2898,6 @@ Consider, for example, that while both the public key and the per-recipient ECDH
 A key derivation function (KDF) is necessary to implement the EC encryption.
 The Concatenation Key Derivation Function (Approved Alternative 1) {{SP800-56A}} with the KDF hash function that is SHA2-256 {{FIPS180}} or stronger is REQUIRED.
-See {{compatibility-profiles}} for the details regarding the choice of the hash function.
 For convenience, the synopsis of the encoding method is given below with significant simplifications attributable to the restricted choice of hash functions in this document.
 However, {{SP800-56A}} is the normative source of the definition.
@@ -3471,42 +3464,6 @@ NIST P-521 | SHA2-512 | AES-256
   Countermeasures can often be taken at the higher protocol level, such as limiting the number of allowed failures or time-blinding of the operations associated with each network interface.
   Mitigations at the scalar multiplication level seek to eliminate any measurable distinction between the ECC point addition and doubling operations.
-# Compatibility Profiles
-## OpenPGP ECC Profile
-A compliant application MUST implement NIST curve P-256, SHOULD implement NIST curve P-521, and SHOULD implement Curve25519 as defined in {{ecc-curve-oid}}.
-A compliant application MUST implement SHA2-256 and SHOULD implement SHA2-384 and SHA2-512.
-A compliant application MUST implement AES-128 and SHOULD implement AES-256.
-A compliant application SHOULD follow {{security-considerations}} regarding the choice of the following algorithms for each curve:
-- the KDF hash algorithm,
-- the KEK algorithm,
-- the message digest algorithm and the hash algorithm used in the key certifications,
-- the symmetric algorithm used for message encryption.
-It is recommended that the chosen symmetric algorithm for message encryption be no less secure than the KEK algorithm.
-## Suite-B Profile
-A subset of algorithms allowed by this document can be used to achieve {{SuiteB}} compatibility.
-The references to {{SuiteB}} in this document are informative.
-This document is primarily concerned with format specification, leaving additional security restrictions unspecified, such as matching the assigned security level of information to authorized recipients or interoperability concerns arising from fewer allowed algorithms in {{SuiteB}} than allowed by this document.
-### Security Strength at 192 Bits
-To achieve the security strength of 192 bits, {{SuiteB}} requires NIST curve P-384, AES-256, and SHA2-384.
-The symmetric algorithm restriction means that the algorithm of KEK used for key wrapping in {{ec-dh-algorithm-ecdh}} and an OpenPGP session key used for message encryption must be AES-256.
-The hash algorithm restriction means that the hash algorithms of KDF and the OpenPGP message digest calculation must be SHA2-384.
-### Security Strength at 128 Bits
-The set of algorithms in {{security-strength-at-192-bits}} is extended to allow NIST curve P-256, AES-128, and SHA2-256.
 # Implementation Nits
 This section is a collection of comments to help an implementer, particularly with an eye to backward compatibility.