Subject: [Openpgp-dt] 2022-01-26 design team notes

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Jan 2022 14:36:36 +0000

OpenPGP Design Team Meeting

2022-01-26

Present:
      dkg
      daniel H
      gniibe
      jeffrey
      justus
      paul

# Congrats/commissertations to Paul on being appointed as SEC AD!

That's another reason for us to try get as done as we can before March!
We're currently down to 14 open, MRs - yay!

# 96-bit keyids merged, but a new issue has arisen:
      https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/76
   (dkg: if we had guidance about where and why to use the v5 key id, it 
might help keep the WG discussion on track when we discuss that)
   https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/106 is 
still open
daniel H will try improve 106 to the point where we may be able to marge 
it (or give up on it) next week
justus is concerned with not giving guidance about not giving guidance 
as to how to display fingerprints - implementations might come up with 
their own incompatible ways to do it, e.g. truncating in various 
different ways
daniel H: a full discussion of that may need a separate document (that 
e.g. describes QR code options)
justus: implementers will have to do something, possibly displaying very 
long FPs
paul: maybe best we can do is say long FPs are awful and informatively 
point to some other document that can handle that
justus: this isn't only about human-in-the-loop comparison but also 
about list-keys and equivalents
paul: suggests merge 106 with a note on it to say this topic needs more 
work, probably in a separate openpgp wg doc
dkg volunteers to put in such a note in 106

# salted signatures 
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/91/
justus will re-base on current repo, then we hope it'll be approved, 
nobody has an issue with it as of now

# SEIPDv2 vs AEADv2 vs. status quo
dkg willing to do up a MR if desired... do we want that?
daniel H willing to do an MR (needs examples updated)
do we have an issue for fixing examples before IETF LC or WG LC? dkg 
will create issue and we'll fix examples later
maybe, write this after MR 128 then 127 then 122 merged or otherwise 
dealt with? will make for less rebasing, daniel H will do that then
128 has no comments so far, so please everyone check it out - we're 
building dependency on it being handled

# padding https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/118
paul raised some issues with clarity and 2119 terms, he'll propose some 
clarifications
dkg will see if copying text from tls1.3 about separate random streams 
for e.g. keys vs potentially visible random data can usefully be copied 
in to the security considerations

# per-message keys (reply-to-all) 
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/122
dkg: should we spell out more about how reply-to-all should work in an 
email context? dkg will create an issue for that (assuming text wouldn't 
go into 4880bis)
people seem ok with the changes in 122 meanwhile
approval is for a bit later (after 128/127 merged) but do review

# GCM
didn't discuss

# v4 keys making v5 sigs? (does OPSv5 need a key version id?)
   https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/120
one-pass sigs...
if v4 keys can make v5 sigs we need a version field in one-pass sig
if however v4 keys never make v5 sigs that's not needed - simpler but is 
it ok?
(the above is already a SHOULD in the draft)
daniel H: agree with that last as guidance, but maybe the option to 
always generate a v5 sig might be useful in future (once v5 sigs are 
widely supported), that'd allow just one code path for generating sigs
justus: if encrypting and signing, one may have a good signal that v5 
sig will be understood (v5 sigs are salted and use bigger hashes)
dkg: that'll enable v4 keys to persist for longer, do we want that?
justus: even if we don't it'll be the case
gniibe: prefers simpler
ACTION: dkg to write up MR for v4-keys-only-make-v4-sigs as an 
alternative to !120

# SF wants to ask about an issue that's come up in the LAKE WG about 
EdDSA...
https://mailarchive.ietf.org/arch/msg/lake/0-9X6McGoQCoqZ0q2v97eH9i4iY/
SF will fwd to CFRG, but for now we think salted FP would avoid this 
vulnerability for openpgp

---

From: Justus Winter <[email-masked]>
Date: Wed, 26 Jan 2022 15:59:35 +0100

Indeed, if we look at the referenced draft [0], we see:

> One countermeasure to such attacks is to re-add randomness to the
> otherwise deterministic calculation of the per-message secret number.

0: https://datatracker.ietf.org/doc/draft-mattsson-cfrg-det-sigs-with-noise/

Justus

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 26 Jan 2022 17:09:09 -0500

> # 96-bit keyids merged, but a new issue has arisen:
 […]
> dkg volunteers to put in such a note in 106

There was already some text in !106 about "more work needed", but i've
added an additional more explicit note there.

> nobody has an issue with it as of now

This is already done, and looks good.  Thank you Justus!  I hope other
folks can review shortly.

> in to the security considerations

This is https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/130

>    https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/120
 […]
> ACTION: dkg to write up MR for v4-keys-only-make-v4-sigs as an 

This is https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/129

I'm now working on reviewing !128 as the next step on the path toward
improved key separation in AEAD (SEIPDv2?) encrypted data.  i hope
others will take a look at that today or tomorrow as well.

     --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 27 Jan 2022 12:59:21 -0500

> 0: https://datatracker.ietf.org/doc/draft-mattsson-cfrg-det-sigs-with-noise/

Do folks think it's worth adding an informative reference to this draft
in crypto-refresh.md?

     --dkg

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Jan 2022 19:12:09 +0000

I'd not add such a reference, I've heard mention of related IPR, but don't know details
S.
________________________________
From: Openpgp-dt <[email-masked]> on behalf of Daniel Kahn Gillmor <[email-masked]>
Sent: Thursday, January 27, 2022 5:59:21 PM
To: [email-masked] <[email-masked]>
Subject: Re: [Openpgp-dt] 2022-01-26 design team notes

     --dkg

--
Openpgp-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/openpgp-dt