I'll take notes in https://notes.ietf.org/notes-ietf-125-cfrg# - anyone else is welcome to help
", "time": "2026-03-17T03:30:15.000Z"}, {"author": "Ti Bo", "text": "I'll do it too
", "time": "2026-03-17T03:30:53.000Z"}, {"author": "Richard Barnes", "text": "Hello Nick!
", "time": "2026-03-17T03:31:05.000Z"}, {"author": "Sean Turner", "text": "Hi! We got 10 here!
", "time": "2026-03-17T03:31:20.000Z"}, {"author": "Russ Housley", "text": "Is audio working for other people?
", "time": "2026-03-17T03:32:20.000Z"}, {"author": "Jonathan Hoyland", "text": "Yup
", "time": "2026-03-17T03:32:27.000Z"}, {"author": "Flo D", "text": "Fine here
", "time": "2026-03-17T03:32:35.000Z"}, {"author": "Stuart Card", "text": "I have no audio after trying the unmute/remute trick twice.
", "time": "2026-03-17T03:38:40.000Z"}, {"author": "Deirdre Connolly", "text": "One paper with proofs for UG generic hybrid KEM construction:
\nhttps://eprint.iacr.org/2026/125.pdf
And the other, with proofs for the CK construction (especially in constructing a hybrid kem with a C2PRI KEM like ML-KEM and a IND-CCA2 PKE like RSA-OAEP, as they want to do in LAMPS): https://eprint.iacr.org/2026/427.pdf
", "time": "2026-03-17T03:39:41.000Z"}, {"author": "Colin Perkins", "text": "Much thanks to the crypto review panel members \u2013 this is hugely important, if not very visible
", "time": "2026-03-17T03:40:07.000Z"}, {"author": "Alexey Melnikov", "text": "+1
", "time": "2026-03-17T03:40:37.000Z"}, {"author": "David Schinazi", "text": "@meetecho we're getting echo from the Shenzhen room
", "time": "2026-03-17T03:41:55.000Z"}, {"author": "Lorenzo Miniero", "text": "@David Schinazi is that better now? I decreased the gain for now
", "time": "2026-03-17T03:42:33.000Z"}, {"author": "David Schinazi", "text": "Yes, thank you
", "time": "2026-03-17T03:42:43.000Z"}, {"author": "Lorenzo Miniero", "text": "We'll boost it when people here get to the mic, but in case we miss it and they're quiet, please do let me know!
", "time": "2026-03-17T03:43:06.000Z"}, {"author": "Richard Barnes", "text": "i question whether this guidance is actually needed. protocols need to be agile w.r.t. KEM and WGs are increasingly not involved in choosing what code points to allocate
", "time": "2026-03-17T03:45:47.000Z"}, {"author": "Valery Smyslov", "text": "I think this will be useful to understand the difference in security properties of different KEMs. For example, different binding properties. Algorithm agility allows to replace one KEM with another, but you have to understand what the difference between them is.
", "time": "2026-03-17T03:49:01.000Z"}, {"author": "Mike Ounsworth", "text": "Richard Barnes said:
\n\n\ni question whether this guidance is actually needed. protocols need to be agile w.r.t. KEM and WGs are increasingly not involved in choosing what code points to allocate
\n
I 90% agree.
\nBut 10% of me is wondering if having a formal written justification for why to / not to publish various KEMs as RFCs is ultimately helpful, even if just to formalize our publication process against appeals.
Mike Ounsworth said:
\n\n\nRichard Barnes said:
\n\n\ni question whether this guidance is actually needed. protocols need to be agile w.r.t. KEM and WGs are increasingly not involved in choosing what code points to allocate
\nI 90% agree.
\n
\nBut 10% of me is wondering if having a formal written justification for why to / not to publish various KEMs as RFCs is ultimately helpful.
draft-barnes-tls-this-could-have-been-an-email
", "time": "2026-03-17T03:50:06.000Z"}, {"author": "Dennis Jackson", "text": "I sort of feel that the horse has already left the stable and is disappearing over the horizon. Maybe this makes sense a future looking document, but it might also be too soon to know what we'd do differently.
", "time": "2026-03-17T03:50:22.000Z"}, {"author": "Richard Barnes", "text": "The WGs already decided when they made the registries spec-required
", "time": "2026-03-17T03:50:33.000Z"}, {"author": "Mike Ounsworth", "text": "Richard Barnes said:
\n\n\ndraft-barnes-tls-this-could-have-been-an-email
\n
OMG you actually published that!!! Love it.
", "time": "2026-03-17T03:51:03.000Z"}, {"author": "David Lawrence", "text": "Awesome
", "time": "2026-03-17T03:51:37.000Z"}, {"author": "Deirdre Connolly", "text": "Oh and out of review of the first one here's a ProofFrog proof of the seed-based keygen indistinguishability of the X-Wing style keygen (a similar style is easy to show for the KEM+KEM style)
\nhttps://github.com/dconnolly/starfortress/blob/main/proof/prooffrog/SeedKeyGen.proof
", "time": "2026-03-17T03:53:04.000Z"}, {"author": "Eric Rescorla", "text": "I really do think \"is it secure\" is something that people need
", "time": "2026-03-17T03:53:11.000Z"}, {"author": "Eric Rescorla", "text": "But it would be very bad if the conclusion was that ML-KEM wasn't good!
", "time": "2026-03-17T03:53:45.000Z"}, {"author": "Mike Ounsworth", "text": "Just to echo Scott's point:
\nI had sort of assumed that if CFRG published a specification describing an algorithm they had approved it!
", "time": "2026-03-17T03:54:42.000Z"}, {"author": "Richard Barnes", "text": "\"We are publishing this algorithm as a cautionary tale. Beware!\"
", "time": "2026-03-17T03:55:22.000Z"}, {"author": "Donald Eastlake", "text": "Chair audio is faint for remote listeners.
", "time": "2026-03-17T03:55:55.000Z"}, {"author": "Lorenzo Miniero", "text": "Better now?
", "time": "2026-03-17T03:56:26.000Z"}, {"author": "John Preu\u00df Mattsson", "text": "CNSA 2.0 states that migrating firmware and software update is step 1. EU roadmap says that starting to migrate PKI and long-lived devices is as high priority as confidentiality. In IETF PQC signatures is the by far most mature field with ML-DSA and SLH-DSA RFCs for both PKIX and CMS already done.
", "time": "2026-03-17T03:58:11.000Z"}, {"author": "Donald Eastlake", "text": "Presenters were always loud enough. Can't tell till a chair speaks at the head table.
", "time": "2026-03-17T03:58:31.000Z"}, {"author": "Richard Barnes", "text": "this does not really seem germane for CFRG, chairs
", "time": "2026-03-17T04:02:10.000Z"}, {"author": "Eric Rescorla", "text": "Richard Barnes said:
\n\n\nthis does not really seem germane for CFRG, chairs
\n
More generally, I would prefer to see presentations that are directed towards driving discussion, not just updates
", "time": "2026-03-17T04:02:46.000Z"}, {"author": "Eric Rescorla", "text": "And by discussion I mean -> towards RG outcomes
", "time": "2026-03-17T04:03:09.000Z"}, {"author": "Mike Ounsworth", "text": "I mean, this is a cool talk about the social impacts of our tech, but I agree that there are other forums for content like this.
", "time": "2026-03-17T04:05:33.000Z"}, {"author": "Eric Rescorla", "text": "I certainly hope the answer is yes, given that you have to like decrypt it to display it. I mean, it's not like I can read the plaintext bits of the images
", "time": "2026-03-17T04:05:43.000Z"}, {"author": "Richard Barnes", "text": "@Eric Rescorla geez, try harder man
", "time": "2026-03-17T04:06:18.000Z"}, {"author": "Eric Rescorla", "text": "So like surely local AI processing is at least possible, though it could be implemented badly
", "time": "2026-03-17T04:06:28.000Z"}, {"author": "Richard Barnes", "text": "I do think she's mainly complaining about cloud-based AI
", "time": "2026-03-17T04:06:47.000Z"}, {"author": "Eric Rescorla", "text": "Richard Barnes said:
\n\n\nI do think she's mainly complaining about cloud-based AI
\n
Well I'm sure, but if the point of this preso is to analyze it, we gotta be clear.
", "time": "2026-03-17T04:07:49.000Z"}, {"author": "Nick Sullivan", "text": "Since the last IETF we\u2019ve split up the meetings between mostly speculative work and non-adopted community presentations and updates/decision points about active work. Scheduling hasn\u2019t made this split perfectly clean.
", "time": "2026-03-17T04:08:16.000Z"}, {"author": "Eric Rescorla", "text": "I mean it's leaving it encrypted
", "time": "2026-03-17T04:09:02.000Z"}, {"author": "Eric Rescorla", "text": "Like it got to you encrypted
", "time": "2026-03-17T04:09:07.000Z"}, {"author": "Eric Rescorla", "text": "I personally don't trust enclaves, but if enclaves actually worked, then why wouldn't this be fine?
", "time": "2026-03-17T04:09:21.000Z"}, {"author": "Eric Rescorla", "text": "Who is the audience for these recommendations?
", "time": "2026-03-17T04:09:59.000Z"}, {"author": "Eric Rescorla", "text": "So, I'd like to observe that the security of your device depends on the security of the software, which, you know, is dependent on how the device vendor maintains their signing keys
", "time": "2026-03-17T04:10:45.000Z"}, {"author": "Eric Rescorla", "text": "So this isn't really that clear-cut
", "time": "2026-03-17T04:10:51.000Z"}, {"author": "Rich Salz", "text": "\n\nScheduling hasn\u2019t made this split perfectly clean
\n
Shrug. Scheduling for this IETF, in particular, has been tricky. I think this talk is more along the lines of what other IRTF RG's do. I'm fine with it.
", "time": "2026-03-17T04:11:08.000Z"}, {"author": "Eric Rescorla", "text": "Like if Apple's signing keys are compromised, then they can just steal your data off the phone
", "time": "2026-03-17T04:11:21.000Z"}, {"author": "Richard Barnes", "text": "Clearly all of these things are technically compatible with E2EE
", "time": "2026-03-17T04:12:14.000Z"}, {"author": "Eric Rescorla", "text": "yeah I don't understand what it means to be \"not compatible with E2EE\"
", "time": "2026-03-17T04:12:27.000Z"}, {"author": "Eric Rescorla", "text": "Like, is link preview also not compatible with E2EE?
", "time": "2026-03-17T04:12:36.000Z"}, {"author": "David Waite", "text": "Is sharing a message from a private chat on a social network not compatible with E2EE?
", "time": "2026-03-17T04:13:44.000Z"}, {"author": "David Waite", "text": "This seems quite a bit like policy on information and user expectations and an example of more overloading of E2EE as a \"feel\" rather than a technical property
", "time": "2026-03-17T04:14:51.000Z"}, {"author": "Deirdre Connolly", "text": "This is pushing back on Apple, Meta, claiming that offloading plaintext to a TEE-backed model is 'extending the ends of end-to-end encryption'
", "time": "2026-03-17T04:16:20.000Z"}, {"author": "Deirdre Connolly", "text": "(it is not)
", "time": "2026-03-17T04:16:23.000Z"}, {"author": "Deirdre Connolly", "text": "If their off-device models were processing ciphertext, as in FHE, it at least preserves the security and privacy properties
", "time": "2026-03-17T04:17:01.000Z"}, {"author": "Eric Rescorla", "text": "Deirdre Connolly said:
\n\n\nIf their off-device models were processing ciphertext, as in FHE, it at least preserves the security and privacy properties
\n
This just seems like arguing about definitions. I would prefer to just describe the security properties.
", "time": "2026-03-17T04:18:00.000Z"}, {"author": "Eric Rescorla", "text": "Like, at this point the term E2EE is more confusing than helpful, so if we need precise terms, rather than trying to redefine E2EE, invent some new acronymic terms
", "time": "2026-03-17T04:18:43.000Z"}, {"author": "Deirdre Connolly", "text": "Eric Rescorla said:
\n\n\nDeirdre Connolly said:
\n\n\nIf their off-device models were processing ciphertext, as in FHE, it at least preserves the security and privacy properties
\nThis just seems like arguing about definitions. I would prefer to just describe the security properties.
\n
it is; it's tough when 'end-to-end encryption' doesn't have a nailed-down security game, and has become more of a branding thing, similar to 'zero trust'
", "time": "2026-03-17T04:18:49.000Z"}, {"author": "David Waite", "text": "if that is a claim they are making, sure, because that is technically incorrect. However E2EE is being overloaded as a privacy property and it is instead an important tool to get that privacy property
", "time": "2026-03-17T04:19:17.000Z"}, {"author": "Eric Rescorla", "text": "To be clear, I am no TEE fan. I just don't think this is the way to make that point
", "time": "2026-03-17T04:19:43.000Z"}, {"author": "Deirdre Connolly", "text": "we wouldn't be talking about this except that Apple, Meta, etc really really want to ship AI and their products and really really want to make a trusted compute server 'extend' the end of their advertised security guarantees
", "time": "2026-03-17T04:19:49.000Z"}, {"author": "Mike Ounsworth", "text": "How we, as the cryptographic community, communicate this stuff to the public super duper matters. Esp. in countries where people's lives depend on their communications being private (esp. from their own governments), the difference between \"Extended E2EE\" and \"Actually Confidential\" really really matters.
", "time": "2026-03-17T04:20:17.000Z"}, {"author": "Eric Rescorla", "text": "Deirdre Connolly said:
\n\n\nwe wouldn't be talking about this except that Apple, Meta, etc really really want to ship AI and their products and really really want to make a trusted compute server 'extend' the end of their advertised security guarantees
\n
Right, but what's wrong with that is that those trusted compute servers don't deliver those guarantees. If they did, it would be different!
", "time": "2026-03-17T04:20:22.000Z"}, {"author": "Dennis Jackson", "text": "I think I agree with the point, but I'm not sure the message was so clear in this presentation.
", "time": "2026-03-17T04:20:30.000Z"}, {"author": "Deirdre Connolly", "text": "If anyone solves FHE-powered LLMs, great, deploy that; or, make the LLMs very very small and efficient to fit on-device, as Mallory said
", "time": "2026-03-17T04:20:36.000Z"}, {"author": "Deirdre Connolly", "text": "(i think the latter is more likely than the former and fits even nicer into existing models of E2EE messaging etc)
", "time": "2026-03-17T04:21:04.000Z"}, {"author": "Deirdre Connolly", "text": "Eric Rescorla said:
\n\n\nDeirdre Connolly said:
\n\n\nwe wouldn't be talking about this except that Apple, Meta, etc really really want to ship AI and their products and really really want to make a trusted compute server 'extend' the end of their advertised security guarantees
\nRight, but what's wrong with that is that those trusted compute servers don't deliver those guarantees. If they did, it would be different!
\n
for them it's a marketing exercise that hurts users
", "time": "2026-03-17T04:22:03.000Z"}, {"author": "Mike Ounsworth", "text": "Mike Ounsworth said:
\n\n\nHow we, as the cryptographic community, communicate this stuff to the public super duper matters. Esp. in countries where people's lives depend on their communications being private (esp. from their own governments), the difference between \"Extended E2EE\" and \"Actually Confidential\" really really matters.
\n
Like, if some company claims that their thing is \"E2EE Via Secure Cloud AI\" ... and then a user gets arrested anyway because it turned out that E2EE system was not designed to be protected from subpoena, that's not gonna match the user's expectation.
", "time": "2026-03-17T04:22:38.000Z"}, {"author": "Michael Richardson", "text": "test vectors without wire formats... I guess it has to include things like formats for numbers.?
", "time": "2026-03-17T04:23:45.000Z"}, {"author": "Eric Rescorla", "text": "So, Chairs, it's really unfortunate that now we don't have time for discussion of this importnat topic!
", "time": "2026-03-17T04:25:30.000Z"}, {"author": "John Gray", "text": "Yes, agreed Mike. I have come to the conclusion that it is really hard to trust anything online these days. Like just because they have a splashy page that says I am protected, can I trust it...
", "time": "2026-03-17T04:25:48.000Z"}, {"author": "Dennis Jackson", "text": "My main concern is about the bandwidth of the CFRG. When we spin up a dedicated WG for new crypto, I would like to see it own all of the crypto, subject only to a Crypto Panel Review.
", "time": "2026-03-17T04:26:10.000Z"}, {"author": "John Gray", "text": "I was just a the JOSE working group and they are adding in the PQ and hybrid algorithms... Much time used up on which algorithms to use, etc... Oh, Nick just said the same thing...
", "time": "2026-03-17T04:28:10.000Z"}, {"author": "Alexey Melnikov", "text": "@EKR: it is. We can see if we can have a bit of time on Thursday for discussions. Or we might have to continue on the CFRG mailing list
", "time": "2026-03-17T04:28:25.000Z"}, {"author": "Eric Rescorla", "text": "Alexey Melnikov said:
\n\n\n@EKR: it is. We can see if we can have a bit of time on Thursday for discussions. Or we might have to continue on the CFRG mailing list
\n
Well this goes to my main thesis: fewer, longer presentations, oriented towards discussion, not updates.
", "time": "2026-03-17T04:29:00.000Z"}, {"author": "Eric Rescorla", "text": "Eric Rescorla said:
\n\n\nAlexey Melnikov said:
\n\n\n@EKR: it is. We can see if we can have a bit of time on Thursday for discussions. Or we might have to continue on the CFRG mailing list
\nWell this goes to my main thesis: fewer, longer presentations, oriented towards discussion, not updates.
\n
And if there's not time for that, then cut all presentations for new work.
", "time": "2026-03-17T04:29:17.000Z"}, {"author": "Mike Ounsworth", "text": "My main comment to Nick's process proposal is: is CFRG willing to commit to an SLA? To me, the important property of that SLA would be that CFRG not decline / delay work items that are gating IETF WGs. In effect, that's asking CFRG to behave more like a WG rather than a RG when handling WG-blocking work items.
", "time": "2026-03-17T04:31:08.000Z"}]