Subject: [Openpgp-dt] 2021-12-08 DT meeting notes

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Dec 2021 14:19:10 +0000

OpenPGP Design Team

2021-12-08

Present:
     dkg
     Daniel Huigens
     gniibe
     Stephen
     Justus
     Jeffrey
Regrets:
   Paul

# Agenda (moar of the same:-)

## key separation

https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/101
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/61

Break issue into bits...

- v5 skesk(?) options:
     - if that and argon2 use argon2 additional data (for alg ids?)
     - might couple that with a "MUST/SHOULD use argon2 for v5 skesk" 
(or not)
  - but some people will not want argon2 (e.g. already high-entropy 
strings) and we want the domain separation regardless of S2K algo choice
  - input string = f(alg ids, pwd) for some f
  - depending on type of s2k alg, do different things
ACTION - daniel H willing to try craft text to see how it looks with 
s2k-specific methods on top of MR 101

- secret key encryption
- could try do same as for skesk, (for usage octet 253; others formally 
pass empty octet string as additional data for backwards compat)
ACTION: daniel H will propose (on MR 101) roughly the same approach for 
usage octet 253 as for v5 skesk above -- the S2K mechanism will include 
algorithm parameters for key derivation.  (algo parameters will *not* be 
in the AAD part of AEAD, that's reserved for the pubkey)

Result from above will go into MR #101

## Actions from last week:

### https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/83 DKG did 
a thing, ready to merge? Yep.

### https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/44

     Daniel H - did write up today
     DKG did https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/103
     - two main things there: arguments and a 130-bit/base32 proposal
   - this kinda tees up a later I-D (QR codes/biz cards etc.)

- tricky bit of the argument relates to collision/pre-image resistance
- if some server app has a (maybe large) DB of public keys, if any of 
those fingerprints collide then app owner could cheat some, possibly 
requiring collusion (or automation maybe)
- Q: how large a DB is needed for that to be probable? if 2^64 that's a 
lot of users, but OTOH RFC4880 is old so the bis RFC may last a while... 
does that need to be one DB really or should we think about all keys 
anywhere
- risks here: encrypt something to wrong public key, or allow someone to 
repudiate  a signature
- we do know humans are crap at comparing FPs of all sorts
Action: dkg will propose new Security considerations subsection, making 
the following points:
humans are bad at comparing high-entropy strings; asking them to compare 
full v5 fingerprints are implausible.
if an implementation aims for usability for fingerprint or key 
comparison (e.g. by reducing the number of bits to compare) then there 
are the following risks as large numbers of keys are available 
(proportional to the size of the truncated fpr):
encrypting to the wrong key
signature non-repudiation might not work as expected (an attacker with 
collision capability could post a signature, and a verifier that doesn't 
store the key but does cache the truncated value could later be told 
that it was invalid, because a different key is produced that matches 
the truncated value)
these can be avoided by always storing and mechanically comparing the 
full fingerprint

SF's note on DT rough plan wrt FPs (to revisit with Justus/Paul and us 
all)...
- Document security considerations wrt use of shorter more humane FPs in 
4880bis as per DKG action above
- DT to not define any new or old ways of producing shorter, humane, FPs 
in 4880bis
- Invite WG to start work on another I-D on this topic (exact scope may 
need a bit of work)
- In the above "humane" means "meant for humans to process" which is 
(deliberately) a but vague
- We didn't fully thrash out the above (we hit the hour mark on the 
call) but I (SF) think that seems like where we may be heading