Minutes for RTCWEB at IETF-interim-2012-rtcweb-1
minutes-interim-2012-rtcweb-1-00

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.