Minutes interim-2024-openpgp-01: Mon 15:00
minutes-interim-2024-openpgp-01-202402261500-00

Pre IETF-119 OpenPGP "interim"/sync-up

Agenda:
- sync-up!

Present:

• dkg
• stephen farrell
• Andrew Gallagher
• Aron Wussler
• Daniel Huigens
• Falko Strenzke
• Johannes Roth
• Juan Cerezo
• Justus Winter
• Michael Richardson
• Stavros Kousidis

Stephen: Chat about the algorithm selection and what needs to be
prepared for the IETF. No need for queueing in this meeting. Who will be
in Brisbane?

Slides should be there ahead of time. should be more verbose than normal
in case of technical problems during IETF 119.

DKG: no need to be too verbose in the slides if that delays sending
them. Earlier ist better.

Stephen: Agenda will mostly be PQC.

DKG: Milestone says that we might choose a 2nd topic at IETF 119.

Stephen: "What next?" will another item
PQC topics will be signature, KEM and KEM-combiners

Stavros: What about splitting the drafts: If we go for a split, what
would be the status of the RFCs besides the core RFC for PQC? Would they
be informational RFCs?

Stephen: Core algos would aim for "proposed standard". Other docs could
also be proposed standard as well, but could be informational. But could
write doc without the WG, but WG will be asked about it at some point
anyway. Ways of splitting the drafts could be a result from this session
or later list discussion.

Stavros: We should avoid a cascade of splits. There should be
well-grounded reasons for the choices of algorithms in each draft.
Criteria should exist for proposing algos to the WG.

DKG: Designated expert review for IANA allocation would not cause
preclusion of too large keys because of concerns for key servers.

Stephen: The core document should include all relevant algorithm types
(signature, encryption). We should give advice to the IESG who can be a
designated expert. The working group will have a chance for commenting
before code point allocation.
Who can present the topics?

Aron: Thread for KEM-combiners still needs to be send out. For the
feedback that was collected, should that be integrated in a new draft
version?

DKG: Yes, makes sense to have before cut-off date to indicate to the WG
which way the editors think we are heading.

Stephen: Mention code point changes. No need to split it at this point.

Aron: Then we will more or less just take the github state and make a
new version. Then we would collect feedback on KEM combiners before
cut-off.

Stephen: KEM-combiners will be a topic across multiple WGs at IETF.

Stavros: TLS is special and they tried to get their combiners in early.
For OpenPGP there does not seem to be a need for a specialist solution.

Aron: Would like to have a general solution. But it currently does not
seem close. Later adoption of the CFRG solution will break existing
code. Our combiner is based on the generic combiner from the
ounsworth-combiner draft.

Stavros: possibly to defer the discussion until next IETF.

Falko: agree.

Stephen: disagree.

Aron: Much disagreement in CFRG currently. Stavros, would you also like
to send out KEM-combiner thread message?

Stavros: Would send it out but say that we will postpone it till next
IETF and now focus on the set of algorithms and splits.

Stephen: One issue with KEM combiner session is how to not make it hard
for library implementers. Set of libraries used for OpenPGP is different
for instance to S/MIME probably. Also think can say on list: this is
discussion in CFRG. Probably want to follow CFRG conclusions. Summer is
earliest to expect any output from CRFG.

Stavros: Current discussion in CFRG is too much random-walk currently

Stpehen: going ahead now is better

DKG: At least inform the implementers about the current construction in
the draft.

Stephen: Input from OpenPGP implementers is possibly also useful to
CFRG. Security features of combiner must fit OpenPGP use cases.

Stephen: We have covered the topics for today. Any other topics.

Aron: Keep the discussion on the list active is useful. KEM thread
received more interest than signatures. Maybe signatures not considered
that relevant yet. But keep them together. Also mere approval will be
useful on the list.

DKG: Will the revised version have a test vector? Could be integrated in
interop test suite?

Justus: could integrate into test suite, yes.

Johannes: we still have Dilithium round 3, not yet ML-DSA.

DKG: Monday is cut-off. Could have test vector v6 key with Ed25519 and
ML-KEM. Usefull for implementers.

ARon: don't now whether still can have test vector in the draft

DKG: would be better

Stephen: other topics for IETF 119? No apparently.
Anyone want to present topic for next rechartering algorithm.

Justus: Good idea to allow encryption with v4?

Aron: I now think is good. Because is an opportunistic upgrade: can
ignore unknown subkey. Allowing interop with older implementation and
have PQC encryption at the same time. Allow quick PQC encryption. There
are implementers that are not yet ready for migration to v6. Giving them
v4 PQC encryption speeds transition.

Justus: Doubt that v4 PQC will be supported by implementers.

Stavros: Concern about breaking implementations with this?

Justus: Don't buy the smooth transition.

DKG: Could drive the discussion about this. Might present at the IETF.

Justus: Will have slide or two.

DKG: If you encrypt to PQC and to and traditional that should not work.

Stavros: Was meant as upgrade path for GnuPG. But now Werner Koch
announced different ideas about PQC.
Idea was to give implementations possibility of a smoother upgrade path.

DKG: Be clear about what we are talking about exactly when posting on
the list.

Aron: should we start a thread about binding of key and PKESK versions?

Stephen: yes, but wait a bit

Aron: wait 10 days after KEM-combiner thread message. Should I also talk
about transition?

Stephen: multiple views on transition will be good, too.

Stephen: have to drop.

DKG: Any other topics? Don't have to use the full hour.

Justus: I have followed the CFRG discussion about KEM-combiners, could
s.o. summerize

Aron: There was call for adoption for the topic for which there were
multiple drafts: generic (ounsworth), X-Wing, ...
TLS came also in with their opinion. Mike and LAMPS came in with
requirement to use RSA. DJB raised multiple points. Conversation evolved
into very highly specialized topics. All have advantages and
disadvantages. Differ in proves and efficiency. Come up with 5 minute
talk about what should be done. CFRG wants to have design team to create
a solution that is suitable for everyone.

DKG: We might not want to wait for the solution of this process. We have
to make a decision.

Aron: As long as we commit to s.th. that is cryptographically sound, it
will be find. Security is not really questioned in any design in the
CRFG discussion. Questions: do we have to optimize our combiner.

Stavros: X-Wing is a good paper. But one reason against it, is that it
is tailored to ML-KEM. Thus not a generic solution that can function as
a blueprint.

DKG: We don't have a good way of signalling asymmetric preferences. Thus
integrating more asymmetric algorithms is not to be foreseen.

Justus: Please use a generic combiner, not a specialized one.

DKG: This kind of preferences should be presented on the list.

Justus: I am fine with KMAC.

Justus: Discussion about splitting the algorithms. What is the reason?
Latency?

DKG: Depends on the split. If the goal is to have spec for some
algorithms, this reduces the latency. Narrow the focus for core
algorithms and at the same time allow other proposals in different
documents.

Aron: Splitting also allows to find out whether certain algorithms are
being pushed in the first place or not.

DKG closes the session