IETF OpenPGP February 2021 Interim

2021-02-26T15:00Z

Meeting held via WebEx

• 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.

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