[rtcweb] Draft minutes for 82.5 meeting

[Cullen Jennings <[e-mail]>]

Here is a draft of the minutes for the last interim meeting. Please let us know if any corrections are needed by the end of Feb 22. Many thanks to Mary, Alan, and Ashish who took the minutes. 

Thanks, 
Cullen, Magnus, & Ted




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.