IETF 121 in Dublin
Monday, November 4th, 2024, 9:30-11:30 (UTC+1)
https://meetings.conf.meetecho.com/ietf121/?session=33433
Notes: https://notes.ietf.org/notes-ietf-121-cfrg
Chairs: Sean Turner, Nick Sullivan
Note-taker: Sean Turner, Conner Ybarra
no agenda bashes
Update on status; lots of extensions.
Motivating negotiations.
Richard: Can you moitivate why the stack needs to know about the
extensions.
Rohan: Need info to allow stack to perform functions for application.
Konrad: We intended safe extensions would have an internal
distinguishator (sp?).
Slide 6: The actual proposal.
Richard: Hate all of this, can fix last bullet (obviously). We worked
ourselves into a corner.
Rohan: Really need a negotiation mechanism.
Richard: A lot of the proposal is based on the stack enforcing security.
Richard/Rohan: Proposed virtual interims.
Motivating combiners; alternate proposal to a hybrid.
See slide 3 for mechanism.
Raphel: The difference between non-repudiation & authenticy.
Britta: doing updates with PQ only in the PQ ratchet. Keeping it simple
gave us the best of both worlds.
Raphel: You still have problem if an insider has a PQ computer. We
should implement this.
Sophie: Should be on the HPKE level. But, you can do this anyway ...
Britta: One of the proposals from IETF 119, but we can pivot if that's
what the WG wants to do. But, messing with the HPKE is more invassive to
the protocol.
Sohpie: Gives you a meta protocol (agreed).
Richard: I am okay with this approach.
Rohan: We also have a propopsal to do both pure and hybrid. Authors
didn't think that there was a problem.
Sean: Going to start a WG adoption call on the list.
No slides.
Awaiting drafts to mature: plain ML-KEM & three mixes.
Richard: Prefers to do GCEDiff.
Raphael: any overlap with encrypted group context vs extended?
Rohan: Don't know if there's an overlap.
Konrad: This is one option; proposals should/could have their own way.
Richard: Will work with Rohan on another version. Next version should be
ready for WG Adoption.
Richard: This is elaborate. It's a mini-MLS key schedule. Is there a
transform like Britta's (PQ Combiners) that could be applied here?
Konrad: It's not that more complicated.
Rohan: The way the I-D is written and it might be subbtle. For each
assoicated party there is a key schedule. Concept makes understanding
the security implications obvious.
Raphel: Keep it simple.
Britta: I like the security impications of this proposal. It's easy to
reason with.
Richard: Do we think we have enough way to solve it this way? I think
no.
Konrad: Not in a big rush.
Deirdre: I like it and it's just not that complex. Needs More eye, but I
think it's about there.
Emad: The Light member can eventually become a full member if they send
or receive a message from all members? How can I be part of the group if
I am not authenticating the whole group and I cannot see the tree with
all members?
Rohan Mahy: How does a Light Client know they were removed?
Richard Barnes: I don't have the asnwer to that right now.
Raphael: THis is not the worst of tradeoffs, but this is pretty
dangerous. Need more security considerations before we adopt this.
Britta: There is a need, but yeah we need seurity review because of the
effect on authenticity. If implementations get lazy there are many
dragons here. SecCons need to be clear about when you can use this
extensions.
Richard: Making sure Karthick will spend time making the SecCons better.
Rohan: Size of group, i.e., contexts, impacts where propoerties.
Deirdre: The blockchain community has experience with light clients. It
didn't include extra proofs, but light clients became very popular.
Britta: In terms of naming, we need to make sure the naming is direct
abbout the dragons.
Jöel: Looking for feedback!
Sophie: An alternative, is to put them in a merkle tree and let the DS
split. Nice in that you don't have to prove ...
Jöel: 1st we do have a paper that includes the security proof. Didn't
look like there was a difference in security - and the other approach is
bigger.
Richard: Formal analysis done yet?
Jöel: Pen and paper proofs are done.
No Slides.
Does not use associated parties.
Rohan: Makes sense; this sits right in the middle. In practice, should
really only publish to the associated partis that is needed to decrypt.
Richard: Combine with assoicated parties.
Rohan: Maybe.
Emad: Support!
Richard: Seems like a good idea. Could you restate why we need sep
secret trees.
Raphel: FS.
ROhan: Something in addition to support wire formats?
Rapheal: Yeah per message.?
Rohan/Richard: Not a fan.
Richard: Would have a dependncy.
WG Adoption Calls: