Subject: [openpgp] OpenPGP Suite-B Profile vs. RFC 8423

From: Masanori Ogino <[email-masked]>
Date: Tue, 2 Mar 2021 08:02:24 +0900

Hello folks,

First of all, thank you all for your effort on revising OpenPGP RFC!
I am really glad to hear that the OpenPGP WG was officially rebooted recently.

I have a comment on draft-ietf-openpgp-crypto-refresh-02, section 16.2.
The section specifies a compatibility profile conforming the Suite B.
However, IETF published RFC 8423 that moved several RFCs referring the
Suite B for other protocols to Historic.

>From RFC 8423:
> In July 2015, NSA published the Committee for National Security
> Systems Advisory Memorandum 02-15 as the first step in replacing
> Suite B with NSA's Commercial National Security Algorithm (CNSA)
> Suite.
> (...)
> As indicated in [CNSA], NSA is transitioning from Suite B to the CNSA
> Suite.  As a result, the profiles of the security protocols for the
> Suite B algorithms are now only of historic interest.

It would be great if the ongoing revision specifies a CNSA profile
and/or obsoletes the Suite B profile IMHO.
What do you think?

Best,
Masanori

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Mar 2021 21:58:33 -0800

> and/or obsoletes the Suite B profile IMHO.

Obsoleting (or maybe even just not describing; I didn't look at the current
state of it) the Suite B profile seems worthwhile.

The ongoing CNSA work has not been done in the IETF itself, and instead is
progressing as RFCs via the Independent Submissions Editor.

-Ben

---

From: Werner Koch <[email-masked]>
Date: Tue, 02 Mar 2021 08:21:18 +0100

> state of it) the Suite B profile seems worthwhile.

I would also suggest to remove any mention of the Suite B profile.

If we mention a specific local standard others countries may also want
to have their profiles mentioned (e.g. Brainpool in Europe).

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Masanori Ogino <[email-masked]>
Date: Tue, 2 Mar 2021 17:55:57 +0900

Hello Benjamin and Werner,

Thank you for prompt responses.

> to have their profiles mentioned (e.g. Brainpool in Europe).

It makes sense for sure.

Best,
Masanori

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 15 Mar 2021 19:13:18 -0400

> to have their profiles mentioned (e.g. Brainpool in Europe).

With no hats on, just speaking as a user and an implementer: I'd also be
fine with removing all mention of "compatibility profiles" (including
Suite B) from the crypto-refresh draft.  We're going to have enough work
to do to settle on changes to Mandatory-to-Implement and other
implementation guidance, and i think these profiles are confusing and
unclear.

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 23 Mar 2021 22:12:13 -0400

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
4880.

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
algorithms.

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
     seriesinfo:
       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
   TWOFISH:
     title: The Twofish Encryption Algorithm
     author:
@@ -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.
-- 
2.30.2

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 23 Mar 2021 22:13:12 -0400

> incomplete, outdated, and duplicative.

This suggestion is recorded in gitlab as
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/41

        --dkg

---

From: Ángel <[email-masked]>
Date: Thu, 25 Mar 2021 02:20:16 +0100

> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/41

+1

This issue also affected the security considerations section. I made a
follow-up at https://gitlab.com/dkg/rfc4880bis/-/merge_requests/1

I tried to keep what was salvable but ended up leaving just three lines
from rfc6637.

Best regards

---

From: Paul Wouters <[email-masked]>
Date: Wed, 24 Mar 2021 21:30:32 -0400 (EDT)

> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/41

I have merged it.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 25 Mar 2021 08:38:11 -0400

> follow-up at https://gitlab.com/dkg/rfc4880bis/-/merge_requests/1

Looks like you've done a merge request against my personal repo, rather
than putting it in the openpgp-wg repo where everyone else will be able
to see it -- i recommend making this MR against
https://gitlab.com/openpgp-wg/rfc4880bis instead so that it gets public
visibility, and the merge requests aren't scattered.  I'm attaching the
proposed patch below so that people following the list can see it.

> I tried to keep what was salvable but ended up leaving just three lines

I'm not convinced that these specific security considerations are
invalid given that the compatibility profiles section is gone.  For
example, do we believe it to be untrue that:

    Compliant applications SHOULD implement, advertise through key
    preferences, and use the strongest algorithms specified in this
    document.

I think that looks correct, and I see no reason to cut it just because
we've dropped the Compatibility Profiles section.

So, (with no hats on) i'm not personally convinced of this change.  What
do other folks in the WG think?

If there are specific points in the Security Considerations section that
you (or anyone else) think should be dropped, or if anyone wants to
propose clarifications or improvements to these sections, I'd be happy
to reconsider a narrower edit too.

              --dkg

From 7093221bf096836f1ffe389d0202f486f4982186 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C3=81ngel?= <[email-masked]>
Date: Thu, 25 Mar 2021 02:00:33 +0100
Subject: [RFC4880bis PATCH] Additionally remove text from rfc6637 security
 section.

It relies and complemented the removed "Compatibility Profiles" section
and shares a number of its issues.

Some parts may be readded later, but currently it's not ready as-is.
---
 crypto-refresh.md | 57 ++++-------------------------------------------
 1 file changed, 4 insertions(+), 53 deletions(-)

diff --git a/crypto-refresh.md b/crypto-refresh.md
index eb8250c..493a51b 100644
--- a/crypto-refresh.md
+++ b/crypto-refresh.md
@@ -2859,6 +2859,9 @@ Finally, the Key ID and fingerprint of a subkey are calculated in the same way a
 This section descripes algorithms and parameters used with Elliptic Curve Cryptography (ECC) keys.
 A thorough introduction to ECC can be found in {{KOBLITZ}}.
 
+None of the ECC methods described in this document are allowed with deprecated V3 keys.
+Refer to {{FIPS186}}, B.4.1, for the method to generate a uniformly distributed ECC private key.
+
 ## Supported ECC Curves
 
 This document references three named prime field curves, defined in {{FIPS186}} as "Curve P-256", "Curve P-384", and "Curve P-521".
@@ -3405,59 +3408,7 @@ Asymmetric key size | Hash size | Symmetric key size
   On the other hand, it is inconvenient to the user to be informed that they typed in the wrong passphrase only after a petabyte of data is decrypted.
   There are many cases in cryptographic engineering where the implementer must use care and wisdom, and this is one.
 
-- Refer to {{FIPS186}}, B.4.1, for the method to generate a uniformly distributed ECC private key.
-
-- The curves proposed in this document correspond to the symmetric key sizes 128 bits, 192 bits, and 256 bits, as described in the table below.
-  This allows a compliant application to offer balanced public key security, which is compatible with the symmetric key strength for each AES algorithm defined here.
-
-  The following table defines the hash and the symmetric encryption algorithm that SHOULD be used with a given curve for ECDSA or ECDH.
-  A stronger hash algorithm or a symmetric key algorithm MAY be used for a given ECC curve.
-  However, note that the increase in the strength of the hash algorithm or the symmetric key algorithm may not increase the overall security offered by the given ECC key.
-
-{: title="Elliptic Curve cryptographic guidance"}
-Curve name | ECC | RSA strength | Hash size strength, informative | Symmetric key size
------------|-----|--------------|---------------------------------|-------------------
-NIST P-256 | 256 | 3072 | 256 | 128
-NIST P-384 | 384 | 7680 | 384 | 192
-NIST P-521 | 521 | 15360 | 512 | 256
-
-- Requirement levels indicated elsewhere in this document lead to the following combinations of algorithms in the OpenPGP profile: MUST implement NIST curve P-256 / SHA2-256 / AES-128, SHOULD implement NIST curve P-521 / SHA2-512 / AES-256, MAY implement NIST curve P-384 / SHA2-384 / AES-256, among other allowed combinations.
-
-  Consistent with the table above, the following table defines the KDF hash algorithm and the AES KEK encryption algorithm that SHOULD be used with a given curve for ECDH.
-  A stronger KDF hash algorithm or AES KEK algorithm MAY be used for a given ECC curve.
-
-{: title="Elliptic Curve KDF and KEK recommendations"}
-Curve name | Recommended KDF hash algorithm | Recommended KEK encryption algorithm
------------|--------------------------------|-------------------------------------
-NIST P-256 | SHA2-256 | AES-128
-NIST P-384 | SHA2-384 | AES-192
-NIST P-521 | SHA2-512 | AES-256
-
-- This document explicitly discourages the use of algorithms other than AES as a KEK algorithm because backward compatibility of the ECDH format is not a concern.
-  The KEK algorithm is only used within the scope of a Public-Key Encrypted Session Key Packet, which represents an ECDH key recipient of a message.
-  Compare this with the algorithm used for the session key of the message, which MAY be different from a KEK algorithm.
-
-  Compliant applications SHOULD implement, advertise through key preferences, and use the strongest algorithms specified in this document.
-
-  Note that the symmetric algorithm preference list may make it impossible to use the balanced strength of symmetric key algorithms for a corresponding public key.
-  For example, the presence of the symmetric key algorithm IDs and their order in the key preference list affects the algorithm choices available to the encoding side, which in turn may make the adherence to the table above infeasible.
-  Therefore, compliance with this specification is a concern throughout the life of the key, starting immediately after the key generation when the key preferences are first added to a key.
-  It is generally advisable to position a symmetric algorithm ID of strength matching the public key at the head of the key preference list.
-
-  Encryption to multiple recipients often results in an unordered intersection subset.
-  For example, if the first recipient's set is {A, B} and the second's is {B, A}, the intersection is an unordered set of two algorithms, A and B.
-  In this case, a compliant application SHOULD choose the stronger encryption algorithm.
-
-  Resource constraints, such as limited computational power, is a likely reason why an application might prefer to use the weakest algorithm.
-  On the other side of the spectrum are applications that can implement every algorithm defined in this document.
-  Most applications are expected to fall into either of two categories.
-  A compliant application in the second, or strongest, category SHOULD prefer AES-256 to AES-192.
-
-  SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH method.
-
-  MDC MUST be used when a symmetric encryption key is protected by ECDH.
-  None of the ECC methods described in this document are allowed with deprecated V3 keys.
-  A compliant application MUST only use iterated and salted S2K to protect private keys, as defined in {{iterated-and-salted-s2k}}, "Iterated and Salted S2K".
+- SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH method.
 
   Side channel attacks are a concern when a compliant application's use of the OpenPGP format can be modeled by a decryption or signing oracle model, for example, when an application is a network service performing decryption to unauthenticated remote users.
   ECC scalar multiplication operations used in ECDSA and ECDH are vulnerable to side channel attacks.
-- 
2.30.2

---

From: Ángel <[email-masked]>
Date: Fri, 26 Mar 2021 01:28:47 +0100

> proposed patch below so that people following the list can see it.

Hi Daniel

Yep. I wanted it to appear on top of merge_requests/41 but did not find
how to do that. Happy to learn how to do that.

Now that Paul has merged your branch, I have rebased it and opened a
direct MR against the main repository:
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/44

> we've dropped the Compatibility Profiles section.

I considered it. That (and folllowing) paragraphs look mostly fine. The
problem there is the part about "use the strongest algorithms specified
in this document". On 6637 that refers to the algorithm strength it is
defining (i.e. the previous paragraphs that get removed). I considered
whether it could be amended. That could end up as "use the strongest
algorithms as defined by local policy", "as defined by the implementer"
or some similarly vague description which wasn't really satisfactory.
Also note that "specified in this document" changes meanings when put
in 4880-refresh than in 6637 which was just about ECC.

I like some of the points it discusses, such as the order issue with
multiple recipients, but it still revolves around strength ("the
stronger encryption algorithm", "the weakest algorithm"...) which is no
longer defined.

I think we're better clearing it and seeing what is importable. I may
have missed some sentence, but I doubt you could keep most of it as
such.*

We MAY want to provide a more complete table than was in 6637
(preferably as a new section, not embedded in Security), in which case
we could more easily reimport some bigger chunk.
That is worth its own discussion, though. I'm not convinced at this
point that 4880-refresh should explicitly state the relative strength
of each algorithm.

(*) A phrase that got removed but should be recovered is «MDC MUST be
used when a symmetric encryption key is protected by ECDH.». I pondered
where to move it, but I concluded that should better go at its own
changeset stating that new algorithms cannot be used without MDC i.e.
they cannot be used with the "Symmetrically Encrypted Data Packet"
(still somewhat redundant, as that one MUST NOT be created).

Additionally, the phrase "A compliant application MUST only use
iterated and salted S2K"... is also mostly fine, but I had already
covered a proposal for that one in the previous 
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/42

If you find other phrases being removed that you think should have been
kept, I would be happy discuss them in more detail. But for now, and
after carefully reviewing the change itself, I stand by the proposal I
did.

Best regards

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Mar 2021 23:27:15 -0400 (EDT)

On Fri, 26 Mar 2021, Ángel wrote:

>> I'm attaching the

I had a look at it. While some text indeed is weird because of the move
from an ECC only document into the generic bis document, I think some
of the text you suggest removing might still make sense, such as the
recommendations of hash algorithms for these curves. And that the place
within the document might be right too?

> in 4880-refresh than in 6637 which was just about ECC.

I agree that needs fixing. The question is how/when to do this. If we
cut the entire section as you propose, we need to a file a tracking bug
to re-evaluate what to bring back, revised or verbatim later on in the
process when we are pulled up all the existing non-controversial work.

> have missed some sentence, but I doubt you could keep most of it as

I think that could work, but let's get the opinion of a few others ?

> (still somewhat redundant, as that one MUST NOT be created).

If others agree, we need a tracking item for this too?

> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/42

I would need to hear from more people about this change to see if there
is consensus for this.

speaking with no roles others than an individual:

You suggest:

 	- Implementations SHOULD use salted or iterated-and-salted S2K specifiers,
 	- as simple S2K specifiers are more vulnerable to dictionary attacks.
 	+ Simple S2K and Salted S2K specifiers are not particularly secure when used
         + with a low-entropy secret, such as those typically provided by users, and
         + implementations SHOULD avoid using these methods on encryption of both keys and messages.
 	[...]
 	- A compliant application MUST only use iterated and salted S2K to protect private keys,
         - as defined in {{iterated-and-salted-s2k}}, "Iterated and Salted S2K".

I think merging these two as you done is fine. I would try to use "SHOULD NOT use"
instead of "SHOULD avoid".

I don't think the phrasing of "not particularly secure".  Can it not just say "weak" or
"vulnerable to low cost attacks" ?

Also, if it is this bad, why is this a SHOULD and not a MUST ? That is,
when would be a valid reason for an implementation to ignore the SHOULD?

> after carefully reviewing the change itself, I stand by the proposal I

Note I only looked at the diff, I did not go looking for other phrases.

Paul

---

From: Ángel <[email-masked]>
Date: Sat, 27 Mar 2021 04:15:52 +0100

On 2021-03-25 at 23:27 -0400, Paul Wouters wrote:
> recommendations of hash algorithms for these curves. 

Good point, that table may be useful without the requirement levels.

> And that the place within the document might be right too?

That's an editorial matter, but I don't think so. I find the security
section to contain many things without a clear script, just a mixture
of things related to security. The problem is that most of the rfc has
some relation to security :-)
There are rfcs with only a few security points to note. Having a
section listing all of them is good. But I don't think that's suitable 
for OpenPGP.

I would prefer to see as little as possible on the Security
Considerations, with the points within the most relevant section to the
topic. See for example how I positioned the line about you MUST use
Iterated and salted s2k at the part discussing rather than in that
generic section. IMHO that makes more sense, instead of having a S2K
requisite in a complete separate part of the document.

Nevertheless, the Security Considerations need an overhaul. There are
multiple types of items: general advice, attack descriptions, key size
tables...
And it must grow, some of that is outdated, while other missing.

That ECC table I would probably place it at its own section, probably
as a 13.5.

Other points should perhaps be 15.x subsections.

> process when we are pulled up all the existing non-controversial work.

I agree with opening a task to reevaluate that later, if merged.
This was not intended as a permanent removal.

> If others agree, we need a tracking item for this too?

Yes, probably. Unless we get a quick consensus on this topic.

> I would need to hear from more people about this change to see if
> there is consensus for this.
> 

This part was proposed in February on a different thread. I am moving
your comment there and replying in that one:

https://mailarchive.ietf.org/arch/msg/openpgp/ml5gzuQtSY6ANBejs8Xk66x_abQ

Regards