IETF 119 in Brisbane
Monday March 18, 2024, 13:00-15:00 (UTC + 10)
https://meetings.conf.meetecho.com/ietf119/?session=31924
Jabber: cfrg@jabber.ietf.org
Notes: https://notes.ietf.org/notes-ietf-119-cfrg
Chairs: Stanislav Smyshlyaev (SS), Nick Sullivan (NS), and Alexey
Melnikov (AM)
https://datatracker.ietf.org/meeting/119/materials/slides-119-cfrg-chairs-slides
Agenda bash: swapping last two slots (KEMs last, John Bradley before)
and there's
an additional if-time-permits talk that may happen
Doc status was reviewed - see slides.
WRT hybrid PQ KEMs chairs are forming a design team, more news later.
Christopher Patton: where's the guidelines for crypto specs at? Nick
Sulivan (as author)
will be progressing
Dan Harkins: what about my HPKE draft? A: needs shepherd follow up.
Crypto review panel refresh, members listed. (See slides)
Colin Perkins: as IRTF chair, thanks to crypto panel and chairs for
organising
https://datatracker.ietf.org/meeting/119/materials/slides-119-cfrg-hedged-ecdsa-and-eddsa-signatures
Changes, open issues and next steps covered in slides.
If someone wanted to help provide proofs, that'd be welcome.
Christopher Patton: wrt issue#3 on github - would like to understand
motivation for issue.
John: we made a related change for another reason anyway (to avoid
possible collisions).
CP: outcome seems fine.
Motivation/background, differences from GCM, industry interest covered
in slides.
Q from John: CFRG adoption? Chairs will discuss adoption between
themselves first.
Christopher Patton:
- do IETF WGs need this?
- John: maybe SRTP for media encryption
- how much could this be changed by CFRG if desired?
- John: CFRG changes would be fine, no need to necessarily be 5G
compatible
Scott Fluhrer: comment, audio doesn't necessarily need this
https://datatracker.ietf.org/meeting/119/materials/slides-119-cfrg-ml-kem-for-hpke
Goals/reqs, re-encapsulation attacks (Cremers et al) covered in slides.
Discussion (in slides) of how/why DHKEM from RFC9180 is ok but ML-KEM
isn't as strong
(though Kyber was) in terms of binding properties. Not catastropic for
ML-KEM, but not
the same as DHKEM, and can be even worse for other KEMs (e.g. Classic
McEliece). Two
possibilities: do HPKE thing just for ML-KEM or modify HPKE to be ok
with that or other
KEMs (e.g. Classic McEliece). Current draft is specific for ML-KEM.
Kris Kwiatkowski: are binding properties needed when ML-KEM decrypt
fails? A: no.
Rohan Mahy: scheme from this draft could be useful: in TLS, or for JWTs.
Comment: first
do the concrete obvious thing, then think about any RFC9180bis later.
dradt-mouris-cfrg-mastic, VDAF/PPM/heavy-hitters related background
covered in slides
Authors plan is next draft could be suitable for RG adoption call.
Meanwhile:
Q1: should we do s/poplar1/mastic/ in draft-irtf-cfrg-vdaf?
Tim Geoghegan: supports mastic, also 'cause faster
- chairs: take Q1 to list
Q2: how to handle dev/review of new VDAFs?
- chairs: also take to list
There's a related side-meeting on MPC Thursday P6/7
draft-chen-cfrg-vdaf-pine, federated ML use-case covered in slides
Some work planned for draft then wondering about RG adoption.
Roman Danyliw: does PPM want to support this use-case? A: just proposed
to PPM, so waiting for feedback on that.
Nick (as chair): PPM hasn't asked CFRG for this.
Chris Patton: as above, not currently in PPM charter but discussions
happening.
Martin Thomson: this affects workloads on different participants,
discussion on that needs to first happen in PPM not here
draft-bradleylundberg-cfrg-arkg, motivation covered in slides.
Covers ways to generate key pairs (with non-linkable public keys?) from
seeds.
Asking for review and feedback on draft, not yet for RG adoption.
Alexey (as chair): wanna ask crypto-panel? A: maybe, perhaps still a bit
early.
Chairs: tee'd up talk via recap of list discussion on KEMs and all the
various opinions seen
Slides cover background incl. private/enterprise PKIs and S/MIME that
are very RSA based
and argue that considering that RSA deployment might enable speedier
migration to hybrid KEM
use
Rohan Mahy: understand the QA delay points, but doesn't see evidence
that keeping RSA makes for any speedup
Mike: if I don't have EC today...
Rohan/Mike argue: note-takers lost in compilers;-)
Rohan: skeptical about this
Mike: would like to be able to share customer use-case, can't yet
Rich Salz: question to chairs - where's this gonna go?
Nick: chairs hope DT will help with reqs that can be discussed on list
Scott Fluhrer: we have same problem
SF: where do we stop with all these options?
Nick: TLSv1.3 did a good job there, maybe we'd like to do similarly and
limit well-defined code-points, maybe allowing additional code-point
registries, balancing act
Aron Wussler: we will need to decide if we want different combiner
constructions or one generic one, but some protocols need to go ahead
now so if we're slow we risk them doing their thing
Jonathan Hoyland: maybe also produce a die-die-die draft for some of the
options on which we're not keen
Nick: might make more sense in IETF than IRTF
Chairs: discussion will continue online and with DT
https://datatracker.ietf.org/meeting/119/materials/slides-119-cfrg-formal-analysis-of-ra-tls
RA == remote attestation, sought but didn't get much feedback from TLS
WG so asking here
slides cover background/problem related to "confidential computing"
Jonathan Hoyland: Not an author of the relevant paper but did study it
and thinks it covered draft-18 and not draft-20.
MUS: published paper was -18 but artefacts later updated to -20
JH: Do artefacts cover -18?
MUS: changes from -18 to -20, still make us wonder
JH: Maybe some of this was just unfinished work
MUS: still having difficulty figuring out model
14:56 - AOB?
Nope, all done.