Minutes IETF125: cfrg: Thu 01:00
minutes-125-cfrg-202603190100-00

Meeting Minutes Crypto Forum (cfrg) RG
Date and time 2026-03-19 01:00
Title Minutes IETF125: cfrg: Thu 01:00
State Active
Other versions markdown
Last updated 2026-03-23

minutes-125-cfrg-202603190100-00

CFRG - IETF 125 Session 1

Tuesday March 17, 2026, 11:30-12:30 (UTC+8)

https://meetings.conf.meetecho.com/ietf125/?session=35061
Jabber: cfrg@jabber.ietf.org
Notes: https://notes.ietf.org/notes-ietf-125-cfrg

Chairs: Alexey Melnikov, Stanislav Smyshlyaev and Nick Sullivan

Note Takers: Dan York, Yan Bo Ti

11:30 - Stanislav Smyshlyaev, "Chairs' update" (5 mins)

No questions.

11:35 - Nick Sullivan, "KEM Security Considerations" (5+5 mins)

  • Slides:
    https://datatracker.ietf.org/meeting/125/materials/slides-125-cfrg-pq-kems-02

  • Adopting per-KEM security evaluation documents. Currently only have
    it for ML-KEM.

  • Only accepting PQ KEMs that have received "extensive" review.
  • Questions for discussion:
    1. Do we need a design team for common evaluation criteria?
    2. Is mailing list sufficient?
    3. Who will write security evaluation document for a PQ KEM?

Question 1 (by Rohan Mahy): What's the proposed output of this
process?

Answer: The proposed output is an adoption of a group of docs that
provides security considerations for protocols.

Question 2 (by EKR): How am I supposed to interpret the output of
this process?

Answer: Read the ML-KEM docs for what is relevant, e.g. sizes, side
channels, etc. It's more targeted at prolifieration group, not the
crypto groups. No considerations beyond ML-KEM, so no comparison point
at the moment. The process is still fluid.

Question 3 (by Xianhui Lu): From the technical side, I think a team
is more suitable. He offers to help with the document.

Answer: Acknowledge help.

Question 4 (by Diedre Connolly): Maybe mailing list is sufficient.
(Discussion about the questions.) Maybe we

Answer: Acknowledge comments.

Question 5 (by Gefei Li): (question about one of the drafts)

Answer: (Scott) We are not considering if ML-KEM is secure. We are
making sure that ML-KEM is specified securely. (Nick) At the moment,
things are still fluid and we are looking at security evaluations.

Question 6 (by Russ Housley): I find this perplexing. As chair of ()
we have in charter to only use NIST or CFRG-approved algorithms.

Answer: CFRG do not approve algorithms.

Question 8 (by Valery Smyslov): Do you think about PQ algorithms in
signatures?

Answer: This is exclusively about KEMs, signatures can go through a
similar process with interest and energy to write the document and if
there is a need to do it. KEM is the focus for now, although signatures
are equally important.

11:45 - Michele Orru, "Sigma protocols and Fiat-Shamir" (5+5 mins)

No questions

11:55 - Mallory Knodel, "End-to-End Encryption and AI" (10+5 mins)

  • Slides:
    https://datatracker.ietf.org/meeting/125/materials/slides-125-cfrg-sessa-how-to-think-about-e2ee-and-ai-00

  • Goal: Analyse processing of message content by integrated AI models
    in under E2EE.

  • Research directions:

    • Security considerations about what kinds of AI integration are
      compaitble with E2EE.
    • What are the legal and normative considerations for disclosure
      and consent.

  • Comparing between cloud-based & local architecture, and also E2EE &
    TEE

  • Recommendation 1: E2EE content to train shared AI models are not
    right
  • Compatible with E2EE: On-device model, and server-side inference
    under FHE for fine-tuning
  • Not compatible with E2EE, but has some security measures: Apple
    Intelligence using TEE, server-sdie inference on separate per-user
    fine-tuned models on TEEs
  • Bad: Server-side PT inference without fine-tuning
  • Recommendation 2: (a) Prioritise endpoint-local processing, (b) if
    processing E2EE content for non-endpoint-local, ensure 3rd parties
    cannot see/use E2EE content, and user's E2EE content is used for
    user's needs.

Question 1 (by John Preuss Mattsson): I hope advanced use of crypto
doesn't turn into privacy theatre. Question - on slide 15, you said FHE
was compatible... wouldn't you need multiparty encryption?

Answer:

[No further time for questions.]

