Privacy Enhanced RTP Conferencing IETF 96 Session 2016-07-22 1000-1200: Tiergarten Scribe: Bernard Aboba, Joe Hill, Olle E Johansson Summary: * Chairs to restart virtual interims to discuss open issues/work items. * Solution Framework documents (draft-jones-perc-private-media-framework) - framework needs to consider mapping with the RFC7667 RTP topology Spec - authors to update entity trust section on Identity establishment - close open issues related to end-point/conference mapping and others. * SSRC Immutability Discussion - WG discussed SSRC mutability vs immutability options - no consensus reached in the room - Emil asked to submit draft explaining the impact of ssrc mutability on security/ssrc collision/end-point procedures in the perc context. * SRTP Double (draft-jennings-perc-double) - needs to address how e2e headers are dealt with * Tunnel Specification (draft-jones-perc-dtls-tunnel) - authors discussed various tunnel transport options (udp/sctp/tls) - concerns related to "firewall traversal" and "DTLS 1.3 message changes" were discussed with the current DTLS based tunnel proposal. - alternative options for tunnel design related to HTTP/Datachannel(SCTP) as the control plane protocol were discussed. - authors to submit updated draft to consider TLS for tunneling DTLS message. - authors to consider Tunnel protocol's extensibility mechanisms as part of the updates * EKT Specification (draft-jennings-perc-srtp-ekt-diet) - TTL to be a relative time rather than absolute time. - extensibility for adding new ekt messages. Authors to discuss this on the mailing list. ------------------------------------------------------------ Raw notes ------------------------------------------------------------ *** Agenda bashing - SOme confusion on who's presenting what, quickly sorted out -- Virtual interim - RB will start discussion on list --- Presentation: Draft-ietf-perc-private-media-framework-01 (David Benham) * Action items - Media distributor requirements and constraints to rfc7667 topology mapping - List of RTP header extensions that should/must not be encrypted - There may be others - Mapping of endpoints-to-a-given-conference may need to be conveyed - Possibly add ability for transmit-only devices not trusted for two-way media - Expand entity trust section (certificate fingerprint via signaling, identity assertions) Roni: YOu want to identify to the key management Adam Roach: Need to map to WebRTC and SIP Richard barned: We should look at the feasability Cullen Jennings: EKT doesn't support this (as EKR said) and I don't see a strong need for this --- Presentation: SSRC immutability - Emil Ivov - Emil: Risky to hinge PERC support on RID (not clearly specified, not implemented) - Emil: Do not prohibit SSRC changes in Perc - Peter Thatcher: The real issue is whether the endpoint can receive simulcast or not - Adam: To claim that simulcast is going to hold it up is wrong. Simulcast is in WGLC and we're not close - Colin Perkins: The discussion to have is where we want the complexity? A simpler middle box or more complexity in receivers? It is a design philosophy. - Discussion about SSRC collissions and how to handle that - Jonathan: this is what RTP topologies is supposed to handle/solve - Roni: Do we trust the middlebox or not? Richard: On one side: If we continue to require SSRC being inmutable, we have a dependency on RIB On other side: SSRC Collissions, two ssrc's being handled Quick hum: Two options: - Keeping requirement that SSRCs being immutable - Allowing mutability No consensus declared - back to mailing list Cullen: We need Emil to write a draft to be discussed, describe what happens on the endpoints --- Presentation: Double - Drat-ietf-perc-double-01 - Cullen Jennings - Which RTP headers are added by the Media distributor - Jonathan : Adding end2end headers later will be really hard - Harald: Need to note that PERC doesn't give any security protection for end2end headers --- Presentation: DTLS Tunnel Protocol - draft-jones-perc-dtls-tunnel - Paul Jones Concerns with current draft - Using DTLS between key distributor and media distributor presents NAT/FW traversal challenges - Current protocol is very limited in terms of extensibility - Current protocol is tightly coupled to specific DTLS messages that will change in DTLS 1.3 EKR: Why are we not using https rest as a control plane? EKR: Proposal: Simle encapsulation protocol used as an outound connection from key distributor to media distributor (slide 5 without message type 2 and 3) Using JSON data structures Adam: No one seems to be in favour of data channels, we're down to a single TLS connection. Need mailing list discussion. Cullen: ...or two connections... --- Presentation: draft-ietf-perc-srtp-ekt-diet - Cullen Jennings Jonathan: Keep message types outside of encryption to assist Wireshark -- End of august timeout for reviews -- End of session -- Jabber log: 10:05 Bernard Aboba [aboba@bluebox.internaut.com/jitsi-1fm10c0] entered the room. 10:05 Nils Ohlmeier [_716589068@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room. Olle E. Johansson at IETF Berlin (GMT+1 DST) 10:05 Slide: Milestones & Documents 10:05 Richard Barnes (chair) speaking 10:06 Slide: Agenda Bernard Aboba 10:06 Richard: Have adopted documents. Drafts welcome on integration with SIP and WebRTC. Olle E. Johansson at IETF Berlin (GMT+1 DST) 10:06 Adam Roach speaking Bernard Aboba 10:06 Richard: Agenda Bash. 10:06 Cullen: Assumed I was presenting, so I have slides. 10:07 Richard: Will add a brief 10 minute slot on SSRC immutability. 10:07 Maire Reavy [1318252808@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room. 10:07 m&m [linuxwolf@outer-planes.net/tradegate] entered the room. 10:08 Vincent Roca [_136287043@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room. 10:08 bergtau [bergtau@jabber.de/c88261a9-e64c-44f0-a76e-89f5a94e0927] entered the room. Bernard Aboba 10:08 Richard: Should we pick the tempo back up with respect to virtual interims? 10:09 David Benham: Framework discussion. 10:09 (draft-ietf-perc-private-media-framework) 10:10 David: In Buenos Aires we adopted 3 working group drafts, including framework draft. Everyone has ready it, right? 10:10 David: Differences in -01. 10:10 David: Reduced acronyms. Olle E. Johansson at IETF Berlin (GMT+1 DST) 10:11 Notes on Etherpad - please help out and keep and eye on it. http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-perc?useMonospaceFont=true 10:12 Jonathan Lennox [jonathanlennox@jabber.org/Vidyo-LT0519-M] entered the room. Nils Ohlmeier 10:12 Did other people also lost video and slides from the room? Bernard Aboba 10:13 David: Outer SRTP master keys created by each endpoint. A conference-wide encryption key used to encrypt endpoint 10:13 "Outer" master key. Jonathan Lennox 10:14 Nils: as I understand it Meetecho should have a button to restart your streams. Nils Ohlmeier 10:14 Jonathan: yeah clicking like 10 times on the refresh got me at least the slides back Meetecho 10:14 yes, audio can be restarted with a button in the upper left (speaker icon circled by two arrows) Sean Turner 10:15 nope - working fine here Meetecho 10:15 video streams by hovering on the stream and clicking the half crcled icon 10:15 no need to click i tten times, though, just give it some time 10:15 (unless it takes way too much time, that is...) Bernard Aboba 10:16 David: Constraints to rfc7667 topology mapping: TOPO-PtP-translator or SFM w/single common SSRC space 10:18 David: Add a list of RTP header extensions that should/must not be E2E encrypted? 10:20 George [gpolitis@jabber.at/116737183237570818411469175552932937] entered the room. Bernard Aboba 10:20 David; Possibly add ability to transmit-only (one way) 10:21 Deb Cooley left the room. 10:22 Deb Cooley [1060721590@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room. Bernard Aboba 10:22 EKR: What is the use case? 10:22 Cullen: An announcement server that says "Cullen Jennings joined the conference". 10:22 Jonathan: How strong is this requirement? Are you willing to drop it? 10:23 David: Someone brought it up on the list. 10:24 Roni: This bullet raises an issue which is not discussed. You say MDD is not trusted content. But this says it's not trusted with the media distribution. 10:25 EKR: I am assuming this is an E2E requirement. So you need different directional traffic keys. You extract different keys in each direction anyway, but this requires extracting 4 keys: RTP and RTCP in each direction. 10:25 EKR: Could require surgery in EKT. 10:26 Cullen: EKT doesn't support this but we could do it. Use case when someone joins a conference, can be delivered out of band, so we don't need to deliver through the audio channel. I do not see a strong need for this, personally. 10:27 Paul: Explains how it could be added to EKT. 10:27 Randell Jesup left the room. Bernard Aboba 10:28 Adam: We already have hop-by-hop keys. 10:28 Mo Zanaty: One of the suggestions was to allow mixing of PERC and non-PERC media. 10:29 Mo Zanaty: Difficult for endpoint receiver to know whether it is trusted or not. 10:29 David: Started a section on identity trust. 10:30 Emil on SSRCs and immutability. 10:30 George left the room. Bernard Aboba 10:30 Emil: Currently, PERC says that an MDD cannot rewrite SSRCs. There has been a lot of discussion around this. Sean Turner 10:31 emil protesting the pink box Bernard Aboba 10:31 Emil: For me, this is quite problematc. SSRC overwrites are used for active speaker switching (one SSRC as main speaker). 10:31 Emil: There is also simulcast. Sender sends multiple layers, but receiver gets a single stream. 10:32 Emil: I am specifically concerned about simulcast case. Only way to make it work with WebRTC (SSRC overwriting). 10:33 Emil: There is also RID-based approach. Not clearly specified yet. 10:33 Emil: No motivation in SFU to add support for RID. Why do it if you already have simulcast? 10:34 Emil: Supporting PERC in SFU requires two branches of code - one to support WebRTC, and a separate branch for PERC (incompatible with WebRTC). 10:34 Emil: These arguments are against making RID the only way to use PERC. 10:35 Emil: Change is not to prohibit use of RID or to prohibit simulcast reception. 10:36 Peter Thatcher: RIDS are just there so you don't have to signal SSRCs. So it's a red herring. Real question is whether endpoint can receive simulcast or not. 10:36 Peter Thatcher: Receiving simulcast a small part of total work.... 10:36 Emil Ivov: There is so much work, so why not add more?? 10:37 Peter Thatcher: In a future version of WebRTC that supports PERC can we also support simulcast? 10:37 Simon Pietro Romano [1204262422@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room. Bernard Aboba 10:37 Peter: ORTC already supports reception of simulcast (with two implementations) 10:38 Adam: RID work is more mature than PERC. 10:38 Vincent Roca left the room. Bernard Aboba 10:39 Richard: Would anyone like to address benefits of immutable SSRCs? 10:39 Colin Perkins: An architectural comment. Architecturally, we could implement this in either way. 10:40 Colin Perkins: The discussion to have is where we want the complexity? A simpler middle box or more complexity in receivers? It is a design philosophy. 10:41 Lorenzo Miniero [1182989666@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room. Bernard Aboba 10:41 Colin: Technical point. Does collision logic work? 10:41 Nils Ohlmeier left the room. Bernard Aboba 10:42 Mo: It can. This is how it would have to work to have a common SSRC space. 10:42 Colin: Not as simple as carrying the original SSRC. 10:42 Nils Ohlmeier [2004610944@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room. Bernard Aboba 10:44 Mo: What I thought was your original main point. For each participant there is a single decoder pipeline. 10:44 Mo: If it is simulcast reception you have a new decoder pipeline for each resolution. 10:45 Mo: This is why some architectures choose to receive different qualities (but not multiple streams). 10:46 Emil: At WebRTC client level there is no support for receiving multiple streams, so that is why the SFU rewrites. 10:46 Mo: Since WebRTC browsers do not support this, you are worried about this?? 10:46 Emil: Maintaining two ways of supporting simulcast also is not thrilling to me. 10:47 George [gpolitis@jabber.at/2900618927793902391469177245586653] entered the room. Bernard Aboba 10:47 Cullen: How does this work for audio? 10:47 You have disconnected 10:48 You have connected Bernard Aboba 10:48 Emil: It is not needed for audio. 10:48 Olle E. Johansson at IETF Berlin (GMT+1 DST) has set the topic to: PERC @ IETF96 | Agenda: https://www.ietf.org/proceedings/96/agenda/agenda-96-perc Lorenzo Miniero 10:48 Emil is not saying there's no support for receiving multiple streams: just that it is not fast and effective enough to make it transparent and immediate in the client experience 10:48 SSRC overwriting does Bernard Aboba 10:49 Cullen: If the middle box can switch SSRCs, can take packets from one... 10:49 Emil: Can send the original SSRC in the packet... 10:50 Ben Campbell [ben@nostrum.com/avalon-air] entered the room. Bernard Aboba 10:50 Jonathan: Emil is saying that he is going to need to maintain this mechanism until everyone endpoint that only supports the original way is decommissioned. And he does not want to maintain two code bases for this. 10:51 Emil: Don't agree that there is a security vulnerability. 10:52 Jonathan: Emil wants a different RTP topology than translator or single SSRC space. So this gets into the framework discussion. There are use cases in a conference where you want to send the same source twice. 10:52 Jonathan: You need to either have multiple MIDs for a source or SSRC rewriting to get that use case to work. 10:53 Miguel: Bottlenecks are in the browser side. I agree with Emil. Nowadays we need to rewrite SSRC. 10:54 Miguel: Why must SSRC be immutable? I do not understand why. 10:54 Roni Even: This is more than just a topology discussion. 10:54 Roni Even: You prefer that middle box is smarter because you cannot depend on the endpoint. I think that is the right way to go. 10:56 Roni Even: If we say middle box is not trusted for what it will distribute then I understand why you are doing this. 10:56 Paul: You will get original SSRC value. 10:56 Paul: You still get original sequence number value. 10:57 Paul: How does endpoint react to that? Does it use original value or modified one? 10:58 Richard: Summarizes tradeoffs. 10:58 Cullen: Some issues around collisions. Lorenzo Miniero 10:59 hummm for relaxing Simon Pietro Romano 10:59 hummmmm Bernard Aboba 10:59 Richard; If you are in favor of keeping requirement for immutability, please hum. Simon Pietro Romano 10:59 ...relaxing Bernard Aboba 10:59 If you are in favor or relaxing, please hum. 10:59 We do not have consensus right now. 10:59 Richard: We will take it to the list. Maire Reavy 10:59 relaxing Bernard Aboba 11:00 Cullen: Emil should write a draft. 11:00 Richard: Emil, are you willing to do the work? 11:00 Emil: Are you asking me to define PERC with SSRC mutablity? 11:01 Richard: What are the processing rules? 11:01 Cullen: All the things we need to put into various documents to make this work. 11:01 Deb Cooley left the room. Bernard Aboba 11:02 Emil: I have addressed the security concerns. 11:02 Richard: We need to wrap this up. 11:03 Roni: You have to do the same for SSRC as for sequence number. 11:03 Colin: Would be useful to produce a draft that lists the concerns. 11:03 Richard: Are you volunteering? 11:03 Colin: No. 11:04 Cullen presenting draft-ietf-perc-double 11:05 We have a hand wavy part of the draft. The mixer can insert some header extensions... but others we might not allow. Sean Turner 11:06 please use mic Bernard Aboba 11:06 Cullen: Client will insert client-mixer level. Do you want MDD to copy values. 11:06 Jonathan: It isn't mixing, so no. 11:07 Jonathan: MID is required for this to work. 11:07 Cullen: CVO does not make sense for middle box to change, coupled to original video. 11:08 Randell Jesup [1317443580@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room. 11:08 Suhas Nandakumar left the room. Bernard Aboba 11:09 Clue Capture ID is in YES category 11:09 Emil: Abs-send-time 11:09 Peter Thatcher: Why do you need MID? 11:10 Jonathan: MIDs are chosen by the offerer. 11:10 Peter: congestion control stuff. 11:11 Ben Campbell left the room. 11:11 Ben Campbell [ben@nostrum.com/avalon-air] entered the room. Bernard Aboba 11:11 Jonathan: No E2E confidentiality of header extensions.... because I designed that so badly. 11:12 Cullen: We can reconstruct the headers that the original person sent. 11:12 Richrard: YES means mixer is allowed to change it. 11:12 Harald: Is there an extension for which there is a security concern? 11:13 Cullen: Didn't look like it to us.... 11:13 Ben Campbell left the room. Bernard Aboba 11:13 Roni: Client-Mixer (Mixer needs to see it, but shouldn't change the value). 11:13 Cullen: Endpoint shouldn't be using it, so what is the problem? 11:13 Ben Campbell [ben@nostrum.com/avalon-air] entered the room. Bernard Aboba 11:15 Cullen: Any other issues? 11:15 Jonathan Lennox: I think in Emil's architecture if you rewrite SSRCs, you will need to rewrite timestamps. 11:15 Cullen: Changes to this draft are minimal to support Emil's plan. 11:16 sftcd [sftcd@jabber.org/18f2775dae1febea] entered the room. 11:16 Kathleen Moriarty [kathleen.moriarty.ietf@gmail.com/AdiumFFD0CA25] entered the room. Bernard Aboba 11:17 Paul Jones, presenting draft-jones-perc-dtls-tunnel 11:17 sftcd left the room. 11:17 Kathleen Moriarty left the room. Bernard Aboba 11:17 Paul: Using DTLS presents NAT/FW traversal challenges. 11:18 Paul: Current protocol coupled to messages changing in DTLS 1.3. 11:18 Paul: A TLS or WebRTC data channel could address the above concerns. 11:21 Paul; suboptions for data channels 11:22 EKR: Why are we not using the web? 11:23 EKR: You seem to be assuming that DTLS packets being tunneled are going over same channel as control info to MDD. Why? 11:25 Paul: Coupling DTLS/SRTP with control traffic. There is convenience in that. 11:25 EKR: You could use HTTP REST for the control channel. Would make system much easier. 11:29 Richard: Not clear to me that passing transport messages via HTTP makes sense. 11:31 EKR: Web services interface. 11:31 EKR: Messages 2 and 3, use REST. 11:32 bergtau left the room. Bernard Aboba 11:32 Cullen: Having two protocols could create issues when load balancing sends the protocols to different destinations. 11:36 bergtau [bergtau@jabber.de/612cacd0-c1e3-499f-b572-bf0f652a2e6a] entered the room. 11:38 Yana Stamcheva [_1932356384@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room. Bernard Aboba 11:39 Cullen on draft-ietf-perc-srtp-ekt-diet 11:41 Cullen: There are legacy EKT implementations... but not clear we have to worry about conflicting with them. Jonathan Lennox 11:43 Me, off-mic: do you need a registry? 11:43 Ben Campbell left the room. 11:43 Ben Campbell [ben@nostrum.com/avalon-air] entered the room. 11:45 Lorenzo Miniero left the room. 11:45 Bernard Aboba left the room. 11:45 Maire Reavy left the room. 11:45 Nils Ohlmeier left the room.