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
<dl>
<dt>stephen</dt>
<dd>additional comments from editors? (Paul & Werner)</dd>
</dl>
no comments
next steps, overview of diffs of bis to crypto-refresh
<dl>
<dt>dkg</dt>
<dd>[slide 7] changes split up into: chartered crypto-refresh changes, crypto-refresh related, not crypto-refresh</dd>
<dt>daniel huigens</dt>
<dd>intended recipient could be viewed as crypto-refresh to fix surreptitious forwarding issue</dd>
<dt>dkg</dt>
<dd>might want to promote? (...)</dd>
<dt>werner</dt>
<dd>brainpool curves are already in 6637, thus not relevant for crypto-refresh</dd>
<dt>dkg</dt>
<dd>can't see them in 6637</dd>
<dt>werner</dt>
<dd>right. any curve can be used by oid, so still unnecessary</dd>
<dt>dkg</dt>
<dd>perhaps just put in that info?</dd>
<dt>neal</dt>
<dd>support for crypto-refresh, and afterwards work on new draft. better not discuss too much about what is and isn't in scope</dd>
<dt>andre</dt>
<dd>
<dl>
<dt>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</dt>
<dt>derek</dt>
<dd>agree with andre, for non-contentious issues we should include them even if not crypto-related</dd>
</dl>
</dd>
<dt>stephen</dt>
<dd>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?</dd>
<dt>dkg</dt>
<dd>maybe include non-contentious issues that have no crypto implications? still, important to stick to charter.</dd>
<dt>ben</dt>
<dd>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.</dd>
<dt>paul</dt>
<dd>prefer to get document done quick and leave anything contentious to second document, don't repeat previous cycle</dd>
<dt>(text werner)</dt>
<dd>agree with paul</dd>
<dt>(text huigens)</dt>
<dd>+1</dd>
<dt>(text friedel)</dt>
<dd>+1</dd>
<dt>stephen & dkg</dt>
<dd>anything missing from points? [slide 7]
- no comments (feel free to bring to list)</dd>
<dt>dkg</dt>
<dd>points on list [slide 7] might not mean we reach charter, might find additional</dd>
</dl>
beyond merge of 4880bis
<dl>
<dt>dkg</dt>
<dd>[slide 8] curve448? S2K update (argon2)? weren't possible in last iteration</dd>
<dt>(text daniel huigens)</dt>
<dd>agree with those</dd>
</dl>
argon2
<dl>
<dt>werner</dt>
<dd>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</dd>
<dt>huigens</dt>
<dd>s2k update important, use cases do exist</dd>
<dt>andre</dt>
<dd>fully disagree, symmetric crypto covers long retention, any change is API breakage, introduces problems</dd>
</dl>
(more back and forth andre/huigens)
<dl>
<dt>derek</dt>
<dd>already have compat issues with pgp 2.6, bridge already crossed.</dd>
<dt>dkg</dt>
<dd>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.</dd>
</dl>
by this reasoning, symmetric openpgp crypto is stuck and we can never change it?
<dl>
<dt>andre</dt>
<dd>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</dd>
<dt>dkg</dt>
<dd>need specification yesterday on how to interpret, but don't generate.</dd>
<dt>(text andre)</dt>
<dd>agreed</dd>
<dt>stephen</dt>
<dd>create issue to track this issue</dd>
<dt>werner</dt>
<dd>argon2 has been discussed on ML, too. can't come to an agreement here, should leave discussion for later</dd>
</dl>
curve448
<dl>
<dt>stephen</dt>
<dd>thoughts on curve448?</dd>
<dt>werner</dt>
<dd>gnupg has curve448. noticed that to do properly this in spec, need new data type. that would take a while, maybe leave it out</dd>
</dl>
other updates?
<dl>
<dt>stephen</dt>
<dd>other updates for crypto-refresh, beyond bis?</dd>
<dt>angel</dt>
<dd>(on symmetric algos again), same issue with public keys (e.g. curve448). needs way to use new algorithms while keeping compatibility</dd>
<dt>(text neal)</dt>
<dd>not an issue because there is features subpacket</dd>
</dl>
userid-less keys
<dl>
<dt>andre</dt>
<dd>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.</dd>
<dt>stephen</dt>
<dd>should create issue for that</dd>
<dt>vincent</dt>
<dd>whole point of user id-less keys is so that you can get updates.</dd>
<dt>andre</dt>
<dd>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.</dd>
<dt>vincent</dt>
<dd>I would also like the next RFC to clarify this.</dd>
<dt>dkg</dt>
<dd>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</dd>
<dt>neal</dt>
<dd>user ids without signatures are ok. hagrid could add "null" user id, so 4880 already addresses this</dd>
</dl>
Upcoming meetings
<dl>
<dt>dkg</dt>
<dd>registration for IETF 110 open [slide 9]
- Meeting 2021-03-11 "Session II"</dd>
<dt>stephen</dt>
<dd>waivers available. based on honor system, please don't abuse</dd>
<dt>dkg</dt>
<dd>next interim? since IETF 111 is end of july. early may
more frequent meetings possible. if we want that, should focus on specific topics</dd>
<dt>(text paul)</dt>
<dd>early may sounds good</dd>
<dt>(text daniel huigens)</dt>
<dd>might be useful to hold semi-regularly</dd>
<dt>stephen</dt>
<dd>let's assume early may, confirm on list</dd>
<dt>derek</dt>
<dd>4-6 weeks sounds reasonable</dd>
</dl>
(sentiment that conferencing solution didn't work great, discussion about alternatives on list)
meeting closed 16:07 UTC