12:10 - Nick Sullivan, "Two-Lane Publication Model for Cryptographic
Mechanisms" (10+10 mins)

  • Slides:
    https://datatracker.ietf.org/meeting/125/materials/slides-125-cfrg-two-lane-model-02

  • Title: "How do we standardize cryptography at the IETF?"

  • What is broken today?

    • WGs use primitives without crypto panel review
    • Crypto issues surface at Last Call

  • Proposes a "two-lane model"

    • Cryptographic foundation
    • Protocol profiles

  • Questions:

    • Is Lane 1 a feasible way to motivate consistent, useful research
      documents from within the CFRG?
    • Are there cases where the two-lane separation creates friction
      rather than clarity?
    • Should this become a BCP, or is informational guidance
      sufficient?

No questions as we are out of time.

CFRG - IETF 125 Session 2

Thursday March 19, 2026, 09:00-11:00 (UTC+8)

https://meetings.conf.meetecho.com/ietf125/?session=35062
Jabber: cfrg@jabber.ietf.org
Notes: https://notes.ietf.org/notes-ietf-125-cfrg

Chairs: Alexey Melnikov, Stanislav Smyshlyaev and Nick Sullivan
Notetakers: Muhammad Usama Sardar, Dan York, Yan Bo Ti

09:00 - Nick Sullivan, "Two-Lane Publication Model for Cryptographic Mechanisms" - Discussion (10 mins)

Michael (NCSC): What about competing requirements?
Nick: Find the best parameterization. Not aiming to have just one
document, but have a slate of documents for different use-cases and WGs.

Eric Rescorla: Walk through an example. What if some WGs wants
ML-KEM?
Nick: Refers to slide 3, and walks through an example where 3 WGs
want to use ML-KEM. Following the flowchart, the decision is to form a
dedicated WG.
Eric Rescorla: We need to consider two things: is a scheme good, and
guidance on how to use a scheme. So if the scheme chosen is NTRU instead
of ML-KEM, what do we do?
Nick: The crypto panel could review it.

Jonathan Hoyland: Is the main goal to reduce load of CFRG?
Nick: Centralized path - a place for groups to bring their
cryptographic questions

Comment from Stephen Farrell in chat: an IETF BCP for this seems
like a good plan to me; not sure the current text is perfect but the
process of making a BCP should fix things

09:10 - Abhi Shelat, "Longfellow ZK" (10+5 mins)

  • Slides:
    https://datatracker.ietf.org/meeting/125/materials/slides-125-cfrg-longfellow-zk-00
  • Use-case is ZK schemes for small identity theorems which is more
    secure than existing solutions.
  • SD-JWT/Oauth interested
  • Prefernce is to go PQ and not use ECC
  • Introduced Longfellow ZKP

  • Current status:
    -- ISRG completed 2nd implementation (bit compatible),
    -- 3 security reviews completed,
    -- improved performance

  • Comparison with Vega: Vega is not PQ secure; does not have
    traditional security argument because it uses the folding technique.

Bas: Great work. Compare with competing technique VOLE-in-the-head.

Abhi: VOLEitH does not scale well because you need one bit per
witness, so it does not scale well. We can carry on discussions.

John Preuß Mattson: Strongly agree not to deploy quantum only at
this stage. Want to see more comparisons with different schemes.
Abhi: Will follow up on email

Eric Rescorla: Fast enough for most applications.
How we get to a usable system?
Abhi: This implementation already supports DCQL query format. It may
not support more general proofs, but it is a good start for now.

Brent Zundel: Supports this work. Fan of Longfellow. Consider naming
it something less general.
Abhi: Thanks for the feedback.

Tanja Lange (chat): You mention fedback from the EU? Did you
actually get the EUDI wallet people to show interest in ZK?

09:25 - Xianhui Lu, Yijian Liu, "NTRU-based Public Key Encryption" (10+5 mins)

Bas Westerbaan: From performance angle, this is an improvement. But
we can't just adopt this. We need to have analysis for years. This is
years away before we can trust it.
Can we have a 768 level? I.e. Security level 3?
Yijian: Current parameter set only provides 1st and 5th security
level.

John Preuß Mattson: Happy to see focus on key exchange sizes. Agree
that we look at DAWN instead of NTRU, and agree with Bas that more
analysis is needed. Hoping that Yijian can submit this scheme to the
CHinese PQ standards so that more analysis can be done there.
Yijian: Thank you for the input.

Eric Rescorla: Needs some bake (maturity and testing) time. Is there
a reduction from DAWN to one of these other variants?
Yijian: Yes,

Nick Sullivan: At the last CFRG we announced we are seeking security
considerations for individual KEMs? Are you willing to write a security
considerations draft?
Yijian: Sure

Some links from chat:
https://eprint.iacr.org/2025/1520
https://developer.apple.com/videos/play/wwdc2025/232/
https://educatedguesswork.org/posts/age-verification-id/

09:40 - Xianhui Lu, Xuan Shen, "Recent Advances in Fully Homomorphic Encryption (FHE)" (10+5 mins)

