Re: [openpgp] OpenPGP interim meeting tomorrow (2021-02-26 15:00Z)

[Daniel Kahn Gillmor <[e-mail]>]

On Sat 2021-02-27 00:01:18 -0500, Daniel Kahn Gillmor wrote:
> I've cleaned and uploaded the notes here:
>
> https://datatracker.ietf.org/meeting/interim-2021-openpgp-01/materials/minutes-interim-2021-openpgp-01-202102261500-00

It occurs to me that I never posted the notes from the interim
specifically to the list.   I include them below, so that there's no
need to pull from the website if you don't want to.

Regards,

     --dkg


IETF OpenPGP February 2021 Interim
==================================

2021-02-26T15:00Z

Meeting held via
[WebEx](https://ietf.webex.com/ietf/j.php?MTID=m1b3bb4269a2ef10b9995442e09426b84)

- Agenda Bash
- Progress on draft-ietf-openpgp-crypto-refresh
- Developing the draft
- Next steps on draft-ietf-openpgp-crypto-refresh
- IETF 110 Agenda & next Interim

Attendees:

- Stephen Farrell
- Neal H. Walfield
- Daniel Kahn Gillmor (dkg)
- Paul Wouters
- Ángel González
- Werner Koch
- Vincent Breitmoser
- Friedel Ziegelmayer (dignifiedquire)
- Jonathan McDowell
- Sylvain Besençon
- Derek Atkins
- Andre Heinecke
- Christoph Biedl
- Andrew Gallagher
- Nora Widdecke
- Ben Kaduk
- Daniel Huigens
- Justus Winter
- Peter Yee
- Heiko Stamer
- Jonathan Hammell

Notes taken on [Riseup's
etherpad](https://pad.riseup.net/p/2021-02-26-openpgp-interim-keep).

Primary Notetaker: Vincent Breitmoser

meeting begins: 16:04 UTC

chair intro, Stephen Farrell & dkg

## Agenda Bashing

no comments, moving on

(session recording starts late) naughty co-chair :-)

## Catchup for OpenPGP WG (dkg)

- rfc4880bis was running on its own, but with wg name
- plan was to recharter and restart wg
- over time restore changes from bis, establish consensus on individual diffs
- general updates about -00 to -02 of new doc [slides 4-5]

## Development status (dkg)

- draft development: now in markdown
- nitpicks can be given as merge requests, substantive changes need ML
discussion - issue tracker is ok, but do follow up on ML since it's the
canonical place - rfc4880.md: identical to rfc4880, as md - rfc4880bis.md: last
version of rfc4880bis draft, as md (historical reminder) - crypto-refresh.md:
working document

stephen
: additional comments from editors? (Paul & Werner)

no comments

## next steps, overview of diffs of bis to crypto-refresh

dkg
: [slide 7] changes split up into: chartered crypto-refresh changes,
crypto-refresh related, not crypto-refresh

daniel huigens
: intended recipient could be viewed as crypto-refresh to fix surreptitious
forwarding issue

dkg
: might want to promote? (...)

werner
: brainpool curves are already in 6637, thus not relevant for crypto-refresh

dkg
: can't see them in 6637

werner
: right. any curve can be used by oid, so still unnecessary

dkg
: perhaps just put in that info?

neal
: support for crypto-refresh, and afterwards work on new draft. better not
discuss too much about what is and isn't in scope

andre
: prefer not to go for another rfc. huge PITA certifying for new spec, would be
better to have this iteration suffice for the next 10 years derek : agree with
andre, for non-contentious issues we should include them even if not
crypto-related

stephen
: need to stick to charter. we can go beyond once that has been done
successfully. tried getting too much done before, couldn't focus enough on what
needed to be done. maybe other ways to handle certification issue?

dkg
: maybe include non-contentious issues that have no crypto implications? still,
important to stick to charter.

ben
: IESG had a case or two where documents handed in exceeded charter. this
caused problems, should stay in charter at least for the next months.

paul
: prefer to get document done quick and leave anything contentious to second
document, don't repeat previous cycle

(text werner)
: agree with paul

(text huigens)
: +1

(text friedel)
: +1

stephen & dkg
: anything missing from points? [slide 7]
  - no comments (feel free to bring to list)

dkg
: points on list [slide 7] might not mean we reach charter, might find
additional

## beyond merge of 4880bis

dkg
: [slide 8] curve448? S2K update (argon2)? weren't possible in last iteration

(text daniel huigens)
: agree with those

### argon2

werner
: argon2 makes no sense for openpgp. only makes sense if interoperable thus
would need to be mandatory, not good for argon2. code point ok, mandatory not
for openpgp.
  clarifications: symmetric encryption not primary use for openpgp, kdf not
  that important because symmetric use cases would use full entropy anyways

huigens
: s2k update important, use cases do exist

andre
: fully disagree, symmetric crypto covers long retention, any change is API
breakage, introduces problems

(more back and forth andre/huigens)

derek
: already have compat issues with pgp 2.6, bridge already crossed.

dkg
: no need to break old stuff when introducing new intro. having text to
consider would help the discussion. might be problem to introduce new algo
without guidance on when they may be used. no capabilities in symmetric
algorithms.

  by this reasoning, symmetric openpgp crypto is stuck and we can never change
  it?

andre
: want algorithms in spec so we can switch when vulnerabilities occur. but is
painful for users, so must consider when we enforce it. no objections to
argon2, but don't want to switch default without attack scenario

dkg
: need specification yesterday on how to interpret, but don't generate.

(text andre)
: agreed

stephen
: create issue to track this issue

werner
: argon2 has been discussed on ML, too. can't come to an agreement here, should
leave discussion for later

### curve448

stephen
: thoughts on curve448?

werner
: gnupg has curve448. noticed that to do properly this in spec, need new data
type. that would take a while, maybe leave it out

## other updates?

stephen
: other updates for crypto-refresh, beyond bis?

angel
: (on symmetric algos again), same issue with public keys (e.g. curve448).
needs way to use new algorithms while keeping compatibility

(text neal)
: not an issue because there is features subpacket

### userid-less keys

andre
: regarding keys without user ids. seems huge split in community regarding this
issue, maybe we should discuss it?
  my opinion (as mail client implementor): no idea what should do with pgp keys
  without user ids. huge issue because this kind of key breaks my use cases.

stephen
: should create issue for that

vincent
: whole point of user id-less keys is so that you can get updates.

andre
: I would like to clarify if it is legal to provide such keys.  I think it is
disallowed, but vincent is doing it anyway.  We should clarify this in the new
RFC.

vincent
: I would also like the next RFC to clarify this.

dkg
: other similar use cases, e.g. free-floating revocation certificates. also not
specced but useful. might want to spec common formats that are in use, to give
better overview

neal
: user ids without signatures are ok. hagrid could add "null" user id, so 4880
already addresses this

## Upcoming meetings

dkg
: registration for IETF 110 open [slide 9]
  - Meeting 2021-03-11 "Session II"

stephen
: waivers available. based on honor system, please don't abuse

dkg
: next interim? since IETF 111 is end of july. early may
  more frequent meetings possible. if we want that, should focus on specific
  topics

(text paul)
: early may sounds good

(text daniel huigens)
: might be useful to hold semi-regularly

stephen
: let's assume early may, confirm on list

derek
: 4-6 weeks sounds reasonable

(sentiment that conferencing solution didn't work great, discussion about
alternatives on list)

meeting closed 16:07 UTC