Minutes RTCWEB Interim Meeting January 31st & February 1st, 2012 Chairs: Ted Hardie, Cullen Jennings, Magnus Westerlund Minutes: Mary Barnes, Alan Johnston, Ashish V. Thapliyal Agenda: http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/agenda/rtcweb.txt Jabber log: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html http://www.ietf.org/jabber/logs/rtcweb/2012-02-01.html Presentations: http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/proceedings.html No audio recording is available. Action items: Chairs to confirm consensus on the use of SCTP as a data transport. Chairs to confirm consensus that layering of SCTP would be SCTP/DTLS/UDP. Chairs to confirm consensus on JSEP / ROAP question Justin Uberti to provide -01 draft of JSEP as an individual submission. Hadriel Kaplan and Eric Rescorla to update architecture draft with text on use of ICE extensions/flags to indicate consent. Working group to gather SDES deployment data by IETF 83 to drive discussion on permitted modes for media security (browser-to-browser secure, javascript visible, unprotected). Working group to review IdP proposals and be prepared to decide at IETF 82 on basic model. Other conclusions: No objections to Harald taking MSID to MMUSIC. The group encouraged progress on bundle in MMUSIC. Attendees: Justin Uberti, Leon Portman, Jonathan Lennox, Wonsuk Lee, Soo-Hyun Choi, Anant Narayanan, Aleksandr Avseyev, Gonzalo Camarillo, Dan Burnett, Rohit Puri, Stephan Wenger, Mauro Cabutto, Robert Sparks, Timothy Terriberry, Bernard Aboba, Mary Barnes, Venkatesh Venkataramanan, Jim Barnett, Andrew Hutton, Xavier Marjou, Randall Stewart, Henry Lum, Milan Young, Yair Wiener, Aron Rosenberg, Dan Druta, Christer Holmberg, Spencer Dawkins, Oscar Ohlsson, Neil Stratford, Marc Petit-Huguenin, Eric Rescorla, Markus Isomaki, Ashish Thapliya, Mathieu Hofman, Stefan Hakansson, Jonathan Lennox, Matthew Kaufman, Mahalingam Mani, Cullen Jennings, Magnus Westerlund, Harald Alvestrand, Michael Thornburgh, Alan Johnston, Martin Thomson, Randell Jesup, Maire D. Reavy, Cary Fitzgerald, Li Zhengdong, Jonathan Rosenberg, Ted Hardie, Mathieu Hofman, Ashish Thapliyal, Adam Bergkvist, Lars Eggert, Suhas Nandakumar, Hadriel Kaplan, Robert Wolff, Manjesh Malavalli, Alexey Aylarov, Dan Wing, Lazar Bivolarski Discussion Summaries: Day 1 JSEP Review -Justin Uberti Goals: Allow easy translation to common signaling protocols and architectures Support early transport negotiation Allow local description to be changed by app Change session parameters at any time Allow direct manipulation of session state Give app as much flexibility as possible, now and in the future Non-goals: Super-simple API Replace SDP Offer generation in JS (at least not right now) JSEP Key concepts: Signaling and transport are separated Signaling state moved into application code Media controlled via local and remote session descriptions (SDP blobs) The "how" of the signaling is left to the application; only the results of the signaling matter Different signaling protocols have different features and mechanisms: Candidate handling Glare handling/Tie breaking Adding or removing sources or sessions RTP Session updates Basically, hard to have a generic signaling mechanism that can map faithfully to all signaling state machines, but that severely limits functionality, i.e., LCD. Needs of media layer: Local format description What I want/am going to do Remote format description What the other side wants/is going to do Local/remote transport info Where is media going to go, and how Discussion of ICE state machine at remote side, both for rehydration and interface changes. (Rehydration is the recovery/restart of a session after a reload) Summarize: need to figure how not to have to redo ICE. Discussion of adding and removing streams, leading to discussion of offer/answer model and where the offer state machine lives. Discussion of a glare-less add, which is based on a delta. Discussion of whether this a capabilities exchange or offer answer; conclusion that it doesn't preclude RFC 3264 Offer/Answer, but it also allows other handling. Things you can do: Send candidates as they are gathered Add/remove sources simultaneously Change session parameters at any time (with or without an O/A exchange) Control local session description that is generated and sent Rehydrate a session from stored state New APIS: creating SDP createOffer (hints): Creates a session description based on the current local media state; |hints| allows for some customization. Does not reserve resources, or change state. createAnswer(offer, hints): Like createOffer, but uses |offer| as input to create a compatible session description. Long discussion of where complexity should be. New APIs: Applying SDP setLocalDescription(type, desc) Applies the local description, e.g. recv codecs, encryption keys. Changes state. setRemoteDescription(type, desc) Applies the remote description, e.g. send codecs, decryption keys. Throws exception on invalid state or params Discussion of complexity of these and the granularity of error codes.: New APIs: ICE IceCallback(media, transportInfo) Callback function that receives transport information that needs to be signaled processIceMessage(media, transportInfo) Invoked to handle received transport information Session Descriptions Standard SDP Transport Info a=ice-candidate lines a=ice-ufrag, password lines a=fingerprint (for DTLS) a=group (for BUNDLE) Discussion of complexity. JSEP does require more code (~60 lines for a basic example, w/o glare handling), but can be encapsulated within a JS library, which might also perform protocol translation too (e.g. convert to SIP, XMPP, or ROAP). It was noted that it will need more specification of the API, in addition to more code. Noted that some developers bundle a library with application, so don't get updates. A more symmetric API may be easier to use. Argued that it is possible to build ROAP on JSEP. JSEP vs ROAP (first presentation view) Key differences: Signaling mechanism lives in app/JS Early transport negotiation supported App has control over local description App can change session parameters at any time, without O/A if desired App can restore session from cached state More JS code, but under app control Glare conditions become a non-issue for many apps Features can be added without new browser APIs (e.g. one-way video, hold, res change) Calls can persist across application upgrades 13:00-14:18 ROAP (Cullen) -Updates since last presentation -Contrast between JSEP and ROAP ROAP Design Rationale Be the simplest protocol possible that can do RFC 3264 Offer/Answer with SDP Concerns about an SDP-based interface: 1. Forces browser to be conscious of SDP offer/answer state 2. Speed of call setup 3. State resurrection on page reload Managing codec resources - From RFC 3264: (review of allocation, sending media, and freeing) Modifying the SDP offer/answer pair state. How the media engine ends up needing outstanding offer state concern is that this is so deeply embedded that you can separate out. What is SDP state? Resources allocated for Old and New SDP When to free Old resources, when to free New Examples of Offer/answer Discussion of "sdp state" vs. "browser state" Review of how Peerconnection might tell a JS application of the SDP changes needed for HOLD. Digression into UI. Review of diagram on quick call setup, and causes of delay. Extensive discussion of what optimizations are possible and the security consequences. The need to run ICE to completion, rather than have the server generate secrets marks the limits here. Proposal to add Candidates message to ROAP Hard to separate the transport information out of SDP but there is one thing that looks like it could be done to allow "trickle ICE" Make a new ROAP message called CANDIDATE with new candidates. This message can be sent at any time and each element in the array augments the candidates in the previous SDP offer/answer CANDIDATE message structure: array of sets of candidate lines. The n'th element in the array is added to the candidates for the n'th "m=" line Believe (hope) this will not break ICE because ICE already allows new candidates in form of peer reflexive at any point in time Need cost/benefit analysis of performance improvement versus potential problems Thoughts? Experiment with this - try out? Discussion of compatibility issues and advantages; worthwhile to examine syntax. Discussion of slide describing the bits of SDP involved in transport. Discussion of resurrection/rehydration on page reload. Should this redo ICE? Proposal: JS to control update timing Current ROAP API calls a callback with new SDP anytime something changes JS expected to send SDP immediately Instead it could call a callback indicating "conditions changed; new SDP required"รน.The JS Application would then be able to ask for the new SDP and send it Not clear where this flexibility helps but it would not be hard to add and would match JSEP in this regard Discussion of the offer/answer limitations with multiple offers. Table of design choices: - Use SDP O/A Pros: finished and deployed. Cons: Ugly. Timeline: 4 months. - Separate transport out of SDP. Pros: architectural purity. Cons: hard to figure out what might break. Timeline: 12 months - Replace SDP. Pros: SDP is hideous Cons: very hard to deploy. Timeline: many years. This carried into general design resolution, for which please see the jabber logs. Consensus questions? 1--Don't care whether ROAP or JSEP is the input document for further work in this area 2---Prefer ROAP be the input document for further work 3--Prefer JSEP be the input document for further work 4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semantics. The results were: 1=9 in room, none in jabber 2=11 in room, 2 in jabber 3=25 in room, 3 in jabber 4=8 in room, none in jabber. Consensus to be confirmed on the list. 15:45-16:20 ish MSID (Harald) Possible solutions Basic issue relates to mapping streams and tracks. Possible responses: Ignore problem - Works badly with multiple streams Use existing identifiers - SSRC: Doesn't exist until PeerConnection connected;it fits with track, but not with stream - CNAME - Has other semantics (synchronization, source) - RTP session / SDP m-line: Unique media type breaks MediaStream concept Add a new identifier: Nonstandard, API only or Standard, carried in SDP blobs Extensive discussion; eventual belief that this is a new semantic, which might be useful outside of RTCWEB. No objection to it going to MMUSIC for further work. 16:30-17:30 Data channel (1) (Randall) Uses Side channels during a 'call' (mute status, etc) Chat File transfer Application synchronization Games Shared whiteboard Co-browsing Shared document editing (with audio and/or video) Many uses we haven't thought of yet Data Channel Requirements Multiple data channels Reliable and unreliable Datagram and Stream (if reliable) paradigms MUST be congestion-controlled MUST be secure (*) Quality open-source userland implementation needed for deployment See draft for other implementation requirements Discussion of whether these requirements can be derived from use cases. Discussion of how much is gained by having an unreliable data channel Reviewed the pros and cons of Pseudo-TCP over UDP, DCCP, SCTP-DTLS, DTLS-SCTP Open issues: SCTP: Michael Thornburg's issues - Blocking of other channels if one isn't serviced Draft for SCTP-DTLS needed if chosen Interleaving of large datagrams DCCP: Is a userland implementation available? Quality? General: Inter-stream priority (nice-to-have) Congestion control interactions with app and media streams PMTU sensing Long discussion of congestion control methods; SCTP's plugabble congestion control emerged as a major advantage. Consensus call: Do you want something other than SCTP for data transport protocol? (3) Do you want SCTP? (19) Question: Do you have enough data to decide on SCTP layering? Review of the differences. SCTP-DTLS-UDP (18) DTLS-SCTP-UDP (0) Consensus calls confirming SCTP and layering to go to the list. Day 2 February 1, 2012 Security Topic - Eric Rescorla (Ekr) Security arch document: draft-ietf-rtcweb-security-arch-00 Issue: Mixed Content Proposal: Remove RTCWEB permissions for origins with mixed content Discussion about MUST vs SHOULD What if page becomes mixed content during a session? Ekr will write text with proposal in next version of draft. Issue: Content Freshness/Keepalives Proposal: MUST use STUN binding requests (not indications) every 30s Discussion about ICE extensions/flags to indicate consent Discussion that this only prevents browsers from being used in attacks - others could still do a flooding attack Discussion that RTCP is not useful for this. Ekr will write some text with help from Hadriel on this. Issue: Media Security Requirements DTLS-SRTP or SDES or RTP Try to make a decision in Paris based on SDES deployment data Two security models proposed: Browser-to-browser secure, Javascript visible Example given Google Chat "off the record" button Discussion about value if users don't check fingerprint or use an Identity service Discussion about forking of media Discussion of tradeoff between complexity vs benefit More on this during Randell Jessup's presentation (W3C WEBRTC) Discussion that this is useful if coupled with identity service Discussion that identity could be a service and not the website Generic Identity Service - Eric Rescorla (Ekr) draft-rescorla-rtcweb-generic-idp-00 Goals presented Discussion about how this is bad for services that want to be able to record media Discussion that a web page could play recorded media instead of real media Discussion that it isn't that you don't trust your own site, but you don't trust the other guy's site - federation case Overview presented with topology diagram Types of Identity Providers (IdP) presented Discussion of IdP that relates to telephone numbers - not clear which case this is - perhaps a third category is needed Discussion about number portability, Viper, iMessage use of phone numbers User Relationships with IdPs Web-based IdP Systems Facebook Connect example (slide 42 (not slide 23) shows example screen) BrowserID example Discussion about sharing across mobile and desktop devices Discussion about delegated vs federated identity Window Communication - PostMessage Discussion about how this affects mixed media case Iframes What are we trying to accomplish? Discussion about permissions being per user and not per browser - tied to a session ROAP Example with BrowserID Discussion about having multiple IdPs used - it is possible JSEP Example and Facebook Connect What needs to be defined Discussion about what this means - how media is rendered What needs to be signed Discussion about signing ICE candidates - perhaps not necessary Discussion about only verifying part: fingerprint but not ICE candidates - possible, but needs multiple signature blocks Security Properties of ICE Candidates Discussion that it is an advantage not to protect the ICE candidates Discussion that the TURN server could be provided by browser and trusted by user - configured by user similar to HTTP proxy, etc. Discussion about how SBCs today insert themselves as a TURN ICE candidate Discussion about whether every JSEP message will need to be signed - avoid this by only signing fingerprint Discussion that could avoid having to go back to IdP for every message Discussion about protecting against traffic analysis by protecting ICE candidates Discussion about the difficulty of allowing different information to be signed, when the net result is binary: this is Alice or this isn't Alice. Discussion about having different TURN servers in different directions Skipped slides of Security of Media Parameters Generic Structure for Identity Assertions How does PeerConnection know IdP domain? Discussion about multiple choices of IdP and trust anchors and if an IdP is less trustworthy than another - choice of authoritative vs 3rd party Discussion about how to avoid state sponsored IdPs, e.g. Iranian government - how to avoid popups and trying to explain 3rd party assertions Discussion about only using authoritative assertions - ignoring third party assertions Discussion about multiple active sessions - need to be able to interrogate using browser chrome Incoming Message Checks (IdP Proxy) Discussion about using // - don't have to use Integrated IdP Support Chairs: not ready to make decisions today. Everyone should read, think, and be ready make decisions in Paris Support for SDES in RTCWEB - Oscar Olson Decisions to be Made Question: have we made the decision to disallow plain RTP decision? Chairs: No Question: we need to decide RTP before SDES Why even consider SDES? Discussion if interop is important, then RTP needs to be discussed Why is interworking simplified? Discussion that 100% of 4G handsets also contain browsers, so this might be the upgrade path Discussion we need to know what X is (% of existing that support/use SDES) Discussion that devices facing the public Internet is the key question - there is more SRTP used than inside the firewall. Discussion about DTLS-SRTP encryption/decryption - could use EKT to avoid this Discussion that avoiding clipping is important, as SDES avoids extra round trips Chairs: Encourage Dan Wing to continue work on use of EKT to avoid encrypt/decrypt in gateway. Security Implications of SDES Discussion about undetectable, but not plausible Discussion about MitM that users must trust man in the middle or check fingerprints/use IdP - can't put lock icon on SDES Discussion that SDES does not have protection against passive attacks and forward secrecy Discussion that conclusion that SDES can be used securely is false. Ran out of time and ended on slide 6. Chairs: Question of legacy interop - how do we detect when legacy interop is happening - please discuss on the list. Chairs: Want activity before Paris, don't stop work.