IETF OpenPGP February 2021 Interim

2021-02-26T15:00Z

Meeting held via WebEx

Attendees:

Notes taken on Riseup's etherpad.

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)

Development status (dkg)

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