Stanislav Smyshlyaev(chair): Add topic to mailing list so that
people can add requests, and we can understand what people need from us.
In one month, there will be a nomination to crypto panel. Please look
for the call for nominations.

Lilun: We have a protocol gap to process ciphertexts.

(Debates in chat):

  • whether CFRG should focus on IETF work only?
  • CFRG should not do anything unless there is specific IETF-demand.
  • The charter is more general than IETF only.
  • It's cool but how it benefits from standardization?
  • Some more debates on the scope of CFRG
  • Good for IRTF to work for maturity of FHE

09:55 - Xinshu Ma, "Low-latency PQ authentication" (10+5 mins)

Questions raised by Xinshu:

  • Are we using the underlying primitives correctly?
  • Do the security properties we relay on actually hold?
  • Are there better constructions we should consider?

Andrei Popov: Couldn't this be done with pre-shared keys shared out
of band in TLS?
(Discussion in the room)

Next step by chairs: Continue on list

10:10 - Guilin Wang, "HMAC Based Hybrid Key Combiners for Multiple Keys" (5+5 mins)

Scott Fluhrer: Why HMAC and not SHAKE?
Guilin: HMAC is popular. Will consider SHAKE.
Further debates on this in chat.

Deirdre: Pre-print is not available. Security properties are not
clear.
HKCv1 is a secure random extractor but not a secure combiner?

Guilin: Paper is published; will add the link.
https://link.springer.com/chapter/10.1007/978-981-95-6206-0_12

10:20 - Lucas Prabel, "Hybrid Digital Signatures with Strong Unforgeability" (10+5 mins)

Scott Fluhrer: Strong preference for black-box construction; we
don't want people to break open signature schemes on their own.

Chairs: Discuss further on list

Debates on different interpretations of hybrid in the chat.

Valery Smyslov (chat): Why not use "composite hybrid" vs
"non-composite hybrid"? This is a terms from pquip RFC

https://datatracker.ietf.org/doc/html/rfc9794

John (chat): my interpretation is that such a non-hybrid signature
migration is allowed by EU and ANSSI. You need to start migrating
trust anchors now, which can be SLH-DSA, but could wait with migration
of short-lived end-entity certificates.
https://na.eventscloud.com/file_uploads/b635298de1c10be6d3732863e8b1beca_Day2-1600-ANSSI.pdf

10:35 - Emil Lundberg, "The Asynchronous Remote Key Generation (ARKG) algorithm" (5+5 mins)

No questions.

10:45 - Muhammad Usama Sardar, "Relay Attacks in Intra-handshake Attestation and Proposed Solution in Post-handshake Attestation" (15 mins)

  • Slides:
    https://datatracker.ietf.org/meeting/125/materials/slides-125-cfrg-relay-attacks-00
  • Primarily a request to CFRG for recommendations and guidance

  • Request for guidance: is level 2 sufficient?

  • Core idea is exporters for Certificate, CertificateVerify, and
    Finished messages to bind them all to the connection.

  • Slide 3/18: Is binding level 2 sufficient?

  • Slide 4/18: Is binding Evidence to
    client_handshake_traffic_secret sufficient? In the slide, I am
    presenting my arguments for why I believe it is not. I would like to
    hear if there is any disagreement.
  • Slide 5/18 shows why we believe binding Evidence to TLS client nonce
    is insufficient.
  • Slide 6/18 shows why we believe binding Evidence to server's public
    key is insufficient.
  • Slide 7/18 confirms Cocos AI acknowledgement of attacks.
  • Slides 9-11/18 are a quick reminder for next discussion.
  • Slides 13/18 is how I envision the design of protocol with two keys
    (proof of possession in steps 2b and 3c). Here I want to discuss if
    I am missing something.
  • Slides 15/18 is purely cryptographic. I want to discuss if my
    reasoning on slide 16/18 based on this is correct cryptographically.

Richard Barnes (chat): "if the secret thing leaks, the system breaks"
seems like a pretty standard caveat

Usama: IMHO, the whole point of composing remote attestation is to
provide a second trust anchor. So if the security argument is still
based on single-point-of-failure of single key, remote attestation adds
not much value in reality.
Moreover, security should not be based on the leakage of this key
because multiple attacks (tee.fail, wiretap.fail, badram etc.) have
shown it be the case, and hardware vendors are just saying:
side-channels are out of scope. We believe we need protocol designs to
be more robust to take care of such attacks.

Jonathan Hoyland (chat): Does the key need to leak, or would oracle
access be sufficient?

Usama: acknowledged, I think both may be orthogonal, but need to
double-check.

Chairs: follow-up on list

https://mailarchive.ietf.org/arch/msg/cfrg/sUQnF1KOL5XsvCwY0VRASICk3T4/

10:55 - AOB

Deirdre: New draft
https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-ml-dsa-security-considerations

Chairs: Call for nomination of crypto panel