[{"author": "Richard Barnes", "text": "

wow, we really got the tiniest room this time

", "time": "2023-11-08T08:31:46Z"}, {"author": "Richard Barnes", "text": "

lgtm so far

", "time": "2023-11-08T08:35:54Z"}, {"author": "Brendan McMillion", "text": "

Would be great to be able to list some concrete extensions / timeline for when they'll be done

", "time": "2023-11-08T08:37:44Z"}, {"author": "Richard Barnes", "text": "

yeah, +1 to EKR

", "time": "2023-11-08T08:39:20Z"}, {"author": "Simon Friedberger", "text": "

https://github.com/mlswg/wg-materials/pull/14/files

", "time": "2023-11-08T08:41:41Z"}, {"author": "Rohan Mahy", "text": "

Regarding the \"thorough security analysis\", the point of the safe extensions work is that additional formal analysis is not necessary for any combination of safe extensions. This doesn't mean there is no security analysis, but that the security properties of MLS aren't invalidated

", "time": "2023-11-08T08:42:07Z"}, {"author": "Raphael Robert", "text": "

Not quite true Rohan, a safe extension can still be dangerous in different ways

", "time": "2023-11-08T08:42:51Z"}, {"author": "Richard Barnes", "text": "

The \"safe extensions\" is just securit analysis abstracted one layer -- analyze the framework instead of each one individually

", "time": "2023-11-08T08:44:47Z"}, {"author": "Jonathan Hoyland", "text": "

I agree with Raphael, you still need to prove that any new extension fulfils the assumptions of the extension framework.

", "time": "2023-11-08T08:44:47Z"}, {"author": "Richard Barnes", "text": "

SHOULD it be capitalized?

", "time": "2023-11-08T08:45:29Z"}, {"author": "Jonathan Hoyland", "text": "

I could define an extension that publishes the keys to Twitter.

", "time": "2023-11-08T08:45:31Z"}, {"author": "Richard Barnes", "text": "

RFC 6919

", "time": "2023-11-08T08:45:41Z"}, {"author": "Richard Barnes", "text": "

@Jonathan no you couldn't, you would have to publish them to X

", "time": "2023-11-08T08:46:15Z"}, {"author": "Britta Hale", "text": "

The safe extension work is focused on negative impact to MLS. Analysis of extensions themselves would provide insight on their security. I agree that it is probably a good idea for approved/WG accepted extensions to be treated with the same rigor as the original protocol so that users have more assurance than \"non negative\" security effects.

", "time": "2023-11-08T08:49:03Z"}, {"author": "Daniel Gillmor", "text": "

slide 7 about mls extensions claims that they can use \"public key material\" but konrad said \"signatures\" -- if they're making signatures, that's not public key material.

", "time": "2023-11-08T08:57:01Z"}, {"author": "Richard Barnes", "text": "

@DKG that seems useful to take to the mic

", "time": "2023-11-08T08:57:26Z"}, {"author": "Deirdre Connolly", "text": "

I very like \"domain separation by extension id by default\"

", "time": "2023-11-08T08:58:19Z"}, {"author": "Deirdre Connolly", "text": "

Is there any worry about signing/encrypting oracle attacks

", "time": "2023-11-08T08:59:10Z"}, {"author": "Daniel Gillmor", "text": "

so i think i understand this as saying that the extension cannot make signatures that either the main protocol could have made or any other extension could make; and it can decrypt messages from any other client only if those messages came from the other client's implementation of that same extension.

", "time": "2023-11-08T09:02:37Z"}, {"author": "Deirdre Connolly", "text": "

An aside, I know there has been MLS message format analysis and recommendations in the Comparse model/work, has any of that been for MLS Extensions ?

", "time": "2023-11-08T09:03:20Z"}, {"author": "Jonathan Hoyland", "text": "

If I'm a malicious extension implementation can I access the secrets of other extensions?

", "time": "2023-11-08T09:05:10Z"}, {"author": "Richard Barnes", "text": "

@Jonathan I think the goal is to avoid that

", "time": "2023-11-08T09:05:29Z"}, {"author": "Richard Barnes", "text": "

but obviously that comes down to software

", "time": "2023-11-08T09:05:39Z"}, {"author": "Jonathan Hoyland", "text": "

So I see how that's avoided in the spec, but not how that would be enforced in code?

", "time": "2023-11-08T09:06:09Z"}, {"author": "Richard Barnes", "text": "

Not the IETF's job to do code!

", "time": "2023-11-08T09:06:20Z"}, {"author": "Benjamin Beurdouche", "text": "

Deirdre Connolly said:

\n
\n

Is there any worry about signing/encrypting oracle attacks

\n
\n

Not that I know of.

", "time": "2023-11-08T09:06:53Z"}, {"author": "Jonathan Hoyland", "text": "

Fair, but that does seem a critical point, so maybe worth calling out in the spec?

", "time": "2023-11-08T09:07:09Z"}, {"author": "Richard Barnes", "text": "

@Dierdre - There is some domain separation for signing/encryption in MLS. grep for \"WithLabel\"

", "time": "2023-11-08T09:07:42Z"}, {"author": "Deirdre Connolly", "text": "

@Richard Barnes is that similarly enforced by the domain separation between new Extensions?

", "time": "2023-11-08T09:08:26Z"}, {"author": "Richard Barnes", "text": "

@Dierdre I would hope so!

", "time": "2023-11-08T09:08:44Z"}, {"author": "Benjamin Beurdouche", "text": "

Deirdre Connolly said:

\n
\n

An aside, I know there has been MLS message format analysis and recommendations in the Comparse model/work, has any of that been for MLS Extensions ?

\n
\n

We are following the TLS approach so afaik we have no ambiguous message format problem by design.

", "time": "2023-11-08T09:08:44Z"}, {"author": "Benjamin Beurdouche", "text": "

It is a good point though to ensure this problem doesn't appear in apps through extensions

", "time": "2023-11-08T09:09:42Z"}, {"author": "Richard Barnes", "text": "

I would probably propose that most of these things go into separate documents. They are not small extensions.

", "time": "2023-11-08T09:09:51Z"}, {"author": "Deirdre Connolly", "text": "

@Benjamin Beurdouche that's good, the Comparse work found/confirmed signature confusion in draft 12 of MLS, so it'd be good to continue using that framework to analyze the new Extension message formats

", "time": "2023-11-08T09:09:58Z"}, {"author": "Konrad Kohbrok", "text": "

Richard Barnes said:

\n
\n

I would probably propose that most of these things go into separate documents. They are not small extensions.

\n
\n

Yes, at least for the \"user trees\" we're in the process of writing something down.

", "time": "2023-11-08T09:10:27Z"}, {"author": "Richard Barnes", "text": "

To Sean's point \"Extensions to support MIMI\" is easy charter scope to write

", "time": "2023-11-08T09:11:52Z"}, {"author": "Richard Barnes", "text": "

and I think MIMI is forbidden by charter to DIY

", "time": "2023-11-08T09:12:06Z"}, {"author": "Alissa Cooper", "text": "

MIMI's charter says that extensions to MLS are out of scope and \"If needed, requirements will be referred to the MLS working group or other relevant working groups in the security area.\"

", "time": "2023-11-08T09:12:25Z"}, {"author": "Alissa Cooper", "text": "

https://datatracker.ietf.org/wg/mimi/about/

", "time": "2023-11-08T09:12:40Z"}, {"author": "Deirdre Connolly", "text": "

I wonder if we can nerd-snipe karthik et al into modeling the Extensions formats :grinning_face_with_smiling_eyes:

", "time": "2023-11-08T09:13:19Z"}, {"author": "Jonathan Hoyland", "text": "

Is this mooted by user trees?

", "time": "2023-11-08T09:14:44Z"}, {"author": "Richard Barnes", "text": "

@Dierdre unfortunately Karthik is a consultant now :money_face:

", "time": "2023-11-08T09:16:03Z"}, {"author": "Konrad Kohbrok", "text": "

MIMI is probably going to need more than the user trees extension will provide.

", "time": "2023-11-08T09:16:06Z"}, {"author": "Konrad Kohbrok", "text": "

(Never mind, I misunderstood your question.)

", "time": "2023-11-08T09:16:52Z"}, {"author": "Deirdre Connolly", "text": "

I just pinged him, we'll see :halo:

", "time": "2023-11-08T09:19:48Z"}, {"author": "Brendan McMillion", "text": "

It sounds like the enforcement can be done by the client just doing bookkeeping itself about what KPs are for what purpose. In which case, I don't see why it would need an extension, if it's not communicating anything to anyone else

", "time": "2023-11-08T09:29:02Z"}, {"author": "Jonathan Hoyland", "text": "

Belt and braces security?

", "time": "2023-11-08T09:29:34Z"}, {"author": "Deirdre Connolly", "text": "

'defense in depth' <3

", "time": "2023-11-08T09:29:50Z"}, {"author": "Brendan McMillion", "text": "

Kabuki theater(?)

", "time": "2023-11-08T09:30:08Z"}, {"author": "Daniel Gillmor", "text": "

\"sensible mimi chairs\" -- you heard it here first

", "time": "2023-11-08T09:36:36Z"}, {"author": "Alissa Cooper", "text": "

you could hook the scope in the MLS charter to the scoping constraints in the mimi charter, e.g., the mimi charter has a notion of an \"initial phase\" (focused only on messaging) and has a long list of things that are out of scope

", "time": "2023-11-08T09:38:13Z"}, {"author": "Deirdre Connolly", "text": "

Important: the NEW kyber does not commit to the public key/ciphersuite, does MLS rely on that? or does the HPKE handle that fine?

", "time": "2023-11-08T09:38:18Z"}, {"author": "Richard Barnes", "text": "

@Dierdre - Interesting, i did not know that. I expect that Th\u00e9ophile will know the answer to that

", "time": "2023-11-08T09:38:58Z"}, {"author": "Deirdre Connolly", "text": "

It's annoying and keeps biting

", "time": "2023-11-08T09:39:07Z"}, {"author": "Richard Barnes", "text": "

and maybe Beurdouche

", "time": "2023-11-08T09:39:10Z"}, {"author": "Deirdre Connolly", "text": "

There are arguments that seem to boil down to 'it makes the IND-CCA* proofs nicer'

", "time": "2023-11-08T09:39:29Z"}, {"author": "Deirdre Connolly", "text": "

A worry:
\nimage.png

\n
", "time": "2023-11-08T09:41:25Z"}, {"author": "Benjamin Beurdouche", "text": "

Yikes

", "time": "2023-11-08T09:41:32Z"}, {"author": "Richard Barnes", "text": "

@Dierdre where is that from?

", "time": "2023-11-08T09:42:14Z"}, {"author": "Daniel Gillmor", "text": "

yikes indeed. @Deirdre Connolly are you saying that the reason for the change is that not committing to the key/ciphersuite makes the IND-CCA proofs nicer?

", "time": "2023-11-08T09:47:15Z"}, {"author": "Richard Barnes", "text": "

that's a good point, that HPKE is public-key committing even if the underlying KEM isn't

", "time": "2023-11-08T09:47:16Z"}, {"author": "Konrad Kohbrok", "text": "

Nice proofs are important!

", "time": "2023-11-08T09:47:36Z"}, {"author": "Richard Barnes", "text": "

correct proofs are important!

", "time": "2023-11-08T09:47:48Z"}, {"author": "Konrad Kohbrok", "text": "

It's easier to check proofs for correctness if they are nice.

", "time": "2023-11-08T09:48:09Z"}, {"author": "Raphael Robert", "text": "

We should only submit perfect drafts from now on

", "time": "2023-11-08T09:48:47Z"}]