[{"author": "Yoav Nir", "text": "

Thom Wiggers said:

\n
\n

Goodmorning ~vietnam~ CFRG

\n
\n

We really should meet in Vietnam some time. Just for that.

", "time": "2026-07-22T07:00:18.000Z"}, {"author": "Kris Kwiatkowski", "text": "

:love_you_gesture:

", "time": "2026-07-22T07:01:32.000Z"}, {"author": "Pascal Sch\u00e4fer", "text": "

Good morning

", "time": "2026-07-22T07:03:48.000Z"}, {"author": "Robert Moskowitz", "text": "

Good, hard rain yesterday in Detroit and dropped the temp and washed the smoke out...

", "time": "2026-07-22T07:11:07.000Z"}, {"author": "John Gray", "text": "

Robert: Sorry about the smoke coming from my homeland... Glad it is cleaned out for you now.

", "time": "2026-07-22T07:13:47.000Z"}, {"author": "Bas Westerbaan", "text": "

Is there a WG asking for FrodoKEM?

", "time": "2026-07-22T07:13:58.000Z"}, {"author": "Yoav Nir", "text": "

ChaCha20 and Poly1305 were not new, but at least the \"glue\" that stuck them together was sort-of novel. Doesn't mean it's a thing CFRG needs to do again.

", "time": "2026-07-22T07:14:13.000Z"}, {"author": "Yoav Nir", "text": "

Bas Westerbaan said:

\n
\n

Is there a WG asking for FrodoKEM?

\n
\n

At least IPsecME. I think also TLS.

", "time": "2026-07-22T07:14:31.000Z"}, {"author": "Thom Wiggers", "text": "

There are un-adopted drafts in e.g. ipsecme referencing FrodoKEM

", "time": "2026-07-22T07:14:33.000Z"}, {"author": "Morgane Guerreau", "text": "

the FrodoKEM question was raised in ipsecme

", "time": "2026-07-22T07:14:33.000Z"}, {"author": "Yoav Nir", "text": "

Maybe IETF should spin up a \"crypto engineering\" working group to write documents like that.

", "time": "2026-07-22T07:15:53.000Z"}, {"author": "Yoav Nir", "text": "

IPsecME is definitely waiting for a not-behind-a-paywall specification.

", "time": "2026-07-22T07:16:47.000Z"}, {"author": "Bas Westerbaan", "text": "

For which reason? Just to check a policy box or technical reasons?

", "time": "2026-07-22T07:17:00.000Z"}, {"author": "Pascal Sch\u00e4fer", "text": "

Yoav Nir said:

\n
\n

Maybe IETF should spin up a \"crypto engineering\" working group to write documents like that.

\n
\n

I think this idea came up already before some IETFs ago.

", "time": "2026-07-22T07:17:06.000Z"}, {"author": "Yoav Nir", "text": "

Because the IETF won't publish documents with a normative reference to a non-public document.

", "time": "2026-07-22T07:17:46.000Z"}, {"author": "Yoav Nir", "text": "

Pascal Sch\u00e4fer said:

\n
\n

Yoav Nir said:

\n
\n

Maybe IETF should spin up a \"crypto engineering\" working group to write documents like that.

\n
\n

I think this idea came up already before some IETFs ago.

\n
\n

Review would be hard in such a working group. Who can check that the IETF \"FrodoKEM\" is the same as the ISO \"FrodoKEM\"? Also strange that this WG would not have change control in any meaningful way.

", "time": "2026-07-22T07:22:13.000Z"}, {"author": "Dmitry Belyavskiy", "text": "

Shouldn't usability considerations and comparison be in PQUIP , not in CFRG? I totally agree we need such a document

", "time": "2026-07-22T07:22:16.000Z"}, {"author": "Thom Wiggers", "text": "

I don't think benchmarks are as useful because they're extremely platform-specific and tend to be a moving target. Though at high-level you can make some general observations

", "time": "2026-07-22T07:23:06.000Z"}, {"author": "Dmitry Belyavskiy", "text": "

Sure, no benchmarks

", "time": "2026-07-22T07:23:21.000Z"}, {"author": "Thom Wiggers", "text": "

shameless plug: https://pqshield.github.io/nist-sigs-zoo/kems/

", "time": "2026-07-22T07:24:13.000Z"}, {"author": "Flo D", "text": "

+1 Scott

", "time": "2026-07-22T07:25:36.000Z"}, {"author": "Sophie Schmieg", "text": "

we can just use seeds for everything

", "time": "2026-07-22T07:26:07.000Z"}, {"author": "Tanja Lange", "text": "

Maybe it's easier with typing. I'm not suggesting to have a comparison document on security. I even said that I don't think that that is useful or possible. However, a CFRG document with comparison of the usability would be useful. I see @Thom Wiggers referencing the zoo. I'd also add https://bench.cr.yp.to/results-kem.html We have the numbers, but we're the (remaining) group for guidance on what crypto fits where.

", "time": "2026-07-22T07:28:11.000Z"}, {"author": "Flo D", "text": "

I agree that trying to iron out potential clashes between different WGs is one of the things PQUIP should have been doing. It hasn't really worked out that way so far, but it doesn't mean it couldn't do that in the future. It's also much less busy than CFRG.

", "time": "2026-07-22T07:28:19.000Z"}, {"author": "Thom Wiggers", "text": "

I should add a link to EBACS, my benchmarks are much less comprehensive (though maybe slightly more accessible)

", "time": "2026-07-22T07:29:49.000Z"}, {"author": "Yoav Nir", "text": "

So since CFRG doesn't want to adopt draft-longa-cfrg-frodokem, maybe it's time to go to DISPATCH to see what the IETF can do with it.

", "time": "2026-07-22T07:31:15.000Z"}, {"author": "Daniel Van Geest", "text": "

\"Who can check that the IETF \"FrodoKEM\" is the same as the ISO \"FrodoKEM\"? \" The individual draft authors are the ISO authors, I've asked them and they say it's the same modulo the ID has the 640 variants, and allows private key seed format (head-up LAMPS!). I also have access to the ISO document and my team has confirmed that the ISO and ID are the same.

", "time": "2026-07-22T07:31:34.000Z"}, {"author": "Flo D", "text": "

Surely Dispatch will just send it back to CFRG?

", "time": "2026-07-22T07:31:45.000Z"}, {"author": "Thom Wiggers", "text": "

but if CFRG then refuses it at least we clarify that there is no forum / a lack of a forum?

", "time": "2026-07-22T07:32:33.000Z"}, {"author": "Flo D", "text": "

Fair point

", "time": "2026-07-22T07:33:00.000Z"}, {"author": "Yoav Nir", "text": "

CFRG has already refused. It's the same people in the IRTF and IETF

", "time": "2026-07-22T07:33:11.000Z"}, {"author": "Kris Kwiatkowski", "text": "

What's a point of standardizing FrodoKEM in IETF if it is already done in ISO?

", "time": "2026-07-22T07:34:11.000Z"}, {"author": "Yoav Nir", "text": "

Daniel Van Geest said:

\n
\n

\"Who can check that the IETF \"FrodoKEM\" is the same as the ISO \"FrodoKEM\"? \" The individual draft authors are the ISO authors, I've asked them and they say it's the same modulo the ID has the 640 variants, and allows private key seed format (head-up LAMPS!). I also have access to the ISO document and my team has confirmed that the ISO and ID are the same.

\n
\n

Good for them. But someone other than the authors needs to review.

", "time": "2026-07-22T07:34:25.000Z"}, {"author": "Pascal Sch\u00e4fer", "text": "

Kris Kwiatkowski said:

\n
\n

What's a point of standardizing FrodoKEM in IETF if it is already done in ISO?

\n
\n

I think IETF drafts cannot use those references if someone wants to use FrodoKEM.

", "time": "2026-07-22T07:34:52.000Z"}, {"author": "Yoav Nir", "text": "

Kris Kwiatkowski said:

\n
\n

What's a point of standardizing FrodoKEM in IETF if it is already done in ISO?

\n
\n

Because we can't use an ISO document as a normative reference.

", "time": "2026-07-22T07:34:54.000Z"}, {"author": "Eliot Lear", "text": "

Yes you can

", "time": "2026-07-22T07:35:08.000Z"}, {"author": "Frank Denis", "text": "

There\u2019s also an implementation of Longfellow in zig

", "time": "2026-07-22T07:35:16.000Z"}, {"author": "Eliot Lear", "text": "

not that I'm recommending it

", "time": "2026-07-22T07:35:19.000Z"}, {"author": "Alexey Melnikov", "text": "

What Eliot said

", "time": "2026-07-22T07:35:21.000Z"}, {"author": "Yoav Nir", "text": "

OK, \"can't\" is too strong. But the IRSG and the community always push back strongly on normative references to documents behind paywalls.

", "time": "2026-07-22T07:36:19.000Z"}, {"author": "Eliot Lear", "text": "

But for independent submissions I would want to see SOME freely accessible specification.

", "time": "2026-07-22T07:36:35.000Z"}, {"author": "Eliot Lear", "text": "

The goal, after all, is widespread implementation

", "time": "2026-07-22T07:36:56.000Z"}, {"author": "Sophie Schmieg", "text": "

Kris Kwiatkowski said:

\n
\n

What's a point of standardizing FrodoKEM in IETF if it is already done in ISO?

\n
\n

so that it also exists as a standard by a well regarded standards organization?

", "time": "2026-07-22T07:37:08.000Z"}, {"author": "Kris Kwiatkowski", "text": "

so that's done

", "time": "2026-07-22T07:38:29.000Z"}, {"author": "Bas Westerbaan", "text": "

I think PQ ZKP is an important topic for the CFRG. I like the engineering that has been done for Long Fellow. I'm not sure it will be the ZKP scheme that is practical enough to deploy for many applications, but it's important to have something relatively simple worked out already just in case.

", "time": "2026-07-22T07:39:01.000Z"}, {"author": "Daniel Van Geest", "text": "

Yoav Nir said:

\n
\n

But someone other than the authors needs to review.

\n
\n

Daniel Van Geest said:

\n
\n

I also have access to the ISO document and my team has confirmed that the ISO and ID are the same.

\n
\n

If I need to do this more formally I can.

", "time": "2026-07-22T07:39:09.000Z"}, {"author": "Rob Hunter", "text": "

For several years particular versions of the Common Criteria standard has also been defined as an ISO standard. Mainly when a major number release was made. I wonder why there isn't an equivalent for FrodoKEM given the EU want adoption for its PQ migration strategy.

", "time": "2026-07-22T07:41:27.000Z"}, {"author": "Thom Wiggers", "text": "

The EU is not necessarily behind the push for FrodoKEM. That's just the French and Germans. Cryptography policy, in large part, is a member state issue.

", "time": "2026-07-22T07:42:30.000Z"}, {"author": "Thom Wiggers", "text": "

ML-KEM is also fine with all these countries even if they consider FrodoKEM to be more conservative/slightly preferred

", "time": "2026-07-22T07:43:23.000Z"}, {"author": "Bas Westerbaan", "text": "

I think IETF and IRTF should spend their time on solving international technical problems. If there is no technical need for another KEM, I think it's a waste of our time.

", "time": "2026-07-22T07:43:26.000Z"}, {"author": "Kris Kwiatkowski", "text": "

+1

", "time": "2026-07-22T07:43:51.000Z"}, {"author": "Thom Wiggers", "text": "

Identifying and removing blockers for PQC migration should be a priority. Technical issues are more fun to solve, policy issues are important too (but I don't think there are any policy issues truely blocking ML-KEM(-hybrids))

", "time": "2026-07-22T07:45:11.000Z"}, {"author": "Eliot Lear", "text": "

@Bas by \"technical need\" you mean diverse mathematical approach?

", "time": "2026-07-22T07:45:28.000Z"}, {"author": "Thom Wiggers", "text": "

(I don't think there's strong policy blockers anywhere at this moment--but don't want to close the door on them)

", "time": "2026-07-22T07:45:54.000Z"}, {"author": "Yoav Nir", "text": "

Daniel Van Geest said:

\n
\n

I also have access to the ISO document and my team has confirmed that the ISO and ID are the same.

\n

If I need to do this more formally I can.

\n

That would be useful.  I might mention your name if/when I raise it on the Dispatch list.\n

\n

\n
", "time": "2026-07-22T07:46:25.000Z"}, {"author": "Alexey Melnikov", "text": "

meetecho: can you move camera to the speaker?

", "time": "2026-07-22T07:49:15.000Z"}, {"author": "Bas Westerbaan", "text": "

Eliot Lear said:

\n
\n

@Bas by \"technical need\" you mean diverse mathematical approach?

\n
\n

That could be an argument. I have not seen that one being made yet properly. So far it's quoting national regulatory bodies, which I do not think is a good argument for an international organization.

", "time": "2026-07-22T07:49:43.000Z"}, {"author": "Thom Wiggers", "text": "

if someone does have that QC sitting next to them, please go to the mic

", "time": "2026-07-22T07:52:22.000Z"}, {"author": "Yoav Nir", "text": "

Bas Westerbaan said:

\n
\n

Eliot Lear said:

\n
\n

@Bas by \"technical need\" you mean diverse mathematical approach?

\n
\n

That could be an argument. I have not seen that one being made yet properly. So far it's quoting national regulatory bodies, which I do not think is a good argument for an international organization.

\n
\n

I'd go further. Having 5 options for something hinders adoption and interoperability. If I were a product manager, I'd adopt a wait-and-see approach until the market decides what is the algorithm to use. NIST did us all a further by requiring that we implement one of their selections by a certain date.

", "time": "2026-07-22T07:56:36.000Z"}, {"author": "Robert Moskowitz", "text": "

@ThomWiggers: Image of Schiller with that Sun machine sitting in his office @MIT running their Kerberos.

", "time": "2026-07-22T07:56:55.000Z"}, {"author": "Tanja Lange", "text": "

Bas Westerbaan said:

\n
\n

Eliot Lear said:

\n
\n

@Bas by \"technical need\" you mean diverse mathematical approach?

\n
\n

That could be an argument. I have not seen that one being made yet properly. So far it's quoting national regulatory bodies, which I do not think is a good argument for an international organization.

\n
\n

NIST made it in going for a second KEM and the security considerations documents show different underlying security assumptions.

\n

IMO, FrodoKEM is more different in security assumption from ML-KEM than HQC (both have a quasi-cyclic structure). Clasisic McEliece is yet more different.

", "time": "2026-07-22T07:57:26.000Z"}, {"author": "Thom Wiggers", "text": "

Sorry @Robert Moskowitz, I think I'm too young for that reference :sweat_smile: :baby:

", "time": "2026-07-22T07:59:05.000Z"}, {"author": "Robert Moskowitz", "text": "

Jeff often had fun stories around that system...

", "time": "2026-07-22T08:01:15.000Z"}, {"author": "Dan Harkins", "text": "

the comment was that since kemeleon already splits rho from the vector of coefficients then the BUA-sKEM is not necessary. Just do ML-KEM.KeyGen and then kemeleon.

", "time": "2026-07-22T08:02:48.000Z"}, {"author": "Dan Harkins", "text": "

in fact, since this draft explicitly splits off rho then it is not really compatible with kemeleon as currently written.

", "time": "2026-07-22T08:03:25.000Z"}, {"author": "Sophie Schmieg", "text": "

Dan Harkins said:

\n
\n

the comment was that since kemeleon already splits rho from the vector of coefficients then the BUA-sKEM is not necessary. Just do ML-KEM.KeyGen and then kemeleon.

\n
\n

this feels like it should be discussed in papers? Or at least repeated on the mailing list

", "time": "2026-07-22T08:03:46.000Z"}, {"author": "Dan Harkins", "text": "

Yes, it should be discussed on the list.

", "time": "2026-07-22T08:05:35.000Z"}, {"author": "Rich Salz", "text": "

\"To be fair\" comment -- wish more folks did that kind of thing.

", "time": "2026-07-22T08:07:16.000Z"}, {"author": "Robert Moskowitz", "text": "

Only a few bytes smaller. Then won't help me. Sigh.

", "time": "2026-07-22T08:07:28.000Z"}, {"author": "John Preu\u00df Mattsson", "text": "

The IPSECME FrodoKEM draft-ietf-ipsecme-hybrid-kem-ikev2-frodo is adopted and WGLC was discussed.

\n

While nothing forbids the IETF to normatively reference paywalled cryptography, we really should not.

", "time": "2026-07-22T08:07:51.000Z"}, {"author": "Thom Wiggers", "text": "

I think some SUF-CMA scheme would be good to have in the toolbox for places where signatures are used more arbitarily, e.g. the ways that SSH keys are (ab)used right now...

", "time": "2026-07-22T08:22:58.000Z"}, {"author": "Thom Wiggers", "text": "

But it should probably be done quickly if it's worth doing, being available too late will make the point moot

", "time": "2026-07-22T08:23:32.000Z"}, {"author": "John Preu\u00df Mattsson", "text": "

I think an important property missing is the number of hash algorithm primitives in the composite.

\n

Also I think they are all composites. That term should not be reserved for the 18 LAMPS algorithms

", "time": "2026-07-22T08:24:19.000Z"}, {"author": "Thom Wiggers", "text": "

we should align with the PQUIP terminology draft

", "time": "2026-07-22T08:25:06.000Z"}, {"author": "Jan Klau\u00dfner", "text": "

+1

", "time": "2026-07-22T08:25:15.000Z"}, {"author": "Thom Wiggers", "text": "

s/draft/rfc/ now :)

", "time": "2026-07-22T08:25:26.000Z"}, {"author": "Thom Wiggers", "text": "

please eat microphone

", "time": "2026-07-22T08:25:46.000Z"}, {"author": "Thom Wiggers", "text": "

(good enough now)

", "time": "2026-07-22T08:26:33.000Z"}, {"author": "Britta Hale", "text": "

There are multiple security nuances and hidden security failure modes for hybrid signatures that are not issues for hybrid KEMs. The presentation touched on two of those, but serious discussion on all of them should occur before moving out on choice or even a decision to pursue such a draft at all.

", "time": "2026-07-22T08:27:54.000Z"}, {"author": "Morgane Guerreau", "text": "

Thom Wiggers said:

\n
\n

I think some SUF-CMA scheme would be good to have in the toolbox for places where signatures are used more arbitarily, e.g. the ways that SSH keys are (ab)used right now...

\n
\n

would it make sense to have one of those SUF-CMA schemes standardized directly into the SSH WG (or any WG where SUF-CMA has a strong case) if CFRG is not interested by the topic?

", "time": "2026-07-22T08:28:39.000Z"}, {"author": "Thom Wiggers", "text": "

maybe? That's up to sshm (and there may be charter issues because the outside-of-ssh uses of keys are technically out of scope of that working group...)

", "time": "2026-07-22T08:29:35.000Z"}, {"author": "Bas Westerbaan", "text": "

Wait, why does SSH need SUF-CMA?

", "time": "2026-07-22T08:29:54.000Z"}, {"author": "Thom Wiggers", "text": "

SSH itself doesn't, but SSH public keys are used for e.g. code signing and in other places

", "time": "2026-07-22T08:30:18.000Z"}, {"author": "Peter Campbell", "text": "

Some of the SSH security proofs require SUF-CMA.

", "time": "2026-07-22T08:30:31.000Z"}, {"author": "Peter Campbell", "text": "

(or assume)

", "time": "2026-07-22T08:30:49.000Z"}, {"author": "Thom Wiggers", "text": "

probably mostly a proof artifact

", "time": "2026-07-22T08:30:57.000Z"}, {"author": "Peter Campbell", "text": "

Probably.

", "time": "2026-07-22T08:31:08.000Z"}, {"author": "Thom Wiggers", "text": "

https://eprint.iacr.org/2025/684 is EUF-CMA in any case

", "time": "2026-07-22T08:31:44.000Z"}, {"author": "Thom Wiggers", "text": "

But I can get the sentiment of \"we're sending these keys into the world, better make them as robust as possible.\" (but also preferably sooner rather than later)

", "time": "2026-07-22T08:33:01.000Z"}, {"author": "Kris Kwiatkowski", "text": "

Britta Hale said:

\n
\n

There are multiple security nuances and hidden security failure modes for hybrid signatures that are not issues for hybrid KEMs. The presentation touched on two of those, but serious discussion on all of them should occur before moving out on choice or even a decision to pursue such a draft at all.

\n
\n

+1. On top of the security nuances, we already have a bloat of composite constructions (18 in LAMPS alone, plus other proposals). Before adding yet another, use cases and required properties should be stated on the list, so we can check whether existing schemes cover them.

", "time": "2026-07-22T08:33:18.000Z"}, {"author": "Peter Campbell", "text": "

@Thom: Hmm. That's unclear. 2025/684 is based on 2013/813 which does technically assume SUF-CMA.

", "time": "2026-07-22T08:36:30.000Z"}, {"author": "Peter Campbell", "text": "

The ACM CCS 2014 version used the term EUF-CMA, but the definition was actually SUF-CMA.

", "time": "2026-07-22T08:37:50.000Z"}, {"author": "Peter Campbell", "text": "

It was corrected in the ePrint version.

", "time": "2026-07-22T08:38:04.000Z"}, {"author": "Bas Westerbaan", "text": "

The game 4 part in the proof of Lemma 4.1 is EUF-CMA\u2014not SUF-CMA

", "time": "2026-07-22T08:40:39.000Z"}, {"author": "Sophie Schmieg", "text": "

But the signatures used with ssh today aren't suf afaik

", "time": "2026-07-22T08:43:00.000Z"}, {"author": "Sophie Schmieg", "text": "

In particular ECDSA allows you to swap the sign

", "time": "2026-07-22T08:43:16.000Z"}, {"author": "Thom Wiggers", "text": "

@Bas Westerbaan actually I think they may also have a wrong definition

", "time": "2026-07-22T08:44:41.000Z"}, {"author": "Peter Campbell", "text": "

This is a restatement of the Game 3 in the proof of Lemma 1 from 2013/813, which does assume SUF-CMA.

", "time": "2026-07-22T08:44:48.000Z"}, {"author": "Thom Wiggers", "text": "

Game 4 aborts if it receives a signature which was never output of a session with a matching session identifier. If signatures are malleable (e.g. append a byte), this is trivial to trigger.

", "time": "2026-07-22T08:45:28.000Z"}, {"author": "John Gray", "text": "

In regards to the bloat of composite signatures... that was an artifact of so many voices in LAMPS asking for specific combinations. Maybe we should have been more forceful in saying No. Sorry... The construction in LAMPS composite signatures is essentially fixed, the algorithms themselves are like parameters fixed by the OID. We did try numerous times to prune the list, so on a positive note, it is smaller than it could have been. :) I think at one point their had been 32 of them!

", "time": "2026-07-22T08:46:56.000Z"}, {"author": "Thom Wiggers", "text": "

Now, I think this may simply be phrased incorrectly. SUF-CMA is typically necessary due to some partnering definition shenanigans but seems to not be the case here. So I think that the game can be rephrased that Game 4 aborts if it accepts without a partner. this is what the second paragraph in Game 4 describes anyway.

", "time": "2026-07-22T08:47:59.000Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Sophie Schmieg wrote:

\n
\n

But the signatures used with ssh today aren't suf afaik
\nIn particular ECDSA allows you to swap the sign

\n
\n

I think standardizing ECDSA with a trivial malleability vulnerability was a mistake.

\n

SSH widely use EdDSA. The standardized versions of EdDSA are not malleable.

", "time": "2026-07-22T08:48:50.000Z"}, {"author": "Kris Kwiatkowski", "text": "

John Gray said:

\n
\n

In regards to the bloat of composite signatures... that was an artifact of so many voices in LAMPS asking for specific combinations. Maybe we should have been more forceful in saying No. Sorry... The construction in LAMPS composite signatures is essentially fixed, the algorithms themselves are like parameters fixed by the OID. We did try numerous times to prune the list, so on a positive note, it is smaller than it could have been. :) I think at one point their had been 32 of them!

\n
\n

I think we must begin with the real use cases that genuinely require hybrid signatures. Aiming to satisfy all conceivable ones will inevitably lead to an explosion in the number of algorithms.

", "time": "2026-07-22T08:52:42.000Z"}, {"author": "Bas Westerbaan", "text": "

Not sure how much it's used in practice, but the PGP signature variants of SSH seem malleable because of the unhashed signature subpackets

", "time": "2026-07-22T08:55:54.000Z"}, {"author": "Sophie Schmieg", "text": "

More practically, I'd rather see the paper revisited on whether SUF is actually required, before open the can of worms that's SUF hybrid signatures

", "time": "2026-07-22T08:57:07.000Z"}, {"author": "Thom Wiggers", "text": "

for SSH itself I strongly doubt it cares about malleability

", "time": "2026-07-22T08:57:36.000Z"}, {"author": "Thom Wiggers", "text": "

(of signatures, i.e., EUF-CMA is enough)

", "time": "2026-07-22T08:57:52.000Z"}, {"author": "Sophie Schmieg", "text": "

+1, I would be very surprised if SUF was needed

", "time": "2026-07-22T08:58:17.000Z"}, {"author": "Thom Wiggers", "text": "

I sent a message to Benjamin Dowling (who I think is also around in Vienna)

", "time": "2026-07-22T08:58:45.000Z"}, {"author": "Renzo Navas", "text": "

thank you!

", "time": "2026-07-22T08:58:51.000Z"}, {"author": "Rich Salz", "text": "

Nice work from the chairs for clarifying and steering discussion

", "time": "2026-07-22T08:59:03.000Z"}]