Subject: [Openpgp-dt] 20211018 dt notes

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Oct 2021 15:41:41 +0100

OpenPGP Design Team
2021-10-18

Present:

daniel kahn gillmor
niibe yutaka
daniel huigens
paul wouters
stephen farrell
justus winter

# Agenda

## Open MRs

## Next Steps

Justus:
   Daniel asked about our definition of done, and I want to suggest to use
   Gitlab's milestone feature to keep track of issues that we want to see
   addressed before releasing a draft or the final crypto-refresh.

## #66 has 2 approvals

Paul can now emit I-D and will; dkg will send a mail to list with a bit 
of context

## Other MRs already approved that can be merged:

!84 has been merged, 81 waiting for approval during meeting, 78 is 
approved, 76 similarly, 75 similarly (editor choice)

All above is for next I-D, all below for after...

# Back to #48 https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/48

- Justus: suggests ECDH as MUSTs
- if we have a MUST for ECDH we need a MUST curve (or >1)
- "MUST support ECDH" yes
- 1 or more MTI curve?  yes
- p256 and/or x25519 ok? yes
- which or both? everyone ok with 25519
- is 448 anywhere here? not a MUST; a SHOULD (if your crypto library 
does it)
- p256? nobody in DT arguing for SHOULD

- EC signatures
- EdDSA is a MUST
- suggestion is: ed25519 as a MUST

GOT HERE on last week's call, with above agreed by those on call, 
picking up discussion of questions below this time...

dkg suggests a generic criterion:
     {MUST algs} == what's needed to talk to brand new code, ignoring 
legacy data and
   {SHOULD algs} == what's needed to talk legacy algs (and isn't a MUST)
another possible criterion:
     {MUST algs} must be superset of minimal set of algs needs for 
fips-140 compliance
      (huigens mentions 
https://csrc.nist.gov/publications/detail/fips/186/5/draft which 
includes eddsa)

- what about ECDSA?
- FIPS might be the only reason to make ECDSA a MUST
- maybe somewhere between don't-care and SHOULD
- regardless, the curve to map to is p256, others aren't sensible 
choices so we'll stay silent on those

- What about DSA/elgamal?
- is it time to drop/deprecate? if so, how?
- 1024-bit DSA defo ought go away as much as possible (i.e. deprecate to 
death)
- Strict Proposal:
MUST NOT generate encrypted ElGamal PKESK
MAY decrypt ElGamal PKESK
MUST NOT sign with DSA
MAY validate DSA signatures as long as key size ≥ 2048 bits
- Relaxed Proposal:
SHOULD NOT generate encrypted ElGamal PKESK (unless no other way to 
encrypt and eprint 2021/923 variance is accounted for)
MAY decrypt ElGamal PKESK (with guidance to avoid 2021/923 concerns)
SHOULD NOT sign with DSA (unless specific features like threshhold 
crypto are needed, and public keys are ≥ 2048 bits)
MAY validate DSA signatures (as long as key size ≥ 2048 bits)
- wrt elgamal https://eprint.iacr.org/2021/923.pdf
 
https://ibm.github.io/system-security-research-updates/2021/07/20/insecurity-elgamal-pt1
- many elgamal keys will have dsa associations
- some stats used in discussion: https://sequoia-pgp.org/tmp/stats.txt
- dkgpg (Heiko Stamer's implementation) uses DSA for threshold signatures
- openpgp.js v5 turns dsa/elgamal off with a config flag to re-enable, 
so we may be able to gather data on how many enable that for a few months...
    - with 67k downloads from npm since 202108, none are seen to have 
enabled this
- we can also try see how many current certs involve dsa/elgamal
- action on daniel/justus: get "current" data
"current": certificate generated in the last 5 years; not expired or revoked
be nice if those actions done in 2 weeks probably ok if longer

For next week:

- Daniel asked about our definition of done, and I want to suggest to use
- justus suggests adding a milestone to gitlab, justus to try as an 
experiment

- RSA as a SHOULD or MUST
- AEAD mode text is needed (and may be tricky)
- compression: CRIME => maybe better no SHOULD? or... 
(https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/64) 

- why the change anyway?

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Oct 2021 14:28:23 -0400 (EDT)

> - FIPS might be the only reason to make ECDSA a MUST

I confirmed the FIPS situation. If the draft is enacted as is, curves 25519
and 448 are going to be approved in its Montgomery, (Twisted) Edwards and
Weierstrass representation. But 25519 will only be allowed SHA2-512 for
signatures.

So I think it makes sense to postpone any FIPS related changes and
revisit this later when we are near to publication of the final RFC.

Paul

---

From: Werner Koch <[email-masked]>
Date: Wed, 20 Oct 2021 09:23:24 +0200

> I confirmed the FIPS situation. If the draft is enacted as is, curves 25519

I don't think that a MUST is required here.  A SHOULD is sufficient
because interoperability between FIPS approved systems will anyway be
given due to the FIPS requirements in addition to the OpenPGP specs.

For a standard version for citizens and the industry an implementation
supporting only 25519 should actually do.

In the context of approved algorithms the question is more may we make
non-approved algorithms a MUST because that, means an, say FIPS-140.3,
approved implementation of OpenPGP would not be OpenPGP compliant.

Aside of FIPS, Europe has different requirements, in particular NIST
curves are not approved and Brainpool curves are the only approved
curves for EU Restricted as well as for qualified electronic signatures.

Iff we want to make OpenPGP fully compliant with such governmental
approved algorithms catalogs we have currently only the option to make
RSA 3072 a MUST and all ECC a SHOULD.  But in just a few years RSA will
likely be dropped and we can't know what's then on the ECC table.  IMHO
the IETF curves will eventually be approved also in Europe but that may
take 5 or more years.

> revisit this later when we are near to publication of the final RFC.

Ack.

Salam-Shalom,

   Werner

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Oct 2021 16:46:54 +0100

On 20/10/2021 16:44, Paul Wouters wrote:
> 
> Fair point. If we treat FIPS needing a MUST, we would also need to give
> EU their MUST. So perhaps better to stay out of this game entirely.

And China/Russia too maybe.

ISTM that staying out of the game is better, if possible. I
don't know what's feasible for pgp though, but maybe staying
out is a good starting position for our work?

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Oct 2021 11:44:16 -0400 (EDT)

> given due to the FIPS requirements in addition to the OpenPGP specs.

Remember we are talking about implementation status, not enabling
status. If software does not implement it, it becomes useful from a
FIPS point of view.

> supporting only 25519 should actually do.

But in general, there are no different distribution channels for
software for citizens, contractors, vendors or governments :)

> approved implementation of OpenPGP would not be OpenPGP compliant.

That is not a problem for FIPS. The software can allow more as long as
when the system is in FIPS mode, those non-approved algorithms are not
used. This could be enforced ideally by software, but from a FIPS point
of view, it is fine to be only some words in the Security Policy that
says "do not use algorithm X".

> the IETF curves will eventually be approved also in Europe but that may

If that happens, we can do a "cryptographic guidelines" document that
just updates the recommended algorithms. I've done those for IKE, IPsec
and DNSSEC. And would require a lot less effort than this crypto refresh
document.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Oct 2021 12:28:05 +0100

Hiya,

On 21/10/2021 02:54, NIIBE Yutaka wrote:
 >
 > (I receive messages to [email-masked], but it seems that I don't
 > have permission to post a message.  If needed, please re-post.)

I just checked and your fsij.org address is subscribed ok but
had the "mod" bit set on the membership list. I unchecked
that which should hopefully fix. If the DT list still isn't
working for you as it ought, ping me and we can fix.

You message from last night (my time:-) is below and didn't
seem to hit the archive nor the moderation queue so people
who've not seen that should read on...

Cheers,
S.

On 21/10/2021 02:54, NIIBE Yutaka wrote:
> Hello,
> 
> (I receive messages to [email-masked], but it seems that I don't
> have permission to post a message.  If needed, please re-post.)
> 
> Paul Wouters <[email-masked]> wrote:
> I think that "FIPS" here generally means "FIPS compliant system", and it
> usually means FIPS 140.
> 
> FIPS 140-3 and FIPS 140-2 are active ones.
> 
> As of today, system like some GNU/Linux distributions, and Windows,
> supports FIPS 140-2 compliant mode (and it will be FIPS 140-3 compliant
> mode in future).
> 
> For approved security functions in FIPS 140-3, the relationship is:
> 
>      FIPS 140-3 -> SP 800-140C -> FIPS 186-4
> 
> In FIPS 186-4, EdDSA is not available, unfortunately.  It is FIPS 186-5
> (draft, currently) where EdDSA is defined.
> 
> Practical issue here would be:
> 
>      Can an implementation of OpenPGP work on FIPS compliant system
>      correctly?
> 
> EdDSA cannot work on FIPS compliant system (of FIPS 140-2 system, of
> FIPS 140-3 system in near future).  It will only work, when next version
> will be published and deployed (FIPS 140-4 with FIPS 186-5).
> 
> To pursue this goal (use of an implementation of OpenPGP on FIPS
> compliant system), for OpenPGP spec., I don't object to include support
> of:
> 
>      ECDH on NIST P-256
>      ECDSA on NIST P-256
> 
> Other option for this goal might be RSA.  But if we do, I'm afraid that
> this will invite update of use of RSA: RSA-PSS and RSA-OAEP (issue #22).
> 
> If we don't pursue this goal, it's better not to include support of ECDH
> on NIST P-256 and ECDSA on NIST P-256.
> 
> 
> Still, I think that it needs considerable work for (any) implementations
> to support running on FIPS compliant system correctly.
>

---

From: NIIBE Yutaka <[email-masked]>
Date: Mon, 25 Oct 2021 19:51:47 +0900

(Resending, because of permission)
==========================
Hello,

    ECDH on NIST P-256
    ECDSA on NIST P-256

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 25 Oct 2021 08:09:55 -0400

> compliant system), for OpenPGP spec., I don't object to include support

I'm not sure i understand the tradeoff here: are we asking whether a
*minimal* OpenPGP implementation (one that just does the MUSTs) would be
FIPS-140-3-compliant?  Or are we asking whether a compatible OpenPGP
implementation *can be* compliant?  Presumably if FIPS-whatever requires
implementation and use of an algorithm like NIST P-256, a compatible
implementation can just implement NIST P-256 in addition to whatever the
MUSTs are for the revised RFC4880, right?

Or does the fact that EdDSA is implemented and enabled make the system
*not* FIPS-140-3-compliant?  If that's the case, and we make both
Ed25519 and NIST P-256 a MUST, then a MUSTs-only implementations would
*still* not be compliant, right?

> this will invite update of use of RSA: RSA-PSS and RSA-OAEP (issue #22).

I'd love to see more thoughts and commentary on #22 -- we'll need to
resolve it (either by implementing it or by deciding to explicitly close
it) before being finished with this process.

Anyone who wants to advocate for RSA-PSS (for v5 signatures) and
RSA-OAEP (for v5 PKESK) might also want to consider proposing concrete
text for review!

> on NIST P-256 and ECDSA on NIST P-256.

Thanks for sharing your conclusions here, gniibe!  Do other DT members
have a preference here?

     --dkg

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Oct 2021 12:58:07 -0400 (EDT)

> MUSTs are for the revised RFC4880, right?

Yes, but it is not only minimum implementations that only implement only
MUSTs. Often, generic implementations only implement the MUSTs as it is
a good indication the important bits and to stay "lean". Some might do
it based on budget - just do the MUST's and leave out all optional
stuff. In the end, for us what matters is that most of the commonly
used implementations would have something FIPS compatible, or risk that
the protocol gets kicked out of FIPS due to in practise having too much
of a failure rate for required SHOULD or MAY parts of the specification.

> *still* not be compliant, right?

No. You can add ROT13 to any FIPS compliant software. As long as either
the code or the accompanying Security Policy document states that ROT13
never be used when operating in FIPS mode. The same applies to key
sizes or other crypto parameters.

> Thanks for sharing your conclusions here, gniibe!  Do other DT members

I think we reached consensus on the list here, with Daniel taking a stab
at changing the current style of text to the current parameters we agree
on. Then see later if we update this in its entirety to a different
phrasing or not.

Paul