[Openpgp-dt] 20211018 dt notes

[Stephen Farrell <[e-mail]>]

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?