- RTC-Web - alvestrand.no

Summary of Alternatives for media keying
by Eric Rescorla 26 Jul '11

26 Jul '11

Hi Folks, This is very late, but here is my attempted summary of the discussion about COMSEC choices at the interim. I'm not saying that this captures everyone's position, but the following positions are the ones that in my view have significant levels of support. Alternative A: [DTLS MUST, NO SDES, NO RTP] An RTC-Web client MUST support DTLS-SRTP and ONLY DTLS-SRTP for media, without support for either SRTP with supplied keying material (SDES-style) AND plain RTP. DTLS-SRTP provides for end-to-end key negotation between the two RTCWEB clients. The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection profile and the DTLS cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA in that it mandates support for Diffie-Hellman key exchange in order to provide Perfect Forward Secrecy. An RTCWEB client MUST provide its user with the ability to to see keying material information sufficient to allow indepent verification of their peer's identity. (REF draft-kaufman-rtcweb-security-ui). The primary drawback of this alternative is the lack of backwards compatibility with devices and software that only support plain RTP, but the requirement for a handshake makes interoperation with these devices not completely trivial anyway. Alternative B: [DTLS-SRTP MUST, SDES MAY, RTP MUST] An RTC-Web client MUST support DTLS-SRTP for media. DTLS-SRTP provides for end-to-end key negotation between the two RTCWEB clients. The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection profile and the DTLS cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA in that it mandates support for Diffie-Hellman key exchange in order to provide Perfect Forward Secrecy. This MUST be the default mode of operation. An RTCWEB client MAY support SRTP with the keying material supplied via the signaling channel with the SRTP_AES128_CM_HMAC_SHA1_80 protection profile. In the case of a web browser client, the keying material should be supplied via a Javascript API. DTLS-SRTP, with its end-to-end keying and authentication capability is preferred over SDES-style [RFC4568] keying. However, the additional API overhead required to add support for a way to force a particular key is low. In addition, once plain RTP is to be supported the arguments against the lower security level provided by SDES-style keying are no longer relevant. Also there are a small number of potential use cases where interoperability with existing SDES-keyed software or devices may be achieved if the RTCWEB endpoint supports this mode of keying. An RTCWEB client MUST support RTP. This provides no privacy but maximizes interoperability. Note that SRTP with a Null cipher has equivalent security but does not meet the interoperability requirement. Plain RTP provides no protection for the media, and so is discouraged as a mode of operation for RTCWEB. However, support for RTP is required in order to provide interoperability with legacy RTP devices and software that do not support encryption. In addition, some use cases such as high-volume PSTN or PBX gateways within an organization may scale more readily without the overhead of media encryption. An RTCWEB client MUST provide its user with the ability to know whether or not the media they are sending is protected by encryption and with the ability to see keying material information sufficient to allow indepent verification of their peer's identity. (REF draft-kaufman-rtcweb-security-ui). Note that this user interface element is much more critical---and hence much more problematic than with alternative A. If DTLS-SRTP is always used, then the user knows what security mechanisms are provided. As soon as multiple alternatives with widely varying security (or no security in the case of RTP) are provided, then users need to actually verify that the security level is satisfactory, which is inherently problematic given typical user behavior. I expect to leave time for discussion of this during my slot tomorrow. I look forward to a good discussion. Best, -Ekr

3 3

Reminder: rtc-web list is closed, use rtcweb@ietf.org or public-webrtc@w3.org
by Harald Alvestrand 12 May '11

12 May '11

Just in case someone is reading this list and not reading the others: Both lists currently have outstanding calls for response with regard to future meetings and working methods. Let your voice be heard! This list, on the other hand, is at the end of its useful life, and will be closed. Harald

1 0

Possible RTCWeb interim meeting
by Cullen Jennings 03 May '11

03 May '11

The just approved IETF RTC Web WG is considering having an interim meeting. To find out more, give your input on dates, etc, go join the rtcweb(a)ietf.org mailing list. You can join at https://www.ietf.org/mailman/listinfo/rtcweb Cullen

1 0

Fwd: W3C mailing-list [was Re: Updated W3C draft charter for Web RTC WG]
by Harald Alvestrand 12 Apr '11

12 Apr '11

This is to be the official public list of the (still in-formation) W3C WG for WebRTC. Welcome! Harald -------- Original Message -------- Subject: W3C mailing-list [was Re: Updated W3C draft charter for Web RTC WG] Date: Tue, 12 Apr 2011 08:48:09 +0200 From: Francois Daoust <fd(a)w3.org> To: Harald Alvestrand <harald(a)alvestrand.no> Hi Harald, The public-webrtc(a)w3.org mailing-list is up and running. To subscribe to the mailing-list, one needs to send an email to public-webrtc-request(a)w3.org with subject "subscribe", or click on the "subscribe to this list" option on the archives page. The archives are available at: http://lists.w3.org/Archives/Public/public-webrtc/ Francois. On 04/07/2011 11:27 AM, Francois Daoust wrote: > On 04/07/2011 10:50 AM, Harald Alvestrand wrote: >> Francios, >> >> a) waiting for anything from me? > > No, I'm waiting for replies from reviewers to my own replies [1] before I can get back to W3C management with a disposition of comments to ask for their formal approval of the changes and chairs nomination. > > David Baron's already replied that he's ok with the proposed changes, so I'm waiting for Chaals feedback in particular. Not a big deal if we don't hear back from other reviewers. > > >> b) are things firm enough that we can create a public-webrtc-whatever(a)w3.org mailing list and start using it for API discussions? > > That's usually done when the group gets created, but we can certainly do that before, yes. I've just requested the creation of a public-webrtc(a)w3.org mailing-list. It may take a few days for this request to be processed by the systems team. > > Francois. > > [1] http://www.w3.org/Search/Mail/Member/search?keywords=daoust&hdr-1-name=subj… > >> >> Harald >> >> On 04/04/11 11:11, Francois Daoust wrote: >>> Hi Harald, >>> >>> It took some time for lack of time and connection last week, but I've eventually made a few changes to the W3C draft charter for Web RTC. See latest version at: >>> http://www.w3.org/2010/12/webrtc-charter.html >>> >>> The diff is available at: >>> http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2010%2F12… >>> >>> List of changes: >>> - liaison with Web and TV IG (for home networking scenarios) added >>> - "any new" added to the mention that audio and video codecs are out of scope to respond to Art Barstow's comment, as that seemed benign enough. >>> - milestones section completed. Let me know if you have comments on this initial roadmap. I've merged all functions into one single row to keep things simple. >>> - decision policy copied from HTML charter >>> - deliverables section completed to put more emphasis on collaboration with IETF without mandating any specific text, using similar wording as that of the latest IETF RTCWeb group's charter. >>> >>> (Note the diff tool loses itself near the end: only the decision policy section has been changed) >>> >>> I stayed silent on the relation with WHATWG, and also did not introduce any change in the charter to address Stefan's detailed comments (e.g. "There must be support for media format negotiation and selection in the solution") to leave that as discussion for the group. >>> >>> Could you review the changes and let me know whether that looks good for you? >>> I've read the BoF notes taken by Christer Holmberg. Any other input from the IETF BoF meeting that would trigger additional changes in the charter? >>> >>> If you're fine with the changes, I'll get back to reviewers to get their approval, and to W3C Management with a disposition of comments to have them approve the charter and the WG chairs. Depending on the time it take to get reviewers approval, the decision could be taken this week, next week or the week after that (on Wednesday, each time). The group's creation can be officially announced shortly after that. >>> >>> Do you have a timeline for the creation of the IETF group? Having both groups created at the same time might be good if that's not too much of a pain to do. >>> >>> Dan Burnett proposed himself as co-chair for the Web RTC group. Dan has a good experience of W3C groups and is already chair of the Voice Browser working group and of the HTML Speech Incubator Group. On the minus side, he already has quite a few W3C activities on his plate. I do not know well Dan and Stefan. It doesn't make sense to have 3 chairs for the group. Do you have a strong preference? >>> >>> Who would be the chairs of the IETF working group? >>> >>> Thanks, >>> Francois. >>> >> >>

2 2

Audio recordings of sessions
by Harald Alvestrand 08 Apr '11

08 Apr '11

Here are the links: http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch3-tues-am.mp3 and probably: http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch5-fri-pm.mp3 but the session does not start at the beginning, and my Linux tools fail to seek... Harald

2 2

Updated mailing list; please re-subscribe
by Ted Hardie 05 Apr '11

05 Apr '11

In case you are not on the DISPATCH mailing list, our AD recently posted this: Subject: RTCWeb mailing list Date: Tue, 05 Apr 2011 10:57:07 +0300 From: Gonzalo Camarillo <Gonzalo.Camarillo(a)ericsson.com> To: DISPATCH <dispatch(a)ietf.org> Hi, FYI: as part of the chartering process, we have created the following mailing list: http://www.ietf.org/mail-archive/web/rtcweb/current/msg00001.html This mailing list is intended to be the mailing list of the RTCWeb WG-to-be. From now on, RTCWeb-related discussions should happen on the newly-created list. Note that the RTCWeb charter is still under IESG/IAB review. Cheers, Gonzalo *Pleae subscribe to the new list and continue discussion there.* * * *Thanks,* * * *Ted*

1 0

Fwd: Updated Charter for RTCWeb
by Harald Alvestrand 02 Apr '11

02 Apr '11

The revised charter, incorporating what we were able to remember from the BOF. This has now been sent to the IESG for their one-week review. Harald

3 3

Ad-hoc RTCWEB meeting (Fwd: [dispatch] DISPATCH Ad-HOC meetings about VIPR and RTCWeb at IETF 80)
by Harald Alvestrand 01 Apr '11

01 Apr '11

Friday 1415-1515 in the Grand Ballroom. -------- Original Message -------- Subject: [dispatch] DISPATCH Ad-HOC meetings about VIPR and RTCWeb at IETF 80 Date: Tue, 15 Mar 2011 11:45:13 -0600 From: Cullen Jennings <fluffy(a)cisco.com> To: DISPATCH list <dispatch(a)ietf.org> The dispatch WG will have two ad-hoc meeting. The first is discuss the technical content of the drafts related to the proposed VIPR WG. Tentative time: VIPR's is in Tyrolka on Thursday 1300-1400 The second is to discuss the technical contents of drafts related to the proposed RTCWeb WG. Tentative time: RTCWeb's is Friday 1415-1515 in the Grand Ballroom Send Agenda requests for time in either of these to Mary and I. Thanks, Mary& Cullen _______________________________________________ dispatch mailing list dispatch(a)ietf.org https://www.ietf.org/mailman/listinfo/dispatch

2 1

IETF#80: RTCWEB BoF notes
by Christer Holmberg 31 Mar '11

31 Mar '11

Hi, Below are my notes from the RTCWEB BoF. Regards, Christer --------------- Collaboration with W3C: -------------------------- - It was noted that while IETF has the network expertise, W3C has the API expertise, and that collaboration between the group is important. - It was indicated, as there are people active in both IETF and W3C, it is better to rely on active collaboration driven by individuals, rather than sending liaisons between the SDOs. - Is was questioned whether IETF and W3C have different IPR policies. - It was indicated that the security model also needs to be defined in collaboration with W3C, as there are web security aspects that IETF might not have good knowledge of. - There was a question whether document produced by IETF and W3C needs to be approved by both SDOs. It was indicated that hopefully there will not be a need for both groups to formally approve documents of the other group, but each SDO should follow and review the work of the other group. - It was commented that we might need to establish a collaboration also with the WHAT WG, rather than relying on W3C for the WHAT WG collaboration. Use-cases and requirements: ----------------------------- Presenter: Christer Holmberg - The presenter indicated that we need to, in order to produce API requirements, agree on the functional split between the browser and the web-app. - The presenter indicated that NAT/FW traversal also contains a mechanism to perform media fallback (e.g. HTTP fallback). RTC-Web Framework: ------------------------- Presenter: Jonathan Rosenberg - The presenter indicated that, as the browser and web-app in most cases are produced by different organizations, we should look at the API between the browser and web-app as a protocol. - It was commented that we need to be careful with terminology, as an API does not dictate a protocol. - It was commented that the API should not be too complex for web application. It was suggested that the API might have different levels of complexity. - It was indicated that the browser application itself might not implement the features it offers to the web-app. Some features might also be offered by the OS, where the broswer simply provides access to those features to the web-app. Web Security: --------------- Presenter: Eric Rescorla - The following security areas, related to rtc-web, were identified: -- Media remote peer verification. -- Access to local device. -- Communication security. - There was a comment that identity also needs to be covered. However, in all use-cases identity might not be needed, or even desired. - It was questioned how we can prevent an application, claiming to be a browser, from sending date before getting consent. It was indicated that such scenario is outside the scope of the WG. Negotiation and Extensibility ---------------------------- Presenter: Cullen Jennings - The presenter indicated that the solution must be extendible, and it must provide a mechanism which allows the negotiation of different features. - It was indicated that full legacy interoperability might not be possible, mostly due to security constraints, without intermediary functions on the media plane. - It was indicated that the WG needs to decide on the level on legacy interoperability. Charter: -------- - A large number of individuals had read the proposed charter text. - There was a question whether document produced by IETF and W3C needs to be approved by both SDOs. It was indicated that hopefully there will not be a need for both groups to formally approve documents of the other group, but each SDO should follow and review the work of the other group. - It was commented that the charter does not talk about legacy interoperability. - It was commented that none of the presentations have described the handling of non-RTP connections. It was indicated that the MG might want to consider sending also non-audio/video data over RTP. - It was commented that the charter should not contain a list of features that might be added to the charter at a later point. Poll: ----- - Willingness to review documents: approx 50-60 individuals. - Willingness to write and provide text to documents: approx 24 individuals.

1 0

My biggest concern
by Robin Raymond 31 Mar '11

31 Mar '11

I've been quiet on the list and perhaps this has already been discussed. My primary concern has to do with the way users interact with their browsers and tying the lifetime of the streaming sessions to the javascript on a webpage. Given the proposals, javascript will likely be used to setup streaming sessions and thus there will need to be automatic clean-up of these sessions when the related javascript objects are closed when a website page is "closed". This in my opinion can cause major issues with users. In my own situation, I have a list of common viewed websites at the top of my browser and a simple accidental click will go to those new pages. I frequently click on those pages accidentally. If I'm simply viewing email, no big deal, I hit the back and while I'm annoyed I can easily recover. With a call in progress this will no longer be the case. The entire session state will be destroyed, the calls will tear down immediately as a result of the lifetime of streams being tied to the lifetime of the javascript objects on the page. I think practically speaking this will happen often. Users will be in a call with each other and say "have you seen that new cool video", and most non tech savvy users will simply type the search into their browser window and their search bar and the browser javascript will be torn down and bring down all the RTP streams thus ending any active communication as a result. How annoying it would be to have established calls torn up/down based on typical browser usage by a user! Expecting users not to navigate while calling is impractical and expecting users will open new browser tabs will be unworkable, especially to anyone like me has had to support family members confusion over browser tabs and accidentally closing what they are working on... I think the depth of this issue is unique to RTC-WEB proposal. Of course, I've seen this issue with videos and other places - where you are in the middle of watching a video, click to a new page and then come back to have the video start over and if it doesn't index itself properly will have to download and play from the beginning. Youtube has done a lot to solve those usability issues by doing many intelligent work arounds and keeping currently locations pretty accurate when going "back". But I fear no such work arounds will be easy or possible with RTC-WEB and solutions could open up new cans of security worms. For example, reopening a closed page with the "back button" could cause re-open a previously accidentally closed media sessions but could also open an intentionally closed sessions. Re-opening the connection automatically based on going "back" to a previous page could be embarrassing if you did actually intend to end the call and then the microphone was re-opened automatically broadcasting to the previous person you were connected. To keep media sessions alive even as users click around implies the lifetime of the call exists outside the active browser page. But this opens up other issues. For example, when does the call get automatically torn down if they leave the site? Or where are the controls for the call going to exist outside the site if the page with the controls is closed? (and the browser would have no understanding of what controls should be presented when navigating off the page since every website will have their own call control definitions). So maybe I'm missing something important like other browser future technologies introduced in conjunction with RTC-WEB (e.g. application based web sites) but I don't understand how RTC-WEB is going to get around these javascript-tied-to-a-webpage lifetime issues... Regards, Robin Raymond hookflash

9 13