Internet Engineering Task Force 101, 22 Mar 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF101-MLS-20180322-1550

Description

MLS meeting session at IETF101
2018/03/22 1550

https://datatracker.ietf.org/meeting/101/proceedings/

A

Hello, everybody welcome to the.

B

Mls Boff we're gonna start in about two minutes so who, in the audience, would like to volunteer to take notes.

B

Okay, we have a volunteer over there and the Dean.

B

You can you can stay where you're on, if you like, by.

C

The way very entertaining Layton talk, sack.

C

Do we also have a jabber scribe somebody, an excellent.

C

B

Alright, so, as our new area director arrives, I'd like to welcome everybody to the messaging layer, security Boff, if you're expecting something else or if you're in the other room no, this is this is the right room. So today we're going to go through several presentations and talk about a proposed charter for messaging layer, security.

D

C

The note: well, it's Thursday, you should have seen this a bunch, so we're not going to linger on this very long, buts in the slides. If you really want to read it, we got a minute take here. We got a jabber scribe. Please sign the blue sheets as they're going around unless you're not already subscribed to the mailing list. It's there and the jabber room is also listed on the slide.

B

Alright, so this is the overview of the agenda: we're going to start with a bit of agenda bashing. If anybody has any changes, they want to propose, as well as following that we're going to do a 30-minute problem statement, followed by an architecture, presentation, a protocol, Draft presentation, as well as a state of formal minute analysis, and then we're gonna spend most of the remainder going over the Charter text very closely and we'll end it off with some Boff questions.

B

So we'll try to keep this moving rather quickly and if people get behind what will let you know just.

C

So no one's surprise, they are the typical Boff questions. So if you've ever read the RFC on how to run a successful Boff, we just copied them. So there's no surprises and we don't have to argue about where the words go in the sentence.

C

Okay, so first up is Richard.

E

All right, Thank, You, Charis, thanks everyone for being here so I, wanted to give everyone an overview of. Why we're here today, the group of us who proposed this, why we care about this? What problem we're trying to solve next slide? Please! So if you look at the app store, any App, Store really and look at for secure messaging apps, nowadays you get a bunch of them. I think we've got people who work on most of these here act today. Actually, um a lot of these are using really similar protocols.

E

Variants on signal protocol are especially prevalent. Some of them are using super different things. A Cisco spark there in left column and iMessage use pretty different protocols, but what's common about all of them, is that they're uncommon they're all using different protocols, maintaining their own libraries, their own software, and because all these protocols are different, they have independent security analyses and some of them have gotten very thorough security analyses and academic papers, and some of them have no analysis at all that I know of anyway, and so the goal of this well next slide.

E

The goal of what we're doing here is to kind of address that situation. The concrete target we're after is an asynchronous group messaging security protocol. Well, delt will dive in to unpack that on the next slide, but the idea is to get something that can meet the the needs of all those apps that were on that last slide and more and other applications that have these common. That common use case in common yeah now, to put a little finer point on that, we're there's a couple of aspects of interoperability.

E

We are after and some we aren't. So the impact of these specifications that we're trying to get here I'll skip to the bottom and say that we're not trying to get full interoperability between messaging applications. That's a much more complicated question involving a message transport involving how you express application level notions.

E

What you put in a message and what we're laughter here is really just that crypto layer. So getting a crypto layer. That's specified closely enough that we can generate code, that's reusable in multiple contexts and have security analyses that can be used to underpin these messaging applications.

E

So the analogy here is that there's tons of applications that use HTTP that use TLS and use TLS in different ways, and so the idea here of MLS is design design, a messaging security protocol that can be used in many different applications in many different ways and what you'll see in these documents? The architecture we'll discuss kind of the are general architecture for how we imagine a messaging protocol and how MLS can fit into that context. And then the protocol documental describe the draft. We got what we got so far: yeah EKG hi.

F

Daniel con Gilmore ACLU, so just as a clarifying question on this slide, you mentioned that application level. Interoperability is in non-goal. This does not address single application with multiple say servers or federated communication. So I just want to be clear that federated communication like across server domains or things, is also how to scope for this. I would say so. Yes, okay, just wanted to make sure that that's clear too, because it seems like that would be a relevant point right. We have XMP already, for example, and we're not trying to do that. That's.

E

Correct, yes, I think I think probably won't. We want to be compatible with use cases like that and not block that I. Think Dave Kirtland, if he's in the room, has already been thinking some about how to address XF in PP, but I think that's something we're not it's not kind of a primary goal: okay, yeah.

G

My perspective XMPP has like no medications to structurally at all other than like it's you know. Are they on the same server right? So you need it, but I mean if somebody were layer, authentication structure on top an XMPP, then you could imagine, then you imagine everybody who would like to here. Do that would be able to talk over XMPP with Federation yeah I think there were the route that the case I think that is, that is that it is like not really in the scope at all.

G

His is like people have their own disjoint like authentication in any infrastructure, is talking to each other.

E

And and I'm really yeah I think that a lot of other Federation that where Federation will become an issue for this protocol, is in the authentication layer and that's all I'll speak more a bit more about authentication there. Let me just table that for the moment, so next slide, please well doc, unpack this.

E

This, the concrete substantive thing we're after here, so we've got a few components to this description, so whatever protocol we need here, we get here needs to have this asynchronicity property and what that means is we want to be able to have these secure messaging sessions where no part to participants are online at the same time. So if I'm, starting up a chat with you, mad I should be able to get some information with that.

E

His he's cashed in the cloud and start up a conversation with him and send him messages that are secure with regard to to everyone, but you med and then, when he comes online, he can get those messages, perhaps update his key and respond to me without me being online and then, when I come back, online I can download those and read those messages, etc, and that applies to both messaging as I was talking about just now, as well as changes to the group ads removes and that kind of move goes into the next one.

E

So this is more than just a one-to-one protocol. So tell us the case: we've had the most experience within the IETF is explicitly a one-to-one protocol. There's a client and a server, and the use case were after here is groups. There are some protocols that have been really well vetted in in the one-to-one space and I. Think a lot of what this is and mentioned. This later is to kind of generalize some of those lessons. We've learned from those protocols to make them work better with groups. Yes, please hi.

H

Dave Kemp, um you say: support sessions. Does that imply that there's state carried over time and there's a an in session primitive to this, or is it really like messaging, where each message stands on its own.

E

At least in the drafts we have now, there is a condition of continuity of a session and I. Think, oh, maybe I'm. Looking over a catriel, our our academic friend here I think some of the goals we have around post compromised security probably depend on carrying that state. I, don't know we need to discuss it a lot but yeah right now.

E

We do have that notion that there is a group and there's a conversation that involves over time that is correlated in their state that gets carried along yeah thanks for the question so yeah, so we need so we're supporting groups here, it's not just one to one and we're. We have a goal to support large and dynamic groups.

E

So obviously we need to be able to add people to groups to build the groups and remove them over time and in addition, a lot of the the the reason we need to look at a group protocol, as opposed to just using a whole bunch of one-to-one channels.

E

Is that there's a bunch of messaging applications that have needs support large groups, so I feel like the number goes up by an order of magnitude every time we have a conversation about it, but it's in the kind of thousands to hundreds of thousands of range and hereby members typically will be talking about individual devices, individual private key holders, so pretty large groups- and you can imagine you know if you're scaling of your protocol is linear at that sort of scale.

E

It gets to be kind of difficult to do a hundred thousand D H operations, it's to had someone say, or you know things that are quadratic- that might work at small scale, get really difficult at the scale of you know, once you had some zeros, so large dynamic groups and try and address those pretty efficiently. Now, let's talk about the security properties, we're trying to get and I've got a cartoon on this in the next slide. There's a few major security properties were trying to get here.

E

Obviously we want message confidentiality, that's kind of why we're doing this whole thing to start with, but within that we want that confidentiality properties to have two properties in terms of its evolution over time. So it's a good question earlier.

E

We want forward secrecy so a you know in the sense that if there's a compromise, then past conversations are secret and we also want post compromised security, and this is a will be a less familiar notion of folks in the sense that, if there's a compromise, then at some point, future messages are also going to be secret from the attacker, who had a point compromised, well I'll dive into that a little bit more on the next slide.

E

Authentication is a concept that's going to be critical here, so that we know who were encrypting to who can read these messages that are confidential. What the boundary of the confidentiality is and finally there's some explicit non goals. We want to call out here that have been properties of some problem. Some protocols in the prior art deniability is one I've said full time deniability here, because we may want to have some deniability, but we know we need a non-denial option for several cases that we've talked about.

E

If you look at some of the existing cases, malleability again transcripts, Forge ability is, is a property that something prior arc has that I'd, at least among any discussions we've had so far has not been a requirement.

E

E

Deniability karthick, would you like to comment on this? No okay, I think what we mean here is deniability means to be able to know becquer yeah.

G

Is to be able to claim that the message that was sent wasn't yours and right, therefore, not to be possible for someone else to prove you use any given message or that you engage in a in a in a communication. Yeah.

E

They're kind of the opposite of non-repudiation.

G

So it's tactical stuff: we don't want to get into.

E

It's kind of the opposite of integrity yeah after the fact you yep all right next slide kind of is a cartoon of what we mean, the the topics of the properties we'll talk about most or for our security and post compromised security. This is to cut a cartoon of what we mean by that, so both of those properties are addressed as a point compromise. The assumption that an end point is fully compromised. All of its secrets are published.

E

The attacker at a point in time and the idea of having forward secrecy and post compromised security properties in a protocol is that there are some protocol actions that establish these boundaries. So in TLS you get forward security when you do a a new handshake with fresh th exchange, because the fresh entropy from that d-h exchange cuts off anyone who had the secrets to the session in the past so that that would be kind of the left hand boundary here. If you think about this in TLS sense, post compromised security is kind of similar.

E

We also addressed that with kind of adding fresh th entropy, but here it's kind of you. You have the endpoints keep around some state that they can use to update over time and add fresh th entropy as the business forward. It's a kind of lockout of past versions of themselves.

F

Sorry, this is dkg again. I, actually think that your explanation of forward security was incorrect and it may just been a slip, but I think it's easier to think of forward secretly forward security in a messaging context as deletion schedules. What gives you forward security is not that you created a new D H pair or even that you ratcheted forward a secret, but that you destroyed the prior secret. That's what gives you the forward security, the destruction of the old secrets, not the new stuff. Well,.

E

It's a combination of both you if.

F

You destroy the old secrets and you know create the new stuff and you can't keep talking yeah right, but the destruction.

E

Is what gives you the forward security yeah? You need to transform the group state to something that's inaccessible, to people that have the history and then delete the history yeah. Absolutely so next slide. Yeah I just wanted to call out the prior art here for comparison. There's been a bunch of work on this in past. I won't go through the specifics. I think the the overarching the important thing to take away here is that you know the more recent stuff is which is closer to the bottom.

E

There's been a lot of good work on ratcheting protocols that that do really well in the one to one case and demonstrate how to do a synchronicity and how to do pcs, but don't really scale well when you're trying to do larger groups and so I think a lot when you look at the protocols we've sketched out that are in the draft you'll see that they look a lot like these earlier ratcheting protocols, but they try and compress some state down so that they can do more efficient operations for juice.

E

Next slide, please so yeah. This is just kind of a cartoon of what we mean by ratcheting it show of hands. People have heard of ratchets and, in the crypto sense, okay good. So this is pretty familiar idea, so we generally talk about two types of rackets. The left-hand side shows hash ratchets, which are you know, forward security things.

E

So, as dkg was saying, if you are derived things from, if you drive things forward in time by hashing and you delete the old things, then you can't go backwards in time and get earlier secrets and on the right hand, side is what we'll call it D H ratchet, where you update the keys you're using in ADH exchange over time, and that gives you post compromised security with regard to older, D, H keys and again, you have to delete the old things as well.

E

In this case, to get pcs, um they want other concepts, so these are kind of the things the tools were using from the prior art to get some of these properties. The other thing is that we've cut we're kind of pulling from the prior art. Is this idea of init keys or pre keys a lot in the literature which are things that I can publish in the cloud that allow someone to initiate a conversation with they provide a public key and some related information?

E

Someone can use to initiate a conversation with me and begin sending me messages without my being online, so those are that's going to be kind of the key to getting in a synchronicity in a couple senses we're gonna, have some user init keys and we'll have group init keys. John will talk about that more and when we talk about the protocol later next slide, please so this just kind of sum up. This is a cartoon of the the scope I talked about earlier.

E

So you know by analogy to TLS here, as I said before, there's lots of applications out there that use TLS HTTPS, my that's my mum, SMTP, XMPP, etc and they're running over different transports. Tianna. If you incorporate details in this picture, they're transported in different ways, they might be transported in HTTP for those of you who came to the a TLS law earlier. This discussion is earlier this week, there's different transports.

E

You can transfer these security protocols different way and they carry different things and but there's a common security layer that addresses the I want to have a secure connection between a client-server use case and similarly off to the side there. They there is a relatively generic authentication function, built into TLS, where you can plug in a certificate, and you can do a signature to create a certificate. Verify message that authenticates the holder a key pair, but the details of the PKI that get used with TLS aren't specified in TLS.

E

There's just that clean interface point and so I think that kind of encapsulates what we're trying to get at here. So we want a security protocol that can serve this group messaging function, kind of independent of transport and independent of exactly what's being carried in those messages, and also have this interface point over to some authentication scheme so that we can take different authentication schemes and plug them in in a way that gets where, where we know something about what security properties we get. So you need to define that interface.

E

Well enough, so that we can talk about it, security properties without wetting ourselves to a whole, detailed authentication, infrastructure. I. Think that's my last slide. Yeah questions on the problem statement. Thank you for the clarifications we've had so far.

E

I

Hi everyone, I'm Imelda, Maura I'm, the tech lead for cones and robots, see security in Google, so we'll talk about. Amelia's architecture covers the system, overview and functional security requirements. So this is bitly. Any massif estimate expect to be server side and client side. So server side has a certification and services most of the times are operating under under the same entity, but they are logically separate clients either a bunch of users. Issues are maintained at one or more device like web desktop mobile from the protocol perspective.

I

Hd device is a separate entity, that's a good client. So in this picture we have like four four members, a b c and d, and there is a group between a B and C. It has three devices ps2 one cs1, so syndication services basically provides mapping between user IDs like email or phone numbers to long term items, C, Keys delivery services. It ensures an order and reliable message, delivery and attachment and if any reordering the message the client should, the protocol should be able to detect that and also store and achieve. Initial user need. Kids.

I

This key is used to create a first message or established session with things without being online, and this is keys are signed by the wrong emergency keys and asterisk stores group membership. So let me list by itself that requires application or the server to store the group members.

I

However, the the second always nosiest by doing like some traffic analysis, so some application might just end up storing the group numbers on the server and one last saying the server is also responsible for evicting long-term inactive users just to protect for secrecy like most application to the using like 30 or 45 days, and after that we just effective 50 with our clients. From the conversation, it's like this okay, so user will do what you expected to do in any messaging systems.

I

We adjust our group, send receive messages, invite remove members join or leave existing groups or add remove devices from the vertical perspective and to remove members and move devices you're the same device at the end of college, just a single client. So it's a vertical layer. They are the same operation and all call all clients are peers. So anyone can add remove any other one. The Ackland for this operation would be up the application layer. So in this situation like a one would create a group with T and C.

I

So a one will request in it: keys for a 2, a 3, B, 1, B, 2 and C 1 click, shirt, secret, verify the signature and this inactive great shirt secret and keep the message and sent to B and C and B SC will calculate the same shirt secret decrypt. The message and optionally will trigger a nuclear vision to improve future for secrecy. Next slide. Please ok, functional requirements scalable, so the protocol should be able to support large group up to 50,000 clients.

I

Isochrones should be able to start all the other operations of the need for all clients to be online and, of course, multi device, and because, as I mentioned device are obtained, a separate entity, so multi device could be supported. Natively. However, when you add, a new device will not be able to access the previous conversation history, but it's always up to the application to support this estate recovery.

I

So if any device or any clients lost the state should be able to recover it without affecting the group and the Ruby state method is our collection is to protect user privacy, so authentication service order. A service should only collect the manometer data to deliver the message Federation as Richard mentioned, so we don't expect a full interval receive it at the application layer. However, as a protocol layer, different implementation should be able to interpret so far. You need a Mike.

J

Could you clarify whether state recovery is speaking about on device state or maybe server state in.

I

Devices states like, for example, is a application crash before updating its a state, so should be able to recover from this.

K

Partes, so if I have multiple devices and there you said that they're roughly equivalent to multiple users, their operations are the same and aren't you already leaking information about when I'm answering from my mobile phone or from my smart TV at home? Yes,.

I

This is a privacy concern concerning this issue, but I believe most of the protocol today support multi-vise have the same issue. However, there isn't some tricks, you can do with a sphere for art. The cheese structure can actually work around this. For example, can you can talk about this more in the protocol, but one idea of this I have all devices under the same node, so from other users can only see a single node. You don't know how many devices you have, but this is a problem with any-any.

K

F

Is dkg I was gonna, actually ask the same question. It seems to me like this is not actually a requirement given the given the one device fan-like doing its own internal fan, I.

I

Guess I guess well, I mean buzz requirements here, because we want every device has its own identity key. This is why I say it's separate clients so because some application require all clients under the thing user shares are similar in C key.

G

Let me propose a distinct way to phrase this requirement. It must be possible the other system in which people do not share data between devices, but rather have it as the visit independent.

G

G

Yeah, that's an it's a caveat like it's like really really hard to get to get. It's really really hard to get that cryptographically, it's easier to get it with an application. I mean so we just concluded. It was too hard like really make it work with the crypto.

L

Ben Schwartz, I I think would be nice, at least if we could entertain a requirement to be able to do this without knowing who the members of a group are and I suspect that a blind signature scheme where you can, which would allow you to decouple the fact that somebody has an account on the system from the from the identity of the person in question.

G

Yeah the problem.

I

Is authentication like.

I

M

Yeah monix is their assumption that the group that there is a some server that has a canonical notion of who he hasn't isn't in the group and tells other people or is there some possibility of a distributed groups where different group members have different notions of who's in it. So.

I

He basically, no you ask him. Oh it needs that client maintains that membership is accrual. Your membership, so yeah.

E

No I think one of the security properties that we're after here is that all participants in the group have the same notion of who is in the group and so that that's a property. We want to assure independent of the server.

D

Really you want everybody to know who's in the group. Sorry Phil harm baker. In my applications, I want to be able to join somebody to a group and have them participate without knowing who else is in the group. Well,.

I

As I mentioned in my previous slide with membership asterisk, the Amelia doesn't require the server to store this. Our some server mighty chooses to it. Does it's not to the application so but cool level? It doesn't care.

I

Ok, so so far, so good last point burgeoning let's make things more complex, so yeah Emily. It should support multiple versions, and it should make sure that picking the highest supported version between outlines and, of course, have mitigation for downgrade attacks. Cleaner, sightings, okay, security requirements, so method secrecy. Only it should have only a group member exists. Current group member should be able to decrypt and access the messages.

I

Intention, authentication messages only be accepted if sent from an investment. Good member, we again another asterisk case. We could optionally improve this by adding padding to the message to make it hard for charity and Isis for secrecy, as explained earlier so means if an attacker have access to all the encrypted traffic and current key material, they should not be able to decrypt message orders and, as all this key the attacker have, and what school and security it's the other way around.

I

So if an attacker has stuck in existing key material at time, T and this key material oblivia time, T, prime, that data will not be able to decrypt any message of such a boring group membership security. So only all client should have the same view. Group member. They could use like something like my batteries or cheese's. Something like that added client should not be able access previous message before joining the group and same for remove the client. We should never access to the message after delay.

I

Attachment security should have the same properties for messages except the encryption. T key through the attachments tends to have longer life time because of the bandwidth your chance to download this later, so they might have a weak or pcs property. This origin authentication this means no other client, can impersonate any other client in the conversation. So I ask consent messages that please come from Bob.

I

This will require adding a signature for your message and another asterisk is deniability, so it's very painful so I know so it Emily specifically explained it doesn't require the nobility, but so particularly container, which there are four camps. First, camp I don't understand the ability and I don't care, which is easy. Second camp I understand the reality, but live don't work. This way all I need to do is just a screenshot of the application to prove the sender of the message. Still easy, sir camp is the object of the nobility I. Don't need deniability I.

I

Think I need a clip to prove for the message center and for scam with people who really really care about the narrative. You think it's awesome. We can't live without it. So it's a hard to make everyone happy, but should be great of support to cult and optionally support innovative. This will come up with the cost by exchanging so we can find by using identity anymore. So if the durability mode is on, this means we have to every user has to change new signature keys over then I will channel yes, yes,.

N

Maybe it's too early to discuss this, but just stop! Oh sorry! Yes, your I've been complaining about people not doing that, because I can't note it down so you're, absolutely right, I'm the demco DC from INRIA. So on the previous slide you mentioned versioning and I am afraid it might be too early to discuss this, but we should probably just have it in our minds, so there's versioning, which is good, but at the same time we seem to be adopting versioning and cipher suites at the same time in the protocol, because we have versioning.

N

But at the same time we also have curve two five, five one nine and p25 six and we can choose between the two as my understanding correct in the Congrats. Yes, so it seems that it might be wise to attempt to limit the amount of state malleability and maybe only rely on versioning in terms of which ciphers are adopted instead of having both versioning and also within the same version. The ability to switch between multiple ciphers, especially because, for example, curve, 255 or nine does not require input. Validation for diffie-hellman, while P 256 does.

I

I generate I'll, be with you the problem with this. Some application widely deployed in different devices and some device has different Hardware implementation. People fear like some different crypto limitations, but I generally generally, if I don't know Erica something to say, I.

G

Was gonna say this is probably not the time to discuss this point. Yeah.

B

We haven't discussed yeah, agility or krypter krypter primitives, yet so yeah just save this for later.

I

It's too early to ask I will do with this omission. Okay. Next one beats. Oh ok, security consideration. It's a good, bad and ugly, so delivery service compromise. This should be good because the server should not be able to decrypt or access any of the messages. However, it can try to modify or alter the message, but the protocol should be able to take this and, of course, you can always do gos attacks.

I

Okay, the bad education service compromise. This will can return, because this is there because it can return in credential. This will allow impersonations and can only be defeated by the guy, who is going to ask the biggest questions or transparency logging, which is a key transparency. The obvious client cover wise, because the attacker can actually read and read accusing message and send receive messages. However, it should not be able to do is the server old peers and this would be defeated once the key material is updated.

I

I give this my last thing so that question do go ahead. Yeah.

F

So this is TKG Union, so this is description of what we expect the attacker to be able to do right, but my understanding is that this draft does not attempt to define the actual delivery service mechanism or the authentication service mechanism. Is that right or do we also intend to define a specific education service mechanism, or do we just say, I think as as the earlier slide deck said, clean interface goes here, you know figure it out. For yourself, are we trying to actually specify what that interface is? I? Think.

I

At least for the authentication service, it's out with :, which will all deliver service which I'm writing this.

E

Yeah I think that's right. You cagey, um we are trying to I think this dog was trying to capture a high-level description of the universe of possibilities. When we get to specification, we won't try and specify the all the parts of that universe will need it that, as you said, the technical, clean interface to the authentication, part and I think is Gary is probably gonna say we might highlight the need for certain other mechanisms, in addition to just an authentication service. So.

F

But just to be clear, what we're saying is: there's a delivery mechanism, which is our hand-wavy cloud thing. Yeah.

O

Yeah and there's an authentication.

F

Mechanism, which is our hand, wavey cloud picture and then we're gonna define the rest of it. Yes,.

G

J

Belvin is under a delivery service. Compromise is the server able to change group memberships. It.

I

Can but it should be detected by the client the same way. It can reorder the message, but the client should be able to take this okay.

I

Any other questions, okay time for the protocol.

C

You guys are excellent on your time management skills 22 seconds before.

P

Cool the hi I'm John Milliken I lead security, first secret conversations on Facebook Messenger, so I'm just gonna cover the sir. Oh sorry, so I'm gonna cover the draft protocol. That's sort of we've published so far. So it's like please.

P

So this protocol is based around something called asynchronous ratcheting trees and the idea is that every participants in the conversation will have some view of this tree which their cache client site and then they're a series of operations which essentially mutate mutate the tree and thus mutate to the overall conversation state and so we'll go into these in more depth. But these are some fairly obvious ones: creating groups adding users updating keys less obvious, but this is for the forward secrecy and post compromised security and, of course, removing people from conversations it's like.

P

So the asynchronous ratcheting tree is a primitive that we described last year. So the idea here is that you have a diffi Hellman binary key tree, allowing updates to it or most mutations to take place in logarithmic time so long as it's roughly balanced.

P

The tree can be manipulated, asynchronously and we've actually proven the confidential confidentiality of group keys just for static routes. So far, so there is more work to be done on this, but it we have enough proofs to be fairly confident that hits a roughly solid, primitive and so in MLS we draft so far, we've taken it a bit further.

P

So we've constrained the story structure a little more we've added support for dynamic groups, so that you can add and remove members and we've sort of tried to look a little at race conditions, although that's fairly embryonic work at the moment. Next slide, please so to just give some intuition about how this works. It's essentially the fact that you can derive a different key pair from some random string. So as the output opport iffy Hellman key exchange is a random string, you can use that to form a different key.

P

So the example we've given here is just taking a hash of a diffie-hellman outputs and treating that as a curve, 2 4, 5 or 9 private key.

P

The key derivation may differ depending on what primitives you actually use, but that's enough for us to be fairly confident that it's feasible as a technique, and this means that both key holders will know this shared key, and thus you can use it recursively next slide, please, and just to clarify some terminology here, just to remind you from from their original drafts.

P

So with respect to C here, we've highlighted the direct path, which is just the sequence of ancestors, from C up to the root key, the root being the one node which has no no ancestors the root by the way is used as to provide the group secret, which is used for protocol keying material. The co path is, then the sequence of siblings, of the path.

P

Apart from the root, of course, which has no sibling so for C. Here this is D a B and D F G H. Then we also have the frontier of a tree, and the idea here is that to add someone to a tree, you need to actually add a new node and what you need to compute their path up. The tree is their their key itself and their co path, and so the frontier provides the co path for a hypothetical new node that will be added. That may be added at some point in the future.

P

So please, and so the idea is.

P

This is really fairly familiar to anyone who knows the signal protocol idea that we have our keying material coming from the tree and some existing group secret and every time when you take the tree, we KDF that in with the original keying material, so we're able to sort of have a chain of material, a chain of keys, taking in the secret data known only to the people from the tree and the secret nature known only to people who were already in the group allowing a sequence of mutations, and we sort of turned these as epochs within our drafts, so to dive into the operations which we've defined and I start with operation zero, which we actually haven't defined.

P

So creating a group given a list of members that there is probably an option to create this directly. But in the draft so far, we've essentially treated this as initially starting with a single leaf and composing a series of ads in the paper. We actually do define how to create a group directly, so this should be fairly easy to implement into the drafts and there are performance reasons to do it that way, but either way we have something which should work in theory.

P

Next slide. Please so next option is that what we call the group initiated ad? This is the operation whereby someone within the group wants to add someone else, and so what we need here is what we call the user init key. These are also may be familiar to some of you as pre keys, as termed in the signal protocol.

P

So the idea being a list of pre-published keys that can be used to add someone to the group, and so the group can perform a a key exchange between that key of the new party and an ad which is known to the members in the group derived from the current epoch state and thus using the frontier and the, and these two keys derive a new leaf and thus compute that leaves path and subsequently the the new root.

P

We should note here that there are actually implications with this particular approach, because it does mean that everyone in the group will know the private key for this new member at the point that they add they adjoin.

P

We do have thoughts on how to improve this situation, particularly using an add key that is only known to the person, adding that the new member, rather than known to the whole group, but this slide represents the drafts as they exist today.

P

It's like so the next operation is the user initiated at so this is motivated by use cases such as conversation invitation links. So, where I want to add you to the group but I, don't necessarily have your account in the service, so I just send you a link which allows you to add yourself to the group, and what we have here is another difficulty known to the whole group. This is actually the same.

P

Add key that we had before sorry, ok, which the witch kept which camp can be used to initiate this new person into the group, and then they can use the the published frontier of the group as their new Co path to compute the new state of the tree and then publish that, and in this instance they have to publish their entire path. No.

J

Gary bobbin two questions on. Does this also cover the use case, I of the situation when a user say reinstalls an application? Yes, depending.

P

On the application that could be done with either of these methods.

E

In fact, the the concrete reason why this got added to the protocol was I was trying to implement this. In the context of missing you gap, it was like Waldo, I do and I get a new device, so yeah, that's the same thing. So it is you pre, publish this group in it key that represents the group state for new potential new users and then, when someone new pops up the wants to join the group, they just download that and initiate themselves into the group. Now. There's authorization concerns around that and.

J

One one point of clarification: that means that the group init key is public. Yes,.

P

And whether the application chooses to use this feature can be down to the can be application. Specific okay next slide, please. So the next point is just updating your own key, so not mutating the people within the group, but just updating your owns secrets so that we can get post compromised security, and so this is very similar to the previous operations, but involves changing your own leaf, probably a new random value and then calculating your new paths and publishing that path.

P

This is approach to confident confidentiality. It's proven within our paper on a RT, because updating a key doesn't involve dynamic group membership.

P

So the next part is removing a user. There is a lot of nuance involved in this, but fundamentally it is possible to simply issue what's effectively update operation for someone else in the group to a key that they do not know, publish that new path, and then at that point they cannot compute the root of the tree because they do not have leaf or a private leaf key and thus are locked out of the group. Of course, publishing a new key for somebody else now means that you know their key in the tree.

P

So there is nuance- and we address this a bit further within the drafts. But hopefully this is enough to give intuition of roughly how that works.

P

Okay, so some of the open issues we do need to prove the property, the security properties of this evolved protocol. It is significantly updated from art, as in the paper, so the hobby lots of fun work for the academics in the room.

P

There are a lot of logistical details, particularly with removing people from the group, as I mentioned. We really don't want situations where somebody knows other private keys in the group, as it makes it very difficult to then remove them from the group. So we need to iron out exactly how that should work message. Sequencing is obviously a fairly big issue, because we need to make sure that's conflicting updates to the tree, don't kind of cause split in the state and, of course, message, protection, authentication, transcripts integrity.

P

The current authentication scheme in the paper is pretty similar. We need to elaborate, particularly with respect to deniability, with many asterisks, as mentioned in the previous talks, and we also may want to include some discussion of how attachment should work as typically. These are not sense within the core messaging protocol, but centers references to some attachment stored elsewhere.

J

Carrie, sorry for other questions, could you go other console, I'd yeah, um just so we're all on the same page I we do want to achieve transcript integrity. Is that right, uh I think that's a case of maybe.

P

Ya know undecided, yet maybe a property that some people want. Phil.

D

Han Baker, as thinking through so we're calculating this group based on the long term, public keys of the participants know.

P

So these leaf keys can be rotated via this update operation. So we would expect some authentication to be routed with the long term keys, but the keys within the tree would not leave the long-term ones. Okay,.

D

So where does that so that's a transaction you're not.

P

Shown or I was it's a transaction that wasn't shown in these slides, okay,.

D

Yeah cuz I was just thinking about a class of attack where I create a per second group. This is similar to the first, but not quite and then manipulate yeah I know there are ways that we can play that game. Yeah yeah.

E

So, just to clarify I'm Phil's question of what keys we expect participants to have. We assume that there's basically two key pairs per participant, there's an identity key pair. That's long lived in used for authentication and there is a leaf key pair which is used to contribute to the group key for confidentiality, which is short lives. It changes whenever you send an update message for pcs.

Q

A question I couldn't really quickly see this from the draft, but Karthik Raghavan indriya. So the question is I'm. Assuming that people will be members of multiple groups, so can they reuse their same identity key in different trees, the same diffie-hellman keys in different trees? How does that work so.

P

Identity keys, we would probably expect to be kind of universal. Of course they come patience. This is what you would store and authenticate by the authentication service or key transparency, the leaf keys within the conversation. We were thinking of being different for different conversations. If we wanted them to be the same I'm sure that would be a fun challenge for you to approve security properties of apps, but we're not assuming.

R

Hi Matthew Hobson from metrics talk. Why would you discuss attachments here at all and failing to understand why MLS would have any opinionated position on attachments I.

E

Mean much like message: protection, it's kind of I agree. It's kind of a separable thing is you'll know the current draft doesn't discuss message protection at all because it seems like you know, once you've got a group key, you know, use any message.

E

Get encapsulation schemee, like I, think the idea was in order to get a reasonably complete functioning here when we were chatting among the folks who had apps, everyone had done some sort of attachment scheme because we all have you know, constraints on the messaging plane, and so the thought was it might make sense to take a look at clarifying. That's we could have some analysis or basically well.

E

It did say let's much like the rest of this: let's do it in a common way, so we can potentially have some common code and some common analysis yeah.

G

Ericka's crawler being just a labrum that I think the sense was that, as Richard said, it was relatively straightforward once hit a shared key to build a messaging app. But that then, if you wanted to have attachments um that was not, as a movie straightforward how to build that and that people had sometimes built in ways that were not optimal. And so that therefore, were describing how to build. It was probably a contribution and.

P

Also, introducing these references can potentially add subtle, bugs that may be non-obvious, so it's helpful to prove the security that.

S

Untoned I know from Microsoft Research. Can you clarify why you you try to fire? Sixth, so my understanding is in your tree. You are constructing a different habit, exponent from public exponents and essentially you are using sha-256 to do that. That's.

P

The example the slides so I.

S

Mean the question is really: why are you considered using CFR, she recommended.

C

It's definitely farther down the path. Okay slide.

S

That tried to five six.

P

It fits nicely into a slide.

E

That was definitely a placeholder thing and I think needs a lot more analysis. Thanks.

T

So what anger I'm vacation question Missy is the so you said that we can add. Remove people from the group is the consensus of months, the group that this person has been added or removed a part of this protocol, or is it like outside the scope of this.

P

So people should the idea is that everyone should know who's in the group. So so that's an app level constraint, but in the protocol I.

G

Think when we talked about this, the idea was that the system should support effectively any cryptographically, any single person evicting any other person and the question of who is allowed to evict, because the most flexible line and there's an is question of who is allowed to evict, was an application question that we set up by some sir authentication actually control thing.

M

Yeah that might well, my worries, is you know, like you evict somebody from the group and some other member is offline and doesn't find out about it. I mean. Does that and then does that now block somebody else from adjoining the group until you manage to reach that person or what happens so.

P

In in theory, this general operations should be asynchronous, so you should be able to just have a list of operations which, when someone comes online, they fetch them and they are able to update themselves to the new state at the group. Okay, in terms of two people doing conflicting operation same time, based on kind of based based on the same state, doing different things. That's sort of an open issue, yeah.

M

I mean I think if you've got fifty thousand people in the group, you've got to have things happening. At the same time,.

J

This might be appropriate for a little bit later but time it just occurred to me that the that the size of the tree only grows over time. Is that correct? Yes, so.

P

We justify that sort of with removing people never makes anything worse. All it means is that the tree is not quite as optimal as it could be, for the new set of members can.

L

You rebalance Ben Schwartz. Can you rebalance a tree that contains zombies, maybe.

P

Yeah, so we hope you haven't looked into rebalancing operations. It's probably that the most obvious way to do that would be to just reuse blank spots when you add new people, but we could potentially look into rebalancing operations if this is a operational concern, so.

L

Specifically, I mean participants who have not removed themselves, but who are unresponsive? Oh.

P

So we did discuss it, I, don't know if it reached the drafts actually, but.

N

E

Oh repeat for an idiom yeah, as you may know, that there's the there- that is an explicit concern we need to address here, is having long term unresponsive nodes and we need to have a way for the server to a victim.

L

So Ben Schwartz I think my my concern here is that it's not just about evicting them, but if, if you have a longer fiction timeline, as noted before, then, if you can't rebalance the tree until you've evicted all unresponsive nodes, then you may never be able to rebalance the tree.

E

So the word rebalance is a little odd here, because the trees that we're using here to keep the math simple, have a fixed structure for the number of leaves, following on the CTE use the same math as a certificate transparency.

E

So there's not really rebalancing going on, but whether a leaf is occupied or not at a given time.

L

Okay, then then, does this create a scalability problem? Does this mean that I have to use size, large trees for all groups of all sizes.

P

So it does mean that if at one point your tree contained 50,000 people and now it and after some sequence of removals, it now only contains two. Then you've got a pairwise group with the tree depth of 16, which we I mean tree. Depth of 16 is still computationally feasible and most situations, but it is suboptimal and we basically consider that it's a fairly unlikely scenario to be I do but.

C

Also because this isn't a fully big protocol, something the working group would decide and discuss about in gonna be point these out, but doing it on the fly, engineering and now's- probably not really a good use of our time. Yeah.

D

I I can believe that the math will work for a group of 50,000 I have I I. Do not think that you can have a messaging group of 50,000 participants. I mean you you, your system is gonna fall apart for other reasons before that is reached, so I I wouldn't be okay. Thanks, don't note it.

U

Is it in scope to be thinking about our bank a duck? Sorry! Is it in scope to think about the forward secrecy of messages generated by a client that is offline racing with removal from the group so that you know the generated messages would be generated to a key that is known by the member that is getting deleted.

U

So and I feel free to tell me that's out of scope for right now. I.

P

Think, probably out of scope, at least so far as now and I. Think I think it's reasonable to consider that if a client, if a client, believes that someone is in the group at the time, it sends a message. It is reasonable for that person to receive the message, but that's probably a sort of fine point to discuss later eius.

B

Goes back to transcript integrity, yeah.

E

I think what I would say is that it is definitely in scope for the architecture document to have to have a very clear crisp, detailed description of the security properties, but he's probably going to hit some of what you're talking about yeah.

P

V

So half of us used orange and half of us used green, so apologies to your retinas, so I'm cat, Rio I'm from Oxford I'm, basically here to say hi I am an academic. So far, there's a few of us around we're interested in working on this. It seemed to work pretty well for TLS right, so we hope we can do similar sorts of things. However, since I don't very often get to represent all academics ever at the IETF I'd also like to say, let's see, Julie fee was great. Mls visibility draft is coming soon.

V

You see, I can say that because I'm only a student.

V

That was a joke.

V

So yes, so there's a few researchers and academics involved in the working group either on the mailing list coming to meetings and so on. Many of them are here. So please come talk to us.

V

There's a fair amount of experience, so Karthik you already heard from if you are outside this morning afternoon, works on TLS Kass, who is my supervisor also worked on the TLS analysis, Benjamin who's sitting there F star NFS, so we have some experience looking at protocols, although there's a bunch of new and interesting challenges in the messaging context that you've heard about that, we look forward to looking at if is related to project. Like my PLA life, 1.3 work, the 5g work, my fellow student Martin was working on and so on.

V

Next slide, please right so just to give you an update on what an alpha they've been so far, so John put up a link to the end-to-end encryption paper which we wrote a few months ago and that really defines the ratcheting 3 primitives that you've got an intuition for. So if you want more formal definitions that, if you enjoy reading conference paper formats, you can check their write in that paper, we spend a fair amount of time, looking at security properties and looking at them fairly formally.

V

So this is capturing secrecy and authentication of messages in mathematical, cryptographic, proof, pen and paper way and is also we define properties like agreement on members, those we punt on a little bit, but I can talk about that offline, and the other thing to say here is that we have a fairly good understanding of what post compromised security means in a formal sense, and so we do indeed define post compromised security for the protocols in the paper.

V

I guess the takeaway, for that is that the ratcheting tree construction itself is relatively new, but we've already started to analyze. It there's plenty more to do so a little bit more about what we actually did.

V

We did to sort of separate things so there's a key tool you can think of as it were, which is the ratcheting trees and the first thing we did is we abstracted away from the concerns that people here will really be interested in things like message formats, dynamic groups, how you add people what exactly it means to add people, how you deal with race conditions and so on. We abstracted away from that a little bit and just looked at the core cryptographic primitive.

V

This is unauthenticated for now, and we gave pen and paper cryptographic proof which is a security reduction, so we would use for security of that to the diffie-hellman a function. This is a fairly standard proof technique that it has its pros and it's cons, but that's what we did and that's really looking at the core ratcheting trees. Of course, that's not nearly enough. If you actually want this to be secure or usable, you also need to make guarantees like if I remove somebody from a group and then send a message. They didn't get it.

V

If the group has people added to it, then you have forward secrecy in the way if you are hearing about earlier. So the other thing we've started to look at- and this is very early- work is doing symbolic analysis using mechanized tools, so we looked using the tamarind mover, but I hear there was also probe arif work happening, perhaps even right now, depending what's on that computer screen next slide, please.

V

So what do we want to contribute going forward? We have some formal definitions of fairly low level properties, we're going to want to provide very precise definitions of all the properties you saw earlier and if includes things like, if you have a state recovery mechanism for I dropped, my phone in the toilet, but honestly I really want to be in this group. Please put me back in the interaction of that with confidentiality is subtle, but we think you can express it. You'll want something like well.

V

You got told that this person is claiming that they have lost their device. You can deal with that as you will, but we can encode that into a formal property we one. We ideally want the properties here to be fairly general. We don't want to hard-code. This is how whatsapp would use it, but again that should be fine.

V

Then, of course, after specifying the properties, you want to verify that, whatever system, if system ends up being designed, whatever system gets designed, actually meets them.

V

That means also low-level proof if there are any significant changes to the ratcheting tree mechanism and then looking at the protocol level, looking at things like proving authentication, making sure that only people in the group can add can add to the group, if you want that or only authorized, people can be added looking more at the threat model, where somebody in the group is malicious, which has a lot of subtleties, but we think you have some guarantees and looking at proofs for the dynamic group case, I hear this this magic tool that lets you write, verified implementations and it just works.

V

So hopefully that will be an easy addendum to all of this as well. Next, like this, that's about it so really I, don't have much to say at the moment other than we're interested in analyzing things. We hope to follow the TLS process, so we hope that drafts will be posted. That we'll be able to pick one make some comments, maybe make some comments for help and help the protocol analysis and yeah we're working on it and we're still going.

Q

Berlin India, so one thing I'd like to mention here is that I mean things like post compromised security and forward security, its forward secrecy and so on are properties that sort of this part of protocol proofs and protocol verifications. We understand them quite well, so we state them, but they may actually not be the most intuitive ways in which application developers and the people are actually going to use MLS may want to think about the security goals.

Q

So this is a call-out everybody in the room that if you have an intuitive notion of what are the goals that you would like state those and we can figure out how to code them in terms of these highly technical definitions which are useful for us, but maybe not may not be so intuitive everybody.

Q

V

Is particularly true in the group context where, if you're very used one to one messaging or one to one communications like TLS, it turns out there's a whole lot of other funny properties. The pop up when you're worrying about say three people in a group a simple example: there is, if you have a shared key with one other person, then if you get a message encrypted under that key, you know they sent it.

V

If you have a shared key with two people and you get a message encrypted under that key, you don't know who sent it.

G

Crow Ferrer is much better than tamarind.

V

Pepper, if, if you fall in some limited scenarios,.

B

Okay, before we get to the charter text, I'd like to ask a few questions just to get a sense of the room. So how many people here have read the protocol draft.

B

How about the architecture draft.

B

How many people have read the formal analysis paper more than you would expect? Well well done, okay and of people who are working on messaging, apps, who's interested in implementing the protocol or a derivation of the protocol, as as written.

B

Quite a few people yeah, um so some of the people who have raised their hands if you're, if you're willing to go up to the mic line and state what messaging app you're working on the.

C

Only caveat is obviously this does not mean that you will absolutely positively do it any time soon pieces that you're working on right.

B

This is to express interest and to express interest relative to a specific application.

I

And affiliation so I mean I, don't wanna again: I intend encryption for Allah and there will in Google so I'm. Definitely looking for something like this to ligament.

W

Jonathan Rosenberg with Cisco and we're looking at this for Cisco spark.

F

This is Eric rajala.

F

Sorry this is Daniel Gilmore I work on an email application, which is my preferred email, client, which is called not much, and if this can work in an email, client I will try to put it in the email, client.

J

Gary Belvin I work at Google I work with emod I'm working on an open-source authentication protocol called key transparency, which I hope would be useful to this.

R

Matthew Hobson again from matrix to oak I, think we were one of the prior art mentioned on Richard slides. Thank you on the ohm and Meghan ratchets that we did encrypt so is pluggable in matrix as a decentralized communications protocol, I, guess addressing a similar problem, but the next layer up the stack at the application level and is certainly interested in MLS as a successor to the army mecca and stuff we're doing today.

R

Hello, I'm, David, land and I work for a company called shore line, but I also have another hat and so I also work for the for the XMPP stands Foundation and there's substantially interest in and wind cryptography. There. Oh.

P

It's me again: John and John Milliken from Facebook we're interested in this for secret conversations in messenger and there's a one of the names on there as on that list is from what Seth they are also potentially interested in this.

S

Hi, my name is Rafa Robert and network for wire and we're interested in continuing the work on this with go to integrate it into the product. At some point,.

D

Johan Baker Komodo security solutions, yeah we're also interested in it. We have a client.

B

Is anybody on the jabber well commented with respect to this.

N

I'd also like to the grant so I'm Nadeem Cove, a CI responsible for cryptic at but I'm also I've been working on this on secure messaging for eight or nine years. This is something that has grown from like a niche experimental thing to affecting the most immediate way that billions of people communicate. We need a standard on this. We need something open. We need something that can be absolved of any sort of human notion on whether we get to implement it or not. To me, this is existential and I would like to see it happen.

N

This is extremely important and as human beings, we should be doing this in an open, standardized way.

N

Cryptic ad doesn't matter anymore.

X

So we got the errand cred from a jabber room thing I'm here from what's up, and we are also interested in this okay, so double confirmation.

C

That's to all the people that the reception that they said well, we try this before and it didn't work who's here all right. So now we're ready for some I charted the Charter that was posted to list. There happened some comments and they've been amended. It's at least four slides and sixteen point five. So as we walk through this.

Y

B

Well, we will read it through and if there are specific comments, we want to be very clear as to what the correct charter text is and whether or not there are questions okay, so the first one. So several internet applications have a need for group key establishment and message protection protection protocols with the following properties. Asynchronicity keys can be established without any two participants being online at the same time forward secrecy. Full compromise of a node at a point in time does not reveal past root, keys, post, compromised security.

B

Full compromise of a node at a point in time does not reveal future Group group keys membership authentication each participant can verify the set of members in the group message. Authentication each message has an authenticated sender, scalability resource requirements that have a good scaling that have good scaling in the size of the group, preferably sublinear.

B

There nope are there any comments on or questions about this first line of the Charter.

M

Can you bring it up again? This is a terrible quibble, but the your bullet points aren't parallel construction.

M

Well all, but the last one are sentences. The last one is a phrase: I felt.

B

That when I was reading, it.

S

Can you further Slayer again Otto and Elena from Microsoft Research seems to be a big problem in that's in that slide, I, don't see where you actually state that the messages have to be confidential and not revealed to anyone outside the group.

S

G

Easier this way, though, don't you think I.

S

Saw as Tony says that the Charter is changed to include confidentiality of messages, in particular with latest discussion in the quake and TLS working group.

B

Will note no later than will we'll see if we can amend this with confidentiality, which seems like an obvious good property.

L

And Schwartz this is, this is definitely equivalent of a node does not reveal future group keys works for some definition of fault compromise that is read-only. If you can modify the client, then you can have it tell you everything in the future. Is that your your definition of full compromises a little weaker than mine,.

B

Sure yeah, this should be clear who should be clear that this is full compromise of the cryptographic components that make up the the identity rather than the application itself. That I.

Z

Think that could could be a little clearer, okay.

Z

Goons message: authentication: does that mean that if this isn't the the Charter that deniability will not be something we work on? No, we still can work on deniability, okay, yeah.

G

So the concrete property you want is that members of the group, no, um which other member of the group set the message that does not necessarily mean they can prove to a third party who sent it, um though it might mean that it's a subset of that.

U

Benkei Nook wearing the ghost of my ace working group, chair hat, so the text up here at the top about new group, key establishment and message protection is perhaps more general mark than you want in that over an ace. We've had some very contentious discussions about keying for a groupie establishment for IOT messaging, which I assume you do not want to bring here. The.

C

Late later paragraphs tighten it down so I when I read this, it's like Internet applications, groupie management and then the next set of paragraphs is like for messaging on Phil.

D

Home baker, the men, bishop authentication I'm pretty sure that if I have a group, that's larger than a thousand people I'll be wanting to keep the group membership confidential. So I'm not sure that that is actually a requirement. That is a feature of the protocol architecture you chosen rather than something that everybody is always going to require. ah The other thing I'm a bit concerned about is: if we don't actually do any form of Interop testing.

D

How do we actually know that protocols that say that they're doing MLS actually are doing MLS, and we may well have an issue with somebody not doing it right and then having the protocol tainted by their incompetence.

C

Problems later they could test to also implementations. Well, have them to test the apps. It can be done. :.

AA

Genesis, just because there's a charter, she I think we do have applications where we're interested in very large video conferences that where the the group of people is known, so I think there's you know well I think there's a but use cases. Both ways to fill soft I said.

E

We're gonna will far afield but to Phil's point about interrupt testing. I would say you you would do MLS and are out testing like you do TLS in are out testing. It's not it's tied to a given transfer, you're gonna to us in our testing over TCP, and you know you'll verify you can pass some data over it, but what you're really testing out is that is the key negotiation in encryption.

E

I think I would expect that the MLS sex would be able to interrupt in the same way when you, where you can generate messages that generate the negotiate, keys and verify that they negotiate the same keys.

D

What I'm getting at is that we may need to have some draft that tells you how to dump out the in drop stuff just that we can do it and we shouldn't hardwire the charters to say that we can't do that.

C

Alright, thank you for taking notes, whoever's taking note, so we can put the second here's slide to several widely deployed. Applications have developed their own protocols to meet these needs. All these protocols are similar note. You are close enough to interoperate. As a result, each application vendor has had to maintain their own protocol stack, can independently build trust and the quality of the protocol. The primary goal of this working groups develop a standard messaging security protocol so that applications can share code and so that there could be shared validation of the protocol cuz.

C

It was with TLS before 3. It is not a goal. This group to enable interoperability between messaging applications beyond the key establishment, authentication confidentiality services, so our ability would require alignment in many different layers. Beyond security example, standard message, transport, an application semantics, the focuses as work is to develop a messaging security layer, that is, that different applications can adapt to their own needs.

B

My comment is that there's double spaces and single spaces mixed together, I.

C

Had probably introduced that all right, so I'll just read the next one too and developing this protocol, we will draw the lessons learn from several prior message-oriented security protocols, in addition to the proprietary messaging security protocols deployed within existing applications. Some of these include s/mime, open, PGP, off-the-record and signal. The intent of this working group is to follow the pattern of TLS 1.3, a specification, implementation and verification proceeding in parallel by the time we arrive at RFC. We hope to have several interoperable implementations, as well as a third thorough security analysis.

C

The specifications developed by this working group will be based on pre, standardized implementation and the deployment experience and generalized and generalizing the design described in draft Amara and draft Barnes I.

C

Think we're gonna put this on github and then we can have it out.

C

Finally, note the consensus is required both for changes to the current protocol mechanism and retention of current mechanisms in particular, because something is in the initial document set does not apply. There is a consensus around the future or around how it is specified and then the milestones which are pure bull.

C

So it's you know. May 2018, for the initial architecture to the official group documents to adopt the messaging protocol mean if we're gonna do what we did in TLS and build in like delay for the researchers to parent their tamarin proofs I normally slip all these dates to the right. All the 2019 days to the right by 6 months, if we're gonna add at a.

O

C

For this security, guys we're gonna add another six months to that right, because I think it's it's only fair that we get the protocol done and they find something we're gonna have to change it, and so the first Mountains are find.

G

In fact, the first miles that the protocols was really fine right, it's the 29 teams, also DSR, are like science fiction, so I mean I would I would just like something's to like you know, one one, twenty and call it a day.

C

Think about picking these dates is there almost you watch it opens that we start to get nasty grams from our ad or from the data tracking Center to say, update these things up these things. So we can, if everyone's basically kind of happy with the first two I, think we're okay and then the last three will just add a year plus I.

G

Would just just negotiate those with your director I think you can find him so otherwise this looks pretty good. That's you.

AB

Ben Campbell I, think I know the answer to this. Just to clarify, when you said the milestones, were you met just the dates and stuff on the right sides? Okay, right! Yes, just the dates and.

E

I appreciate the grammar fixes pointed out by people in the audience. This is in a Google Doc that wasn't, you know linked to the mailing list a few weeks ago. So I would really appreciate edits. I think.

C

That uh Nick, Nick and I'll get together and throw up pick it up or we can start dumping stuff up there so that you guys can edit it all right. Scoping questions.

B

Okay, so we have a couple questions here about the scope and we wanted to make sure that folks in the room are generally in agreement about several questions. So first of which is, does the scope sound, reasonable.

AC

B

Anybody in the room think that the scope that had was laid out was is not reasonable if so get up to the mic.

F

B

F

Gene again, all of the discussion that we've had here has been about the key management and slipped into the Charter is about message, protection and so I just want to I want people to be conscious of the fact that we seem to be charting ourselves to do another message, protection document or set of document or work within the IETF.

F

We have to already open PGP messages and content the cryptographic message syntax. It sounds to me like we're kind of talking about a third and all of the presentation and all the interesting discussion that we just had didn't really mention it. We just kind of slipped it in at the end.

G

So I don't know other people think speaking for myself, I've been assuming that this would reuse one of the existing formats, kaze, Jose or Jose or whatever already have, but that what that what like, if you look at the you think about their relationship between um you, know, Jose and caught right, where Jose is I'm, sorry, Jose and caught where Jose is like a you know, the generic message protocol and then Conte specifies he says the that has to appear into it.

G

There's certain things that have to appear in here to make like they think were quite cute and a Fire's and and and maybe like sequence, numbers and stuff, like that and I think I, would think, was effectively a profile of one those things um that maybe.

O

G

Doesn't fit that that's what I have might in my head, um I I, don't know um I, guess I would my presumption would be think that that's I guess I would like maybe there's some situation in which that's not appropriate I'm something they working would have that flexibility, make it a different decision, um but so.

E

I I actually had a slightly different expectation when I could just to describe I I was envisioning message, protection to be something like the TLS record layer, the TLS ciphertext structs, because this is a rather more limited context where there is everything is pre negotiators I, don't need all the indications that you might need in and say, jwe or comparable Jose or cozy objects, so I think but I think that's about the universe of things we're talking about either reusing something if what we need is simple enough, defining something lightweight.

E

That makes sense only in the context of this protocol or reusing something generic. If that makes sense, that's I realize it's a little wishy-washy yeah, that's what the Charter the Charter says.

E

B

So this point goes back to the dkg at the very last line. The Charter is what your questions about right.

W

W

Yeah, okay yeah, so if I, if I may sort of beg to differ on that actually and Jonathan Rosenberg, so this sort of interesting protocol we're defining that it's not actually meant to provide interoperability across different vendors products. So I see like I mean what would be the point of specifying the actual message protection technique. This was never meant interoperate. In my view.

W

The main objective here is: you know it is to provide something that has a correctness capability and that's it, and so that we can say it works and we can do some testing against the test. Shim with some implementations. Just to make sure it is. Yours is correct, but besides that, like none of these things are planning to operate and so I think we should do the minimal amount that delivers correctness and no more.

E

No I certainly agree that correctness and having verifiable security properties are the targets here, but I think to Phil's point from earlier in order to really verify that we have something interoperable but I think we need a syntax so that we can test around something, and maybe maybe we can plug into JW.

E

Yeah, let me frame this differently, I think, in order to get something that is sufficiently detailed, that we can verify security, probably the security properties were going to want to verify authenticity, transcript integrity, etc. We're going to need to specify this whole you, you would need to say the message protection forum endless provide this and this and this and this and this at which point you might as well define a syntax. Does those things.

D

Phil Han Baker I I disagreed that I I I think that we can have the output of the Interop. Honest simply be the key values that you're going to use, because you know the output of this is ultimately going to be a master secret that changes with state changes to the tree of members. The reason that I would like to keep this out of this group is that the obvious next standard process, which will be an app's process, will be to propose a standard messaging format. I mean you know. We are our standards body.

D

The internet needs an interoperable messaging platform, that's based on an open standard that anybody can set up a server that works like SMTP, and that is something that the ITF should be doing. But the fact that we have this group doing key negotiation shouldn't block the apps area from doing that part of the task and the fact that vendors would rather, we didn't, come to an open standard shouldn't, stop that either.

G

So I guess I'm gonna disagree with claim that all we need is the key values. um If you want to provide treasure integrity- and you want to provide you know, um group integrity, you're gonna need to stand up, standardize, I, specifically the contents, the messages and so like. If people really feel like, they don't want to specify whether it's cozy or josé or CMS, like you know, I can III guess we get to find an abstract description of what the messages had to contain in the messages. Largely are a ad.

G

You know, AAT blocks containing some crap, um but, like I, think it is imperative that we did that this describe like what the property I mean so so show me a way to skin this is we? Do we describe this sort of abstract?

G

You know, um you know message which services animation service and similarly, you could say: well those abstract messaging service whose property is it takes a you know it takes a key and a bunch of metadata and you know a and and and some data and it spits out like a blob and then on the way in the door. It takes.

G

You know a key and a bunch of a bunch of a blob and spits out metadata and some data, and if people want to like do that, like that seems fine, that's gonna yeah, that's a minimum! Make the damn thing work and you know I mean. Is there like almost baffling?

G

You have to say that, because, like now you're just like okay, we're just gonna hit you we're just gonna like I, guess boy you now use like okay, I wanna cause a I wanna, you know see Bohr or JSON encode and like I, stopped it in an ad but like if that TV will feel like warmer I'm, like totally fine with that, but I think that's what has to happen.

R

Dave Cridland again and just an answer to well mostly Philip that part of the actor as well- and you know there is a there- is already an interoperable messaging system that was designed within the IETF, and you can set up your own well, several actually but yeah XMPP exists and the the getting of a message from one place to another is done and dealt with.

R

That's that's an easy, easy job and you can set up your own server and you can all of us the bits that the bits that the XMPP will me and proxying from that the apps world will meet guidance on is its is I, can tell you what what format the messages inside the encryption should be. I can tell you what format the messages outside the encryption should be.

R

I cannot tell you in what order to do the signing or the and the encryption, and nor would I try to tell you if you guys, if you guys all say well, you can negotiate all these keys and then you do rot13 or even double rot13 for extra security. That's fine! I'm, just gonna go along with that, but, on the other hand, I do know what needs to go inside the messages I do not do know what needs to go outside and how to transport them around the network.

AD

Yeah matthew, Miller I, think I'm, probably going to echo a few of these other ones. That I think we can find a boundary here on what we need to do that we can come up with interoperable implementations as long as we've got inputs and outputs that we can collapse into a way that we can do an interoperable test, I think will be I.

AD

Think will be okay for what we're looking at trying to do, and you know whether that is kaze Jose, whether it's we start with the tos structure and find some mapping that works for the testing framework. I. Think I think any of those are equally valid at this point. At this point, in fact, I think this is almost worth just punting a little bit further on and just saying we will work on something.

B

So the sense of the room I'm getting is that there's not a demand to define a message: syntax in the application sense, but potentially a definition of what the cipher text format would be.

AA

: joins a. It seems that we're debating almost a bike shed issue here, which is at the very bottom of our thing. We have some stuff that falls out into a container and we're talking about whether we need to define no container an abstract definition can depict container or point out that this maps to different containers and most of the people who set stood up at the mic ten minutes ago or I'll going to map this to different containers. Let's just leave this this working group.

AA

This has really changed the work in the Charter in any significant way, like LEM figure it out when that gets going, it's not gonna be a big deal, so I think we should just ignore this topic for the point of chartering that.

C

Was actually gonna be? My point was that you know if this was something that somebody really felt they were gonna fall on the sword for before you know getting up and chartering, they should get to the microphone and state their case, because I kind of felt like it wasn't that way. I.

W

Just want to be clear: I just want to be clear because I don't want to miss it. Jonathan Rosenberg I, don't want to miss it expectations or wrong working group members around different goals, I'm sort of hearing some people want to build interoperable messaging implementations, and that certainly requires you to do an extra layer of diligence. I mean even at the core. How you specify this thing when your goal is correctness and not interoperability at any layer of the system, is probably pretty different.

W

So while I'm not gonna like follow my sword on this particular topic like I, just want to make sure we're a line that the goal is correctness. Not interoperability and I saw interoperability in the Charter I.

AC

U

Benkei doc, this is somewhat overtaken by events, but it is possible to use phrasing like giving consideration to existing IETF technologies, including cozy, job CMS, etc.

B

Next question: okay: the next question is: are the security boundaries presented suitable for a security analysis and if somebody disagrees please step up to the mic or so did someone said it says? No, no I would.

G

Actually like that chair, so to take homes for these just so, we have them on the record. Okay, that's! Okay! All.

B

Right so let's do a home for this please so, okay, we're gonna have a home! For, yes, are the boundaries presented suitable, yes and then a home for no so I'll home. Now, for yes,.

B

Come now for no okay, I think that's pretty clear. Let's move to the next one!

B

This this is based on a question raised in the list and do we agree that the application layer interface is the correct place to enable visibility requirements? Should they exist? Yes,.

G

So I'm reading this as we're not gonna, do anything to name up visibility. Is that what that means? Yes,.

E

Yes, the set of parties that can decrypt a message is determined by the key management protocol as the membership of the group and there's no there's nothing. No provision for decrypting beyond that.

B

Let's do home for this as well, so yeah, let's changed the phrasing to what Richard said so own. The the the statement is only the members who are agreed upon within this protocol to be able to decrypt messages.

B

That's okay, I'll rephrase that um the only parties able to decrypt messages are the parties who are authorized by this protocol. You.

AA

Know we have a BCP that basically says this. Oh I'll do, or are we even discussing this one.

Z

Okay, Jonathan.

W

Rosenberg I'm, gonna sort of repeat my prior comment and like since we're not specifying a protocol if I want I could build like my application on top of it, that, like emails, the keys to everyone in the universe, I mean no one will use my app, but like okay like. Why do we even specifying this we're.

B

Specifying that it is at the application right here.

G

But I'm understanding what I'm, assuming is that the purpose of this Charter is to procore is, is to rule out a scope, say a say. An extension like the or HRD extension is presented on Monday. So is that what the 40 point is closes? Yes,.

E

Okay, so look: let's.

B

Have a home for this? um Yes, for the only parties to decrypt the messages are authorized, are the ones authorized to decrypt and we'll have a hum yes and then home now? So um yes for now and hum no.

M

AE

So Martin Thompson the we're, not bashing the words here, because this is an on statement.

AE

But we all understand right.

B

Yes, okay, so let's do the next one do the doc. So this is a question about whether or not the two documents, the two documents that most of the room has read, constitute a good starting point for a working group so home now. For yes,.

B

Humm now for no.

B

That's pretty clear and now the final question about should the ITF do the work is: is this proposal flexible enough for the common use cases of secure message, messaging applications, and are there any new clarifications on this and we'll go straight to the home so hum for yes,.

B

B

So it for the people who hum no is there? Do you want to make your case in that? This is not flexible enough to support the common use cases? Oh.

D

I have a bunch of use cases I think not going to be covered by this, but that's fine, because I think that we will discover them as we go through the the work and yeah. We will need more than one key agreement for multi-party communications.

D

The case where you don't know the other parties in the communication is a real one. The case where you have the communication controlled by one party is also real.

D

The week when you have n greater than two in the conversation you're going to have a lot more degrees of freedom and the idea that one set of requirements is going to fit absolutely every application is just not going to fit. So the statement is common, yeah use cases yeah. That's.

B

D

Cases I I I will agree that it is flexible enough for common use cases. But not if you put the definite article in there.

R

Is similar to Philip I? Think if you actually add one word into that, then it it will stand, but without that one word it will fail and I can give you lots of common messaging applications where this won't work. Mailing lists won't really work. The mailing list that we used in the ITF, for instance those aren't entirely uncommon. There are a number of other a number of other cases message boards anything along those lines, and these are all asynchronous messaging messaging applications.

R

So if you put in the word synchronous just before messaging, then you're you're covered. Oh.

R

Well, okay! Well, it depends on how you look at it if you, if, at any time your your messaging application, relies for its utility on the on access to historical information for people, then that fails now. Typically I describe those as you either have synchronous messaging applications in as much as you expect the other person to get the message you know in a timely manner or else is asynchronous where it's it's new. You expect people to look at messages out of order, and you know massively different massively different times.

R

D

As Jim Gettys said to me, this is pinball you when you get to play again so I'm saying that after we've done this one I think there's another game. We want to play I'm not saying block. This I'm saying bear in mind that this is not the only way of skinning this cat.

D

Okay, I think that makes things clear. I, don't.

E

Think we need to parse out it right here exactly the the set of use cases that are addressed, I think the critical question is: is there a compelling set of use cases that this addresses and for me, that answer is yes? Okay,.

B

So, let's let some for that, then is. Are there a set of compelling use cases for which this protocol is useful? Hum? Yes,.

B

Humm for now, okay, so I think that's that's a lot more clear. So.

G

This is not walk word but I'm just nitpicking. These are all great questions, but the one question you haven't asked is: should we form a working group in this area and hum since it says and sit hey? Oh I didn't see that those weren't there.

C

Okay, questions.

G

C

We kind of led you down the garden path here, a little bit on some of these, so the first one is, you know, is the problem sufficiently understood.

C

We've had a little bit of debate here there, but basically it kind of seems like people have got to the point where they're like we're: okay, so we're gonna have a home on that actual question. So please huh I'm gonna. Do it twice right, please hub now, if please come now, if you don't so, please hum now, if you think the problem statement, if the problem is sufficiently understood.

C

Please hum now, if you think the problem is not sufficiently understood. Okay, so that's clear, please hum now, if you think the problem is tractable.

C

Please hum now, if you think the problem is not tractable clear as well.

B

Okay, so the the third question is: is the ITF? That's the this in this case? Is this the right place to address the problem? um Yes,.

B

B

Okay, so this is these are not home questions, but can who is willing to author specifications.

B

Okay, great and.

C

B

The more important question so.

AF

B

More more important question is: who is willing to review specifications? Oh.

C

So I guess the real question is like do we think that this is a good enough thing to start a working group for so let's do a home for that. Please some now, if you think we should form a working group.

C

Be some now, if you don't, that was pretty darn clear, we're still gonna Bristow we're still going to work on the Charter text a little bit, obviously, but I think you're.

AF

C

More please so I can try to make my bag lighter. If your name's up on this list in yellow, please come up here.

G

So this you already got theirs and if they.

AF

G

Would I know you're.

AG

Worth your rockateur shirts.