Privacy Enhanced RTP Conferencing IETF 93 Session 2015-07-20 1300-1500: Congress Hall III Scribe: Sean Turner , Alan Jonhston Summary: * Chairs kicked off the first PERC meeting * WG discussed PERC requirements, WebRTC use cases and couple of solution framework documents. * Requirements document (draft-jones-perc-private-media-reqts-01) - is progressing in the right direction - might need more clarifications on scope of key management requirements. * WebRTC use cases document (draft-westerlund-perc-webrtc-use-case-00) - more discussion is needed on key management functionality approaches, specifically media path key management vs out-of-band key management. * Solution Framework documents (draft-jones-perc-private-media-framework-00 & draft-mattsson-perc-srtp-cloud-00) - There was an interest in using EKT to distribute SRTP master keys. - WG felt more discussion is needed on the scope of the Media Distribution Devices in terms of modifying aspects of RTP Header and RTCP messages. - EKT needs updating to reflect new extensions proposed in the framework documents * Proposal was made to move EKT to PERC from AVTCore since it fits naturally with the PERC requirements. Decision pending a better idea of PERC requirements. * Chairs to setup design team meetings to discuss the following items - Aspects of RTP/RTCP that can be modified by the MDD - Key management (generation, distribution, rekeying) approaches under various deployments (SIP, WebRTC ..) ------------------------------------------------------------ Raw notes (From Sean Turner) ------------------------------------------------------------ Chair Welcome Slides Chairs started with looking at milestones and proposed drafts. No agenda bashes required. draft-jones-perc-private-media-reqts Reviewed history of draft - it replaces draft-jones-avtcore-private-media-reqts-01. Roni: There are no requirements that address the KM map? Paul: Do we need an explicit requirement and what would it be? draft-westerlund-perc-webrtc-use-case-00 Mo: You're trying to protect that a site can enforce the end-to-end session. Is that the JS enforcing something on the browser? Magnus: Not necessarily - the browser needs to behave Mo: Is the users valifating something or is it the user? Magnus: There are a couple of options here. The import thing is that the service can apply a policy and get it enforced. Mo: You want user control and service control Peter: When you say origin are they both referring to the server serving up the media ... Magnus: It's the top page. EKR: The underlying assumpton is that the web origin is associated with a server not the KMF. There's a KMF and somebody wrote the SFU? Magnus: You want to stop a man-in-the-middle. EKR: the mental model is that the enterprise contracts out and they provide a conference systems except the KMF so that the conference system can be updated but ... Magnus: THere's one step before that to run a server that loads the basic page and policy. EKR: You might do that but that's not how Mozilla runs most of its services. Peter: The origin server must be run by the party that wants end to end or is it may. Magnus: So far it's a must. Peter: That's a great goal. ... EKR: I hope it's just the KMF. Adam: Just to be clear the implication is a standardized protocol for KMF? Magnus: You need to have it secure for key retrieval. Adam: I think that might be problemtic. I want to collocate the UA with the KMF(?) Roni: Do you know that the client is going to an entity in this conference? Magnus: Some yes - I would claim you need ot know the mode of operation. Roni: There needs to be a requirement then. EKR: it seems like you need to know there's a push and a double wrap nothing else before that is useful. Peter: I think this is a policy choice of the application (for clients to get access before they join). Some applications will want people to have early access to content. Magnus: Agree it must be optional. EKR: I agree but I don't see it as a reasonable required for real-time data. Peter: Building toward the recording case. Roni: You should the participant may join only for a short time. When do you want to do the rekeying. Magnus: Yes there's some implications on rekeying here. Want to make sure there's no impact on the quality of service provided. Roni: I think some of the requirements are general problems. Magnus: The problem is the trust model the middle boxes aren't trusted here. EKR: (on the strawman solution) ONe thing that confused me is why are you encrypting they key? Magnus: I don't think we're encrypting it. EKR: It's encrypted with a key the client supplied? Richard: This is more about solution that requirement so let's hold this convo. Open Discussion Roni: The first thing is does the end-point need to know it's about support MTF. There are some conferencing where you're getting invited from the application so there a different flow so there's not really a login. Magnus: I think I agree with Roni. Not all identities are people. When it comes to dialing out it doesnt' look that different. Fluffy: I didn't see much about names that are displayed to users - it's important that the people in the conference have an idea what conference they're in. We have to have something user visable. EKR: Right ... so ... I guess ;) at present you mean something visible in the chome (yes). Mo: Need to understand the user and site authentication trust models. Richard: There's an tension between the desrie to not impact endpoints. PHB: It solves a lot of problems if you just use a fingerprint thoughtout your code. Roni: I noticed something about only explicitly registered clients. There can be different models that allow open conferences. Magnus: Somebody that has authority over the conference is the one to decide whether it's open or not. Those participants are the only ones who can join. Adam: Curious about the point you're making about existing implementations - there's ton of stuff changing so displaying stuff in the chrome doesn't look that bad. Richard: Just saying that it seems like we want to minimize the changes. Adam: Is the site forcing perc or not? EKR: Not sure I'm groking force/expose Adam: It's perc or don't work. Richard: There'a more basic definitional problem here- what do mean by do perc. Not sure it's oberservable from the endpoint. John: Knowing it's perc or not is not enough. EKR: The machinery I expected is that the user is being asked to give permission for media graned toward the KMF. .... Fluff: The user experience we want to have moz using hangouts whitebox provider and when you go to start the conference you authorize your camera to send media conF#@moz and all the web interaction happened with moz@conference.com. Adam: That's a forgone conclusion? ... Paul: Need a use case document. Colin: Need to make a decision on ruling TCP info (?) in or out of scope Andrew: On active keep alives there are times in mobile networks where you might be out for several minutes. Magus: Yes but there's a difference in the set of people in the conf - you end up forcing a rekey. Ted: Any system which is attempting to rejoin must be able to handle that the conference was rekeyed. Active keep alives are horrible on the batteries of mobile devices. How are we going to be dealing with muting to rejoin later? EKR: Do we need to identify multiple senders: bridge can assert the senders or it can be end-to-end. The last time we did sigs for RTP and now we can actually sign ever packet. draft-jones-perc-private-media-framework-00 Adam: Clarification that changes are to ekt or a profile? Paul: Changes not profile. Adam: We should probably send requirements to the WG already managing it. Paul: Not sure EKT is used in industry. Adam: It belongs in the mmusic Magnus: This group is specified to do this work so do it here. Jon: .... Paul: ... Colin: there's an assumptoin that the MDD has access to the hop-by-hop. We might want to limit what information the endpoints put in RTP. Paul: It comes back to whether we want to encrypt RTCP so far it's just been hop-by-hop. Endpoints just shouldb't put anything confidential into RTCP. EKR: As I understand it here is that hte tradeoff is that thre's some info leakage. EKR: Would be good to get somebody to write up what the middle boxes can do. Fluffy: There's more in RTCP that I remember - need to do a privacy scan. Either don't use 'em or encrypt them. Justin: ... draft-mattsson-perc-srtp-cloud-00 Peter: Are yo usaying the relevant RTP tops is exactly this list or just some. John: These are the ones we know about. I don't thinkwe should support ever RTP topologies ever made. Magnus: There aren't really that many topologies. Andrew: Are you just considering unicast? John: multicast is out of sopce according to the charter. Mo: You mean even if the speaker is switched out and doesn't come back for 10 minutes you want to force a continuous seq # John: I would say RTP enforces that. Mo: I disagree with that requirement Colin: It's been there from the beginning. Mo: Loss strategy needs to be rethought wrt perc. Magnus: Rewriting seq # is possible and I think that's right accoridng to the RTP spec. Rewriting seq # should be open though. Colin: We need requirements that make it consistent with 3550. But what's being suggested isn't. Fluffy: The way this slide is phrased is misleading (do not break RTP slide). Colin: I think there are other ways to solve this without breaking the endpoints. Jon: Is there a need for the ? to have semantics or can they be random? John: In the IV formation case - yes. Mo: I want to make sure existing policies can migrate. Source data is send unmolested through the middlebox. Requiring middleboxes to do transfroms seems unnecessarily. EKR: I think we should understand there are two distict problems: Key management and RTP screwaround. We need to keep them seperate. Can we do a design team? What to have ordinary endpoints to be the KMF. Colin: Agrees we should try to seperate them out. Steve: Want a use case document. Mo: Good that they're both concentrating on GCM. Also think about new work like aero(?) Magnus: Request that the framework - why is the hop by hop key from the KMF as opposed to generating it by the two end points. Paul: The MDD is just passing the connection to the KMF so it's kind of transparent. Do this so the endpoint when it does DTLS/SRTP/EKT it can do it point to point and the they're behaviour is the same. Do the key exchange in the media path and minimize changes on the endpoint. Mo: To expand a bit - you could make other choices. How should the DTLS tunnel be deployed - in one implemention the MDD is like a turn relay to the KMF. You could also do two DTLS sessions. Fluffy: It's desirable to be able to ensure the arrival is fast to make sure the key delivery and media are in synch. Deiverying identity info for point to point is the same as conference call. Richard: Design team for RTP bits that need ot be exposed to middleboxes? Seeing thumbs up. Bernard: Is this a decision about what points we're not going to support of 3550? Richard: ... Colin: Again the SRTP spec has two parts - we do need to consider both parts. Richard: jon, magnus, paul, justin, jon, fluffy, colin, ekr, randell, maire ------------------------------------------------------------ Raw notes (From Alan Johnston) ------------------------------------------------------------ Tuesday, 1300 - 1500, Congress Hall III Minute taker: Alan Johnston Time Length Discussion Leader Topic Reference 1300 - 1310 10 minutes Chairs Administriva Review of milestones No agenda bashes 1310 - 1330 20 minutes Paul Jones Requirements draft-jones-perc-private-media-reqts-00 What changed Some new requirements Question about key management 1330 - 1350 20 minutes Magnus Westerlund WebRTC Usecases and Framework draft-westerlund-perc-webrtc-use-case-00 Use cases reviewed Question about site forcing end-to-end security Question about web origin being conferencing service Question about who runs origin server Question about standardized protocol for KMF Question about does client need to know Question about participant joiner is a policy setting Question about rekeying timing Question about moderator joining/rejoining Straw man solution Question about double encrypting key in Content-Encryption header field 1350 - 1405 15 minutes WG Discussions Comment - should there be a requirement for endpoint support Comment - how user knows what conference they are in - the name displayed to user Comment - different views of trust model Comment - only use key fingerprints to identify keys Comment - conferences can be joined in different ways, sometimes you don’t know who will join Comment - degree of changes needed for client to join a perc conference Comment - definition question - what does “conference is perc” mean? Comment - what is user experience Comment - there is a need for a use cases document Comment - there are few requirements on RTCP Comment - active keepalives Comment - we could sign every RTP packet 1405 - 1425 20 minutes Paul Jones Solution Framework for Private Media draft-jones-perc-private-media-framework-00 Question about changes or profile of EKT? Question about whether this WG is chartered to change EKT Question about assumptions about what can be put in RTCP Question about need for RTCP end-to-end 1425 - 1445 20 minutes John Mattsson SRTP For Cloud Services draft-mattsson-perc-srtp-cloud-00 Question about relevant toplogies Question about consecutive sequence number enforcement Question about resilience and packet loss 1445 - 1500 15 minutes WG Discussions Comment - Make sure present topologies can migrate to this one, avoid inflation of packet headers Comment - Separate documents for key management and SRTP modifications Comment - a use case document would be useful Comment - Aligning on GCM is good, watch our new Aero ciphers Comment - Chairs - What about a design team for SRTP about end-to-end vs hop-by-hop bits Comment - include RTCP. Volunteers identified as: John Mattson, Paul Jones, Jonathan Lennox, Colin Perkins, Randall Jessup, Eric Rescorla. ======================================================================================