[{"author": "Jonathan Hoyland", "text": "

Hi folks :wave:

", "time": "2026-07-21T14:30:10.000Z"}, {"author": "Robert Moskowitz", "text": "

checking out the echo???

", "time": "2026-07-21T14:30:13.000Z"}, {"author": "Pascal Sch\u00e4fer", "text": "

Hi :wave:

", "time": "2026-07-21T14:33:37.000Z"}, {"author": "Rob Hunter", "text": "

camera on speaker?

", "time": "2026-07-21T14:34:43.000Z"}, {"author": "Robert Moskowitz", "text": "

Why not layer 2? Or not IETF's playground?

", "time": "2026-07-21T14:35:29.000Z"}, {"author": "Ted Hardie", "text": "

@meetecho can you check the camera direction in CURRENT?

", "time": "2026-07-21T14:35:44.000Z"}, {"author": "Lorenzo Miniero", "text": "

@Ted Hardie we're showing Russ

", "time": "2026-07-21T14:36:04.000Z"}, {"author": "Ted Hardie", "text": "

Thanks for the confirmation @meetecho

", "time": "2026-07-21T14:36:29.000Z"}, {"author": "Lorenzo Miniero", "text": "

Apologies, I forgot to ack Rob when he poked us :pray:

", "time": "2026-07-21T14:36:58.000Z"}, {"author": "Rob Hunter", "text": "

many thanks! Just a gentle nudge, never a poke!

", "time": "2026-07-21T14:38:48.000Z"}, {"author": "James Howe", "text": "

Hello everyone! Does anyone know/remember if votes can be done in zulip or do you need to do this via the full client?

", "time": "2026-07-21T14:41:19.000Z"}, {"author": "Eric Rescorla", "text": "

you need the full client

", "time": "2026-07-21T14:41:24.000Z"}, {"author": "Eric Rescorla", "text": "

Or rather the client

", "time": "2026-07-21T14:41:32.000Z"}, {"author": "Paul Wouters", "text": "

or the lite client

", "time": "2026-07-21T14:41:36.000Z"}, {"author": "James Howe", "text": "

Is there a trick to get the lite client?

", "time": "2026-07-21T14:41:49.000Z"}, {"author": "Daniel Gillmor", "text": "

\"it's not voting\"

", "time": "2026-07-21T14:42:01.000Z"}, {"author": "Thom Wiggers", "text": "

@james you should be logging into meetecho through the links in the room or through the IETF agenda

", "time": "2026-07-21T14:42:22.000Z"}, {"author": "Paul Wouters", "text": "

linked in the ietf 126 agenda for each meeting

", "time": "2026-07-21T14:42:27.000Z"}, {"author": "Thom Wiggers", "text": "

it's the buttons with the \"phone\" icon

", "time": "2026-07-21T14:42:30.000Z"}, {"author": "Ted Hardie", "text": "

@James from the agenda, click the icon that looks like a phone

", "time": "2026-07-21T14:42:32.000Z"}, {"author": "Lorenzo Miniero", "text": "

@James Howe in the agenda, the lite client (onsite tool) is the one with the green phone icon

", "time": "2026-07-21T14:42:39.000Z"}, {"author": "James Howe", "text": "

Ah that's what I did, maybe I am using the lite client then. Thanks everyone

", "time": "2026-07-21T14:43:57.000Z"}, {"author": "Jonathan Lennox", "text": "

If you're seeing the slides, you're on the lite client. If you're on the chat you're probalby on the lite client unless you're using something explicitly branded Zulip.

", "time": "2026-07-21T14:45:01.000Z"}, {"author": "Eric Rescorla", "text": "

The question I am trying to understand is as follows. I agree that MLS allows you to do unidirectional key updates. However, if you do a key update followed by actually using the new key and the update is lost, then obviously the recipient cannot decrypt the traffic. So how much survivability do you need in the case of that and is that a requirement of this work?

", "time": "2026-07-21T14:45:55.000Z"}, {"author": "Hyrum Mills", "text": "

difference in the url is that the full client is https://meetecho.ietf.org/client/?group=current and the lite client is https://meetecho.ietf.org/lite/?group=current

", "time": "2026-07-21T14:46:19.000Z"}, {"author": "Jonathan Hoyland", "text": "

Eric Rescorla said:

\n
\n

The question I am trying to understand is as follows. I agree that MLS allows you to do unidirectional key updates. However, if you do a key update followed by actually using the new key and the update is lost, then obviously the recipient cannot decrypt the traffic. So how much survivability do you need in the case of that and is that a requirement of this work?

\n
\n

It's hard to imagine a recovery mechanism that didn't also create a vulnerability.

", "time": "2026-07-21T14:47:19.000Z"}, {"author": "Eric Rescorla", "text": "

In TLS, this is handled by having reliable and in-order delivery of the data and in DTLS/QUIC by requiring ACKs of the update packets before the new key is used

", "time": "2026-07-21T14:47:19.000Z"}, {"author": "Eric Rescorla", "text": "

Jonathan Hoyland said:

\n
\n

Eric Rescorla said:

\n
\n

The question I am trying to understand is as follows. I agree that MLS allows you to do unidirectional key updates. However, if you do a key update followed by actually using the new key and the update is lost, then obviously the recipient cannot decrypt the traffic. So how much survivability do you need in the case of that and is that a requirement of this work?

\n
\n

It's hard to imagine a recovery mechanism that didn't also create a vulnerability.

\n
\n

Well hence my question :)

", "time": "2026-07-21T14:47:36.000Z"}, {"author": "Eric Rescorla", "text": "

I'm not sure I buy this claim. We usually assume the attacker controls the entire transmission channel

", "time": "2026-07-21T14:48:14.000Z"}, {"author": "Ted Hardie", "text": "

If the attacker has Drone1, why does the attacker not simply use D1 to monitor the traffic?

", "time": "2026-07-21T14:48:18.000Z"}, {"author": "Robert Moskowitz", "text": "

May have to inject traffic to get telemetry from other members.

", "time": "2026-07-21T14:49:01.000Z"}, {"author": "Carlos Melchor", "text": "

@eric I guess the presentation is about the settings in which reliability is less important than privacy (you accept some greenpeace data to be lost, but don't want the drone to be detected/destroyed).

", "time": "2026-07-21T14:49:03.000Z"}, {"author": "Jonathan Lennox", "text": "

I like Ga\u00ebtan's background.

", "time": "2026-07-21T14:50:29.000Z"}, {"author": "Jonathan Hoyland", "text": "

Censors or Sensors?

", "time": "2026-07-21T14:50:31.000Z"}, {"author": "Daniel Gillmor", "text": "

censor-evading sensors

", "time": "2026-07-21T14:50:54.000Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Maybe they want the new updated TLS record layer defined in
\nhttps://datatracker.ietf.org/doc/draft-ietf-tls-super-jumbo-record-limit/

", "time": "2026-07-21T14:50:56.000Z"}, {"author": "Robert Moskowitz", "text": "

Sensors, as I see it.

", "time": "2026-07-21T14:50:59.000Z"}, {"author": "Eric Rescorla", "text": "

@John Preu\u00df Mattsson would interested in your thoughts on my question above about update loss

", "time": "2026-07-21T14:51:17.000Z"}, {"author": "Renzo Navas", "text": "

+1 background (\"In space no one can hear you scream\")

", "time": "2026-07-21T14:51:19.000Z"}, {"author": "James Howe", "text": "

Sensors indeed

", "time": "2026-07-21T14:51:27.000Z"}, {"author": "Eric Rescorla", "text": "

Why aren't they using QUIC?

", "time": "2026-07-21T14:51:32.000Z"}, {"author": "Thom Wiggers", "text": "

^

", "time": "2026-07-21T14:51:37.000Z"}, {"author": "Eric Rescorla", "text": "

Which is designed to resist this kind of networking issue

", "time": "2026-07-21T14:51:59.000Z"}, {"author": "Eric Rescorla", "text": "

This misunderstands the situation with 0-RTT

", "time": "2026-07-21T14:52:27.000Z"}, {"author": "Thom Wiggers", "text": "

MLS does not solve resumption per se

", "time": "2026-07-21T14:52:53.000Z"}, {"author": "Daniel Gillmor", "text": "

it's not clear why you couldn't handle anti-replay at the application layer; do the sensors not serialize their data?

", "time": "2026-07-21T14:52:59.000Z"}, {"author": "Eric Rescorla", "text": "

yes.

", "time": "2026-07-21T14:53:07.000Z"}, {"author": "Daniel Gillmor", "text": "

@ekr, that's not going to be seen as a \"clarifying question\"

", "time": "2026-07-21T14:53:30.000Z"}, {"author": "Jonathan Hoyland", "text": "

Also, if a sensor has a bad connection, then retransmitting lost data might be a good thing.

", "time": "2026-07-21T14:53:58.000Z"}, {"author": "Yaroslav Rosomakho", "text": "

I think it really depends on what sensor is doing. In some cases you really don't want retransmit old data to ensure you have enough bandwidth to transmit fresh data

", "time": "2026-07-21T14:54:38.000Z"}, {"author": "Carlos Melchor", "text": "

Note that the \"formal verification\" means here a well-done academic proof, not a proof using formal-methods.

", "time": "2026-07-21T14:54:43.000Z"}, {"author": "Jonathan Hoyland", "text": "

(With ratcheting that data is guaranteed to be lost)

", "time": "2026-07-21T14:54:49.000Z"}, {"author": "Robert Moskowitz", "text": "

Daniel, you should see the serialization mess I have to deal with in ADS-B which has ground retransmitters for greater coverage.

", "time": "2026-07-21T14:54:52.000Z"}, {"author": "Jonathan Hoyland", "text": "

Carlos Melchor said:

\n
\n

Note that the \"formal verification\" means here a well-done academic proof, not a proof using formal-methods.

\n
\n

I have no idea what the difference between these is supposed to be? Are you suggesting the proof is a pen and paper proof?

", "time": "2026-07-21T14:55:29.000Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Hi @Eric Rescorla

\n

My presentation was mostly about unidirectional communication, even if I did mentioned unidirectional key management. I think people that have deployed MLS in e.g., messaging systems is better suited at answering your question of a lost key update in a bad quality network.

", "time": "2026-07-21T14:57:33.000Z"}, {"author": "Jonathan Hoyland", "text": "

What does well-analysed mean in this context, the binding between MLS and TLS is very non-trivial

", "time": "2026-07-21T14:57:42.000Z"}, {"author": "Thom Wiggers", "text": "

@jonathan not sure if I agree, you can tie the proof of the TLS record layer to any proof of a secure key exchange

", "time": "2026-07-21T14:58:27.000Z"}, {"author": "Daniel Gillmor", "text": "

if you're willing to be flexible, pretty much any \"certificate-shaped\" thing can be put into an X.509 structure.

", "time": "2026-07-21T14:58:43.000Z"}, {"author": "Thom Wiggers", "text": "

there is a generic result that allows combining proofs

", "time": "2026-07-21T14:58:56.000Z"}, {"author": "Daniel Gillmor", "text": "

especially if you control both sides of the connection

", "time": "2026-07-21T14:59:01.000Z"}, {"author": "Eric Rescorla", "text": "

To elaborate about the situation with TLS 0-RTT a little bit, the issue with 0-RTT is basically twofold (1) You need to worry about two servers retaining state (2) you need to be able to handle the connection state being totally lost. And the way MLS handles this is by having hard synchronous state so that it just assumes neither of these can happen

", "time": "2026-07-21T14:59:21.000Z"}, {"author": "Benjamin Dowling", "text": "

@Thom I think yes and no. you can generically combine KEX proofs with symmetric-key primitives, but it requires a compositional framework, right?

", "time": "2026-07-21T14:59:41.000Z"}, {"author": "Eric Rescorla", "text": "

I'm a little puzzled by an existing WG draft still being in flux as an argument for spinning up a whole new WG

", "time": "2026-07-21T15:00:09.000Z"}, {"author": "Daniel Gillmor", "text": "

Yah, you can also achieve 0-rtt replay protection by just having a single server endpoint. the problem comes when you have two machines answering for the same TLS endpoint.

", "time": "2026-07-21T15:00:35.000Z"}, {"author": "Carlos Melchor", "text": "

@jonathan making that fully detailed and following the state of the art proofs is the objective of the paper @gaetan spoke about.

", "time": "2026-07-21T15:00:48.000Z"}, {"author": "Thom Wiggers", "text": "

@Ben: yeah I'm thinking of Chris Brzuska's work. It seemed that the symmetric-key part could be pretty arbitrary if you can define partnering

", "time": "2026-07-21T15:01:04.000Z"}, {"author": "Yaroslav Rosomakho", "text": "

Last I checked it was an adopted draft progressing more or less as expected through the WG process. I would not call that \"in flux\"

", "time": "2026-07-21T15:01:05.000Z"}, {"author": "Eric Rescorla", "text": "

Daniel Gillmor said:

\n
\n

Yah, you can also achieve 0-rtt replay protection by just having a single server endpoint. the problem comes when you have two machines answering for the same TLS endpoint.

\n
\n

Exactly. But the basic assumption here is that there is only one endpoint.

", "time": "2026-07-21T15:01:08.000Z"}, {"author": "Eric Rescorla", "text": "

Yaroslav Rosomakho said:

\n
\n

Last I checked it was an adopted draft progressing more or less as expected through the WG process. I would not call that \"in flux\"

\n
\n

Fair enough. I wasn't trying to criticize.

", "time": "2026-07-21T15:01:25.000Z"}, {"author": "Ted Hardie", "text": "

Is that true for the DNS swarm case as well? That looks to be a multiparty use case, no?

", "time": "2026-07-21T15:01:40.000Z"}, {"author": "Jonathan Hoyland", "text": "

You might be able to use the keys of one in the other, but that doesn't, for example, prove that both parties agree on how the keys were derived. Maybe one party thinks it's just an OOB key but the other thinks it's from MLS

", "time": "2026-07-21T15:01:47.000Z"}, {"author": "Ted Hardie", "text": "

(Drone Swarm, sorry for my typo!)

", "time": "2026-07-21T15:01:57.000Z"}, {"author": "Daniel Gillmor", "text": "

I like \"DNS Swarm\"

", "time": "2026-07-21T15:02:06.000Z"}, {"author": "Eric Rescorla", "text": "

Ted Hardie said:

\n
\n

Is that true for the DNS swarm case as well? That looks to be a multiparty use case, no?

\n
\n

Too complicated for here, but basically this is about 0-RTT

", "time": "2026-07-21T15:02:18.000Z"}, {"author": "Ted Hardie", "text": "

It's late in the day, I'm lucky my typo was SFW

", "time": "2026-07-21T15:02:22.000Z"}, {"author": "Rich Salz", "text": "

It was auto-correct...

", "time": "2026-07-21T15:02:43.000Z"}, {"author": "Robert Moskowitz", "text": "

@Tom Hardie, Drone Swarm at times is multi-party.

", "time": "2026-07-21T15:02:49.000Z"}, {"author": "Daniel Gillmor", "text": "

TLS does have extensible credentials

", "time": "2026-07-21T15:02:51.000Z"}, {"author": "Thom Wiggers", "text": "

@Jonathan: right, that's a fair point since the TLS record layer doesn't live in a vacuum

", "time": "2026-07-21T15:02:52.000Z"}, {"author": "Jonathan Hoyland", "text": "

Ted Hardie said:

\n
\n

Is that true for the DNS swarm case as well? That looks to be a multiparty use case, no?

\n
\n

This is the scary part (and thus my joke about censors)

", "time": "2026-07-21T15:03:09.000Z"}, {"author": "Ted Hardie", "text": "

@ekr So in the charter, this item \" Adopt two-party protocol specification\" is only for a 0-RTT use case?

", "time": "2026-07-21T15:03:36.000Z"}, {"author": "Martin Thomson", "text": "

A proof of the system is not much use if the system is not worth proving.

", "time": "2026-07-21T15:04:04.000Z"}, {"author": "Jonathan Hoyland", "text": "

Thom Wiggers said:

\n
\n

@Jonathan: right, that's a fair point since the TLS record layer doesn't live in a vacuum

\n
\n

I want to know what kind of proof it is, given that we're told it's not using formal methods

", "time": "2026-07-21T15:04:09.000Z"}, {"author": "Britta Hale", "text": "

Jonathan Hoyland said:

\n
\n

You might be able to use the keys of one in the other, but that doesn't, for example, prove that both parties agree on how the keys were derived. Maybe one party thinks it's just an OOB key but the other thinks it's from MLS

\n
\n

That is mixing handshake security model (which establishes binding) and channel security (which assumes it). It is no different from the TLS analyses that separate the two

", "time": "2026-07-21T15:04:17.000Z"}, {"author": "John Preu\u00df Mattsson", "text": "

I would also not calling EKU draft being in flux, but it does not give you reauthentication without changes to the application layer. It can also not be used when the parties or not online simultanously.

", "time": "2026-07-21T15:04:38.000Z"}, {"author": "Jonathan Hoyland", "text": "

Britta Hale said:

\n
\n

Jonathan Hoyland said:

\n
\n

You might be able to use the keys of one in the other, but that doesn't, for example, prove that both parties agree on how the keys were derived. Maybe one party thinks it's just an OOB key but the other thinks it's from MLS

\n
\n

That is mixing handshake security model (which establishes binding) and channel security (which assumes it). It is no different from the TLS analyses that separate the two

\n
\n

An analysis that skips that binding is indeed leaving a hole ...

", "time": "2026-07-21T15:04:52.000Z"}, {"author": "Eric Rescorla", "text": "

So I could talk a bit more about the drone swarm case, but the TL;DR is that the way you get into replay problems with TLS 1.3 0-RTT is that you have to deal with ambiguity about the state of the counterparty. MLS deals with this by just saying that there is a fixed state and not recover from it..

", "time": "2026-07-21T15:04:52.000Z"}, {"author": "Robert Moskowitz", "text": "

the \"Drone Show\" effort in ASTM F38 is supposedly single party. At least for now! Oh, and some need more than 1,000 nodes as was a limit mentioned in MLS session earlier today.

", "time": "2026-07-21T15:05:10.000Z"}, {"author": "Martin Thomson", "text": "

Eric Rescorla said:

\n
\n

So I could talk a bit more about the drone swarm case, but the TL;DR is that the way you get into replay problems with TLS 1.3 0-RTT is that you have to deal with ambiguity about the state of the counterparty. MLS deals with this by just saying that there is a fixed state and not recover from it..

\n
\n

That's just a different design choice. I'm not sure that either one is better. I know that TLS was designed with the web in mind. I don't know if fixed assumptions about the state of a peer is compatible with the way that the web works.

", "time": "2026-07-21T15:05:59.000Z"}, {"author": "Eric Rescorla", "text": "

Martin Thomson said:

\n
\n

Eric Rescorla said:

\n
\n

So I could talk a bit more about the drone swarm case, but the TL;DR is that the way you get into replay problems with TLS 1.3 0-RTT is that you have to deal with ambiguity about the state of the counterparty. MLS deals with this by just saying that there is a fixed state and not recover from it..

\n
\n

That's just a different design choice. I'm not sure that either one is better. I know that TLS was designed with the web in mind. I don't know if fixed assumptions about the state of a peer is compatible with the way that the web works.

\n
\n

Agreed. I was mostly trying to say if you are willing to accept this reuqirement, thent he world si easier

", "time": "2026-07-21T15:06:43.000Z"}, {"author": "Daniel Gillmor", "text": "

thank you stephen! I had the same question

", "time": "2026-07-21T15:07:39.000Z"}, {"author": "Eric Rescorla", "text": "

I'm a little confused about the scoping here. Is it about multi-user or two party?

", "time": "2026-07-21T15:08:18.000Z"}, {"author": "Robert Moskowitz", "text": "

I wondered about that too. With the Drone Swarm example.

", "time": "2026-07-21T15:08:40.000Z"}, {"author": "Daniel Gillmor", "text": "

https://datatracker.ietf.org/doc/bofreq-housley-continuous-updating-and-ratcheting-for-rekeying-encrypted-network-transport/ says \"two-party\"

", "time": "2026-07-21T15:08:41.000Z"}, {"author": "Daniel Gillmor", "text": "

how many drones are needed for it to make a swarm?

", "time": "2026-07-21T15:08:52.000Z"}, {"author": "Robert Moskowitz", "text": "

Then how did swarms swarm in?

", "time": "2026-07-21T15:09:10.000Z"}, {"author": "Jonathan Lennox", "text": "

Sorites paradox

", "time": "2026-07-21T15:09:25.000Z"}, {"author": "Robert Moskowitz", "text": "

3 drones starts a swarm.

", "time": "2026-07-21T15:09:31.000Z"}, {"author": "Robert Moskowitz", "text": "

Yea Ted!

", "time": "2026-07-21T15:09:53.000Z"}, {"author": "Eric Rescorla", "text": "

I see the party says \"two party\"

", "time": "2026-07-21T15:10:01.000Z"}, {"author": "Benjamin Dowling", "text": "

@Jonathan re:binding I think that it would be straightforward to prove partnering requirements ala the Brzuska et al compositional framework for the MLS handshake, unless I've misunderstood your point

", "time": "2026-07-21T15:10:02.000Z"}, {"author": "Jonathan Hoyland", "text": "

I think it could be proven, but saying it's well-analysed without having specified any binding seems ... questionable.

", "time": "2026-07-21T15:11:12.000Z"}, {"author": "Martin Thomson", "text": "

Can someone articulate the problem statement concisely for someone who might have missed the introductory material? The slides aren't helping me understand.

", "time": "2026-07-21T15:11:25.000Z"}, {"author": "Carlos Melchor", "text": "

@jonathan it is a classical cryptographic proof by \"not formal method\" I mean the work is not about an machine-assisted automated proof, but a proof by reduction written by cryptographers.

", "time": "2026-07-21T15:11:33.000Z"}, {"author": "Ted Hardie", "text": "

+1 to EKR

", "time": "2026-07-21T15:12:10.000Z"}, {"author": "Robert Moskowitz", "text": "", "time": "2026-07-21T15:12:30.000Z"}, {"author": "Jonathan Hoyland", "text": "

@Carlos Melchor I'll choose not to take offence at the suggestion that people that use machine-checked proofs aren't cryptographers. Has the reduction been peer-reviewed somewhere?

", "time": "2026-07-21T15:12:48.000Z"}, {"author": "Robert Moskowitz", "text": "

Hey! I typed a +, but something changed it to that dot....

", "time": "2026-07-21T15:13:10.000Z"}, {"author": "Daniel Gillmor", "text": "

it's a markdown bullet

", "time": "2026-07-21T15:13:22.000Z"}, {"author": "Thom Wiggers", "text": "

probably actually a minus symbol

", "time": "2026-07-21T15:13:24.000Z"}, {"author": "Daniel Gillmor", "text": "

or a *

", "time": "2026-07-21T15:13:31.000Z"}, {"author": "Daniel Gillmor", "text": "", "time": "2026-07-21T15:13:36.000Z"}, {"author": "Thom Wiggers", "text": "", "time": "2026-07-21T15:13:42.000Z"}, {"author": "Thom Wiggers", "text": "

plus/minus are often near/on the same key

", "time": "2026-07-21T15:13:50.000Z"}, {"author": "Daniel Gillmor", "text": "

that's why you should never multiply ekr by 2\u00b2\u2075\u2076

", "time": "2026-07-21T15:13:59.000Z"}, {"author": "Martin Thomson", "text": "

I thought that was like \"2<sup>256</sup> to Slitherin\", which seems fine

", "time": "2026-07-21T15:14:30.000Z"}, {"author": "Robert Moskowitz", "text": "

There is a big swarm, swarming behind us.

", "time": "2026-07-21T15:14:32.000Z"}, {"author": "Eric Rescorla", "text": "

Daniel Gillmor said:

\n
\n

that's why you should never multiply ekr by 2\u00b2\u2075\u2076

\n
\n

I was hoping someone would multiply me by 2^521

", "time": "2026-07-21T15:14:34.000Z"}, {"author": "Thom Wiggers", "text": "

I don't think the IETF is ready for that speed of talking

", "time": "2026-07-21T15:14:52.000Z"}, {"author": "Ted Hardie", "text": "

May I ask why the BoF was given this hard scope, rather than having that discussion emerge from the BoF?

", "time": "2026-07-21T15:15:16.000Z"}, {"author": "Stephen Farrell", "text": "

I'm thinking I'd like a 'no undetectable ghost group members' sentence added to the charter

", "time": "2026-07-21T15:15:48.000Z"}, {"author": "Carlos Melchor", "text": "

@jonathan ahah one of the authors is a specialist of machine-assisted proofs, but this proof is not. The paper is being finalised and will be published on a peer reviewed venue.

", "time": "2026-07-21T15:16:32.000Z"}, {"author": "Robert Moskowitz", "text": "

I came here because swarm use case included....

", "time": "2026-07-21T15:16:42.000Z"}, {"author": "Rich Salz", "text": "

Multiplying by either is likely to overflow and end up at zero.

", "time": "2026-07-21T15:17:29.000Z"}, {"author": "Eric Rescorla", "text": "

Stephen Farrell said:

\n
\n

I'm thinking I'd like a 'no undetectable ghost group members' sentence added to the charter

\n
\n

Is this technically possible? The endpoints can always just exfiltrate the keys

", "time": "2026-07-21T15:18:08.000Z"}, {"author": "Jonathan Lennox", "text": "

Or indeed the data communicated

", "time": "2026-07-21T15:18:42.000Z"}, {"author": "John Gray", "text": "

I don't really understand what I would do with this? I get that it combines MLS with TLS in an interesting way, but what advantage does this give over using either MLS or TLS themselves as intended? The question about security analysis seems relevant as it looks like it may modify standard MLS/TLS work, but I don't know enough about how this is supposed to work.

", "time": "2026-07-21T15:18:47.000Z"}, {"author": "Martin Thomson", "text": "

I'm still missing a problem statement. Why is it impossible to use MLS to generate a PSK for use within TLS?

", "time": "2026-07-21T15:18:52.000Z"}, {"author": "Stephen Farrell", "text": "

@ekr: the entity with the exfiltrated leys would not be a group member then though?

", "time": "2026-07-21T15:19:14.000Z"}, {"author": "Eric Rescorla", "text": "

Stephen Farrell said:

\n
\n

@ekr: the entity with the exfiltrated leys would not be a group member then though?

\n
\n

Not at the MLS layer, no

", "time": "2026-07-21T15:19:25.000Z"}, {"author": "Thom Wiggers", "text": "

@Martin: presumably \"how to run the MLS part\" mechanics are missing?

", "time": "2026-07-21T15:19:35.000Z"}, {"author": "Martin Thomson", "text": "

@Thom Wiggers over TLS, clearly.

", "time": "2026-07-21T15:19:50.000Z"}, {"author": "Sean Turner", "text": "

@Hannes the AI could do slop and comparing it to what people might have done here is not really fair

", "time": "2026-07-21T15:20:19.000Z"}, {"author": "Eric Rescorla", "text": "

The point Hannes is making is actually quite important: it's not safe to have multiple senders on the same TLS connection because they will have colliding IVs

", "time": "2026-07-21T15:20:51.000Z"}, {"author": "Jonathan Hoyland", "text": "

Especially in the drone case where some of them may be out of range of others.

", "time": "2026-07-21T15:21:22.000Z"}, {"author": "Eric Rescorla", "text": "

Eric Rescorla said:

\n
\n

The point Hannes is making is actually quite important: it's not safe to have multiple senders on the same TLS connection because they will have colliding IVs

\n
\n

You need to fix this by having individual sender state at the symmetric layer

", "time": "2026-07-21T15:21:44.000Z"}, {"author": "Ted Hardie", "text": "

For BoF Question 4, I think the deliverables are not in the right order. I think assuming a mulitparty protocol and designing for that makes more sene. If there are sometimes only two parties, it is pretty likely to be a solvable change, where designs going the other direction are less likely to work. I understand that this was a structural limitation to the BoF, but I still don't understand why. As a result, I think this needs more thought.

", "time": "2026-07-21T15:21:47.000Z"}, {"author": "Martin Thomson", "text": "

Well, they need to coordinate, because if they aren't able to sequence IVs properly, the connection breaks and if they collide, the confidentiality and integrity goes away.

", "time": "2026-07-21T15:21:56.000Z"}, {"author": "Robert Moskowitz", "text": "

@EKR, and that is why I keep scratching my balding head on saying TLS with multi-party talks.

", "time": "2026-07-21T15:22:04.000Z"}, {"author": "John Preu\u00df Mattsson", "text": "

My two-party problem statement for long-term connection. I would like TLS/DTLS/QUIC libraries that takes care of frequent rekeying and reauthentication providing Forward Secrecy (FS) and Post-Compromise Security (PCS). I do not want to change my application layer. That could as pointed out also be solved by CURRENT designing a layer on top of TLS/DTLS/QUIC. But such a solution does not solve the two-party space use cases.

", "time": "2026-07-21T15:22:25.000Z"}, {"author": "Eric Rescorla", "text": "

Martin Thomson said:

\n
\n

Well, they need to coordinate, because if they aren't able to sequence IVs properly, the connection breaks and if they collide, the confidentiality and integrity goes away.

\n
\n

The right way to deal with this is just to have different keys, obviously. Which is how TLS handles directional keys now

", "time": "2026-07-21T15:22:40.000Z"}, {"author": "Martin Thomson", "text": "

@Eric Rescorla There is also what some QUIC implementations do, with close coordination, which allows multiple senders to send into the same connection.

", "time": "2026-07-21T15:23:20.000Z"}, {"author": "Jonathan Hoyland", "text": "

I'm a big fan of channel bindings, so I think the analysis would be great fun.

", "time": "2026-07-21T15:23:22.000Z"}, {"author": "Eric Rescorla", "text": "

John Preu\u00df Mattsson said:

\n
\n

My two-party problem statement for long-term connection. I would like TLS/DTLS/QUIC libraries that takes care of frequent rekeying and reauthentication providing Forward Secrecy (FS) and Post-Compromise Security (PCS). I do not want to change my application layer. That could as pointed out also be solved by CURRENT designing a layer on top of TLS/DTLS/QUIC. But such a solution does not solve the two-party space use cases.

\n
\n

This seems like a coherent problem statement.,

", "time": "2026-07-21T15:23:35.000Z"}, {"author": "Robert Moskowitz", "text": "

IEEE 802.1AE addressed the IV collision problem by including the MAC into the IV. Need something similar here?

", "time": "2026-07-21T15:23:46.000Z"}, {"author": "Daniel Gillmor", "text": "

MT: can you offer a pointer?

", "time": "2026-07-21T15:23:57.000Z"}, {"author": "Martin Thomson", "text": "

@John Preu\u00df Mattsson is that not addressed by the TLS with full rekeying?

", "time": "2026-07-21T15:24:00.000Z"}, {"author": "Muhammad Usama Sardar", "text": "

LAKE WG indeed has some phrasing in its charter: https://datatracker.ietf.org/group/lake/about/

", "time": "2026-07-21T15:24:16.000Z"}, {"author": "Martin Thomson", "text": "

Daniel Gillmor said:

\n
\n

MT: can you offer a pointer?

\n
\n

I think that Fastly do this, but it's all proprietary tech, because it is very hard to avoid nonce reuse.

", "time": "2026-07-21T15:24:26.000Z"}, {"author": "Daniel Gillmor", "text": "

Carlos: can't you do that with store-and-forward messaging, e.g. CMS or OpenPGP?

", "time": "2026-07-21T15:24:46.000Z"}, {"author": "Rich Salz", "text": "

LAKE doesn't require it, like Paul said. It says \"he group welcomes formal analysis to be performed ...\" Which means \"we would encourage but not require it\"

", "time": "2026-07-21T15:25:41.000Z"}, {"author": "Jonathan Hoyland", "text": "

Martin Thomson said:

\n
\n

Daniel Gillmor said:

\n
\n

MT: can you offer a pointer?

\n
\n

I think that Fastly do this, but it's all proprietary tech, because it is very hard to avoid nonce reuse.

\n
\n

I don't see why it would be especially hard? There is guidance in the AES-GCM spec for how to achieve this (giving each sender a fixed part of its IV)

", "time": "2026-07-21T15:25:42.000Z"}, {"author": "Martin Thomson", "text": "

@Jonathan Hoyland it's a little harder than that in QUIC because there is a need to have packet numbers be roughly sequential. So you need to have a node in control that doles out ranges of packet numbers. Doable, but totally proprietary.

", "time": "2026-07-21T15:26:33.000Z"}, {"author": "Robert Moskowitz", "text": "

Because the first use case of GCM was 802.1AE.

", "time": "2026-07-21T15:26:37.000Z"}, {"author": "Muhammad Usama Sardar", "text": "

Rich Salz said:

\n
\n

LAKE doesn't require it, like Paul said. It says \"he group welcomes formal analysis to be performed ...\" Which means \"we would encourage but not require it\"

\n
\n

Sure, that's what I also said. Don't require it, but at least mention and encourage it in the charter clearly. We did have some problem at SEAT where we are repeatedly told that formal analysis is out of scope.

", "time": "2026-07-21T15:26:59.000Z"}, {"author": "Jonathan Hoyland", "text": "

Martin Thomson said:

\n
\n

Jonathan Hoyland it's a little harder than that in QUIC because there is a need to have packet numbers be roughly sequential. So you need to have a node in control that doles out ranges of packet numbers. Doable, but totally proprietary.

\n
\n

Ah, ok, I can see how that would be more tricky

", "time": "2026-07-21T15:27:06.000Z"}, {"author": "Eric Rescorla", "text": "

It's clearly possible to figure out how to segment the transmitting IV space and the key space. I'm mostly just saying that you need to solve it and that it's not something the TLS record layer has done

", "time": "2026-07-21T15:27:08.000Z"}, {"author": "Jonathan Lennox", "text": "

MT: Doesn't that just mean you hand out low bits rather than high bits?

", "time": "2026-07-21T15:27:19.000Z"}, {"author": "Jonathan Hoyland", "text": "

Presumably because you need monotonicity?

", "time": "2026-07-21T15:27:43.000Z"}, {"author": "Jonathan Hammell", "text": "

Group communication could be done in NEXT.

", "time": "2026-07-21T15:27:51.000Z"}, {"author": "Martin Thomson", "text": "

@Jonathan Lennox not precisely, because of the weird flux that you get when there are multiple senders who are sending different amounts at different times :)

", "time": "2026-07-21T15:27:57.000Z"}, {"author": "Rich Salz", "text": "

For N-party, can't you hand out a multiplier and each entity uses their next higher multiple?

", "time": "2026-07-21T15:28:58.000Z"}, {"author": "Jonathan Hoyland", "text": "

@MT You've piqued my interest, I'm going to have to look into how that works.

", "time": "2026-07-21T15:29:04.000Z"}, {"author": "Jonathan Lennox", "text": "

Is this use case also interested in using MLS with the QUIC \"record layer\" instead?

", "time": "2026-07-21T15:29:18.000Z"}, {"author": "Muhammad Usama Sardar", "text": "

Also, formal analysis can be seen as review. So my comment was directly an answer to question 6 on display.

", "time": "2026-07-21T15:29:21.000Z"}, {"author": "Jonathan Lennox", "text": "

I think that's what tiptop wants

", "time": "2026-07-21T15:29:43.000Z"}, {"author": "Martin Thomson", "text": "

\"this is doing the opposite of what QUIC did\" - by which you mean QUIC was a good idea, but this is the opposite of that ?

", "time": "2026-07-21T15:30:18.000Z"}, {"author": "Kazuho Oku", "text": "

Martin Thomson said:

\n
\n

Daniel Gillmor said:

\n
\n

MT: can you offer a pointer?

\n
\n

I think that Fastly do this, but it's all proprietary tech, because it is very hard to avoid nonce reuse.

\n
\n

For 3-party QUIC (or coordinated sending), we just ship the encryption key and the PN to be used Screenshot 2026-07-21 at 17.28.38.png. I recall Meta does the same.

\n
", "time": "2026-07-21T15:30:58.000Z"}, {"author": "John Preu\u00df Mattsson", "text": "

@Martin Thomson, Yes all my requirements for long-tern connections can be fulfilled by frequently setting up new TLS/DTLS/QUIC connections and moving over the traffic in a way that do not disturb or require changes to the application layer. If TLS/QUIC WG specified how to that and that is implemented in TLS/DTLS/QUIC libraries that would be good. EKU solves one part but still requires the application layer to do the reauthentication.

", "time": "2026-07-21T15:31:34.000Z"}, {"author": "Daniel Gillmor", "text": "

Kazuho -- ok, but this is basically the QUIC server and the content servers operating as to halves of the server endpoint. right?

", "time": "2026-07-21T15:32:35.000Z"}, {"author": "Martin Thomson", "text": "

Reauthentication is tricky, but that's something TLS can do, with a small extension, not a total lobotomy.

", "time": "2026-07-21T15:32:47.000Z"}, {"author": "Kazuho Oku", "text": "

@Daniel Gillmor Exactly!

", "time": "2026-07-21T15:32:48.000Z"}, {"author": "Daniel Gillmor", "text": "

two* halves

", "time": "2026-07-21T15:33:00.000Z"}, {"author": "Daniel Gillmor", "text": "

non-x.509 credentials in TLS would belong in the TLS working group

", "time": "2026-07-21T15:34:00.000Z"}, {"author": "Eric Rescorla", "text": "

As noted above, basically everything anyone designs has some kind of agility for credentials. TLS certainly does

", "time": "2026-07-21T15:34:17.000Z"}, {"author": "Eric Rescorla", "text": "

Like it's literally just a code point.

", "time": "2026-07-21T15:34:25.000Z"}, {"author": "Jonathan Lennox", "text": "

It's only been defined for x.509 and raw pk, but that's only because that's all anyone's needed

", "time": "2026-07-21T15:34:45.000Z"}, {"author": "Eric Rescorla", "text": "

Jonathan Lennox said:

\n
\n

It's only been defined for x.509 and raw pk, but that's only because that's all anyone's needed

\n
\n

I think there's actually a PGP one too

", "time": "2026-07-21T15:34:56.000Z"}, {"author": "bengo", "text": "

Is the \u201cproblem statement\u201d explicit somewhere? If so where. Sorry noob question.

", "time": "2026-07-21T15:35:06.000Z"}, {"author": "Jonathan Hoyland", "text": "

I think the closest thing is https://docs.google.com/document/d/1f8KDExti7Eo_LvRFIZyHKJcpVUXF0Et8vDPo5nPdRGY/edit?tab=t.0

", "time": "2026-07-21T15:35:28.000Z"}, {"author": "Marc Blanchet", "text": "

for chairs, I voted \"no opinion\" but my real vote was more \"somewhat\"

", "time": "2026-07-21T15:35:36.000Z"}, {"author": "Robert Moskowitz", "text": "

Without a clear problem statement how can we answer #2?

", "time": "2026-07-21T15:35:40.000Z"}, {"author": "Daniel Gillmor", "text": "

there is a PGP codepoint for TLS. it was deprecated though : https://www.rfc-editor.org/info/rfc6091/

", "time": "2026-07-21T15:36:01.000Z"}, {"author": "Daniel Gillmor", "text": "

you'd get more than one answer

", "time": "2026-07-21T15:36:20.000Z"}, {"author": "Stephen Farrell", "text": "

not sure we need that answer: there're clearly some interested IETFers who know how this stuff works, so they can come back

", "time": "2026-07-21T15:36:36.000Z"}, {"author": "Martin Thomson", "text": "

there are many problems in this space, yes

", "time": "2026-07-21T15:36:49.000Z"}, {"author": "Jonathan Lennox", "text": "

The question \"was there at least one question presented today that the IETF is the right place to work on\" could be answered, but I\"m not sure it's a useful question to answer

", "time": "2026-07-21T15:37:10.000Z"}, {"author": "Eric Rescorla", "text": "

I don't really think there is much point in asking more questions here.

", "time": "2026-07-21T15:37:36.000Z"}, {"author": "Stephen Farrell", "text": "

right, and the proponents i guess know what to do

", "time": "2026-07-21T15:37:52.000Z"}, {"author": "Daniel Gillmor", "text": "

and we don't know what the work is

", "time": "2026-07-21T15:37:53.000Z"}, {"author": "Robert Moskowitz", "text": "

Yes, whatever the work is!

", "time": "2026-07-21T15:38:02.000Z"}, {"author": "Eric Rescorla", "text": "

Stephen is right, the right thing is for proponents to come back with a proposal which gets a positive answer to quesiton 1

", "time": "2026-07-21T15:38:04.000Z"}, {"author": "Martin Thomson", "text": "

anything to do with TLS and MLS does belong in the IETF, but that isn't useful without knowing what the \"any\" and the \"thing\" are doing with each other.

", "time": "2026-07-21T15:38:28.000Z"}, {"author": "Daniel Gillmor", "text": "

no, if you want MLS as the handshake for the 2-party TLS protocol, you have to say why

", "time": "2026-07-21T15:38:52.000Z"}, {"author": "David Schinazi", "text": "

In space no one can hear you rekey

", "time": "2026-07-21T15:39:27.000Z"}, {"author": "Orie Steele", "text": "

^ <3

", "time": "2026-07-21T15:40:10.000Z"}, {"author": "Daniel Gillmor", "text": "

that is, what is missing from the TLS handshake that you think a new handshake would improve?

", "time": "2026-07-21T15:40:17.000Z"}, {"author": "Martin Thomson", "text": "

David Schinazi said:

\n
\n

In space no one can hear you rekey

\n
\n

So why bother doing it?

", "time": "2026-07-21T15:40:32.000Z"}, {"author": "Eric Rescorla", "text": "

Ye

\n

Daniel Gillmor said:

\n
\n

that is, what is missing from the TLS handshake that you think a new handshake would improve?

\n
\n

Yes, that would be an excellent statement

", "time": "2026-07-21T15:40:36.000Z"}, {"author": "Daniel Gillmor", "text": "

if you want more yeses, try asking \"are you willing to complain about the lack of clarity in the next round of problem statement?\"

", "time": "2026-07-21T15:40:51.000Z"}, {"author": "Jonathan Lennox", "text": "

I don't think \"are you willing to complain\" is ever a question that needs to be asked at the IETF

", "time": "2026-07-21T15:41:31.000Z"}, {"author": "John Gray", "text": "

Agreed, we need clarification of the problems and why MLS/TLS are the best way to do it.

", "time": "2026-07-21T15:41:41.000Z"}, {"author": "Ted Hardie", "text": "

Don't motivate that--describe the problem with clarity. If that is the right answer, that will emerge.

", "time": "2026-07-21T15:41:42.000Z"}, {"author": "Harald Alvestrand", "text": "

I'm interested in the claim that MLS can do key rollover on an one-way channel. Since an one-way reliable channel is a contradiction in terms, that would require MLS key rollover to be resistent against packet loss.

", "time": "2026-07-21T15:42:01.000Z"}]