Minutes for RTCWEB at IETF-94
minutes-94-rtcweb-1

RTCWEB Minutes IETF 94
Chairs:  Cullen Jennings, Sean Turner, Ted Hardie
Scribes: Wendy Seltzer, Patrick McManus, Bo Burnum

Tuesday 9:00-11:30

Review JSEP Issues
See slides (https://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-1.pdf)
and associated github issues (https://github.com/rtcweb-wg/jsep/issues)

Significant discussion around rtcp-mux. Decisions in room was that if bundle
was being used, then rtcp-mux MUST all be used. The implications are that when
bundle is negotiated, the RTP and RTCP will always be on the same port. The
main argument for this was it reduced complexity in the browser code. The only
major concerns raised was the impact on gateways that translate between WebRTC
with bundle and DTLS-SRTP on one side and older style SIP on the other side.
Justin’s measurements showed about 1% of current connections are using bundle
without mux. 
(https://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.pdf contains the
text update).

There was strong consensus in the room for this change.

This way forward will require a new IETF Last Call, as it changes rtp-usage,
which is the RFC Editor queue.

Review IP address leakage

The group first reviewed the discussion which had taken place at TPAC, which
proposed 4 levels of candidate revelation.  (see slide 15 of the JSEP slide
deck).  The group then discussed whether this met the security and privacy
goals of the group and how to move forward.  The group agreed that very
restrictive and very permissive approaches could be adopted by an application
after user installation of a plug-in or extension, so focused on the default
case.  A proposed  guideline is that WebRTC apps should be allowed to reveal
whatever HTTP would reveal.  Candidates beyond that remain contentious.  The
group agreed to an experiment to distinguish the usability of restricting to
the host candidate versus using the default plus the like RFC 1918 or RFC 6598
address.  Further discussion of IPv6 link local or ULA addresses is needed, but
the same guidelines will be used.

At the direction of our AD, this will be documented in a separated draft, so
that it can proceed after data on the results are available.

Thursday 15:20-16:20
Draft-ietf-rtcweb-audio has expired and will be updated.
Draft-ietf-rtcweb-audio-interop will go for WGLC as informational just after
this meeting. WG chairs solicit the WG to review draft-ietf-rtcweb-fec. Magnus
Westerlund has reviewed and just needs to type it up. Mo Zanaty will review
too. Christer Holmberg informs that he has submitted a draft how to signal
support of RTCP mux-only to MMUSIC list. Review MMUSIC simulcast There have
been a few decisions in MMUSIC. The main change is that RID is now the only
identifier for simulcast, which simplifies simulcast negotiation. There will be
an update to the document in the next few weeks. Peter T: we need the resulting
SDP O/A text to import into JSEP. Mo: will post to the list. Justin: will take
this into JSEP as soon as simulcast and RID documents are stable. A hum decided
to adopt simulcast in the way currently outlined by the simulcast and RID
drafts (editor’s note: assumedly including the described changes that were
described here but are not edited into the documents yet). Security drafts
SecDir comments Draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security A
consensus call was made to adopt ECDSA instead of RSA, by taking a first hum if
the room understands the topic; significant response. After a bit of
discussion, it was asked if anyone objects to have both as MTI and no one
objects. So, it was decided to have both MTI by keeping RSA while also adopting
ECDSA as MTI. Regarding the received SecDir comment to section 5.2, Martin
Thomson accepts the token to handle screen sharing security in W3C. Other
agenda requests None.

Raw Notes:

rtcweb

9:00-11:30  Tuesday Morning session I

JSEP- 120 minutes
EKR: joint work with Justin and Cullen
https://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-1.pdf
planning to talk about the things with *s
Filled in setLocal and setRemote (*)
Clarify ICE default candidates during gathering (*)
Clarify downscaling and upscaling rules
Update SDP modification rules
Updated to latest datachannel SDP.
Allow multiple fingerprint lines
Dummy candidates use IPv4 (again) between Scylla and Charybdis.

Applying local descriptions (S 5.7) [slide 3]
Applying remote descriptions (S 5.8) [slide 4]
we considered writing a big if statement, but

Jonathan Lennox:
EKR: CreateOffer is a stateless operation
So you can't change the password

Applying answers (S 5.9) [slide 5]
Is anybody bent out of shape by all that. Seeing no one, move on.

Default Candidates [slide 6]
We were running into people who were sad about completely bogus values
● Proposed rules
○ If no candidates gathered, use dummy [existing]
○ If some candidates gathered use “best” [not in draft yet]
○ If any candidate pairs have completed, use the one in use [new]
○ Once ICE is completed, use selected pair [RFC 5245]

TedH: why not say "if some candidates are gathered, use any" rather than best?
EKR: less about state machine than not flip-flopping
TedH: you're unlikely to get the one you're ultimately likely to want to use
EKR: true in 5245; if every time a new entry comes in, you pick the 5245
default, then repeated queries will give different results. TedH: churn of
re-doing when you get new candidates is a bad idea Peter Thatcher: could we
just say first? EKR: yes. Peter: In JS, you'd call setLocal, CreateOffer...
Jonathan Lennox: trying to avoid triggering ICE mismatch. so put any valid
candidate. EKR: if we think churn is bad, either pick any and stick with it, or
pick the first. JL: latter is an implementation of the former, so pick the
former. EKR: ok, pick one and stick with it. EKR: on the proposed rules 1,3,4,
are find. 2. if some candidates are gathered, pick one and stick with it in the
c line until completed EKR: these have to be things already in candidates. If
there are any candidates in SDP, one must appear in the C line. where this
comes up is applications trying to talk to @

Default mux policy [slide 7]
some discussion at last IETF, always do mux
Cullen: option 2 entirely, or in bundle?
EKR: forbid non-mux entirely.
Peter: option 1, default for the policy
MT: you said obviously default should be require; it's not so obvious
EKR: we're trying to move to a much-mux world. cost, gather twice as many
candidates; people who don't want mux have to do a bunch of stuff, turn off
bundle. MT: default policy of balance isn't necesarily true EKR: we want to do
field measurements, see how many people set it. MT: by only measuring mux,
we're under-measuring non-mux Magnus: in non-bundle case, EKR: I'm trying to
reflec in the editor's draft what people want. Christer: decision in MMUSIC
that when you use bundle, you must use mux. Where remote doesn't bundle, must
have possibility for non-mux EKR: in balance policy, still do mux gathering
Justin: I haven't heard argument for why to support non-mux. Measurement, about
1% of sessions using non-mux. Don't keep it around just because Magnus: reason
for non-bundle, non-mux is care for legacy cases. 1 media stream per
media-type. Peter: speaking to an endpoint that does DTLS already. How many
endpoints do ICE but not mux? Justin: still not clear where non-mux rtcp is
valuable. opportunity to throw away complexity we don't need. Why do we support
this now and in the future. Christer: there are platforms that want it Justin:
this is technical complexity we'll have to keep for a long time MT: re Justin's
argument, browsers dont' want to carry this stuff. Tension between those who
are happy to change their code, and those who arent EKR: but it's different to
take out functions vs put them in. Component structure of ICE is a major
barrier to correct implementation. Both ICE and JSEP stack would be made
easier. Justin: since it's easeir for the stack, should have a clear technical
benefit to override Magnus: "forbid" = not required ot implement non-mux EKR:
but then every browser won't do it. Magnus: @@ EKR: do we have a sense of how
many systems that don't now need gws would need gws under this scenario?
Magnus: IMS clients Jonathan Lennox: you say implementing multiple components
is hard, why? EKR: affects the API. ICE context with media streams, components
hanging off. collapse the data structures. Scheduling algos are complicated
Jonathan Lennox: if you don't care about odd/even, ... Ted Hardie: question
about data. For the 1% currently doing non-mux, clear; can you tell us anything
about number of instances of people doing non-bundle, mux? Peter: currently
don't support the other. so all the cases of bundle TedH: So bundle mux woudl
have to change. that's a lot. Peter: none are impacted by MMUSIC. If you
bundle, you must mux. Peter: very complex implementation, separate layer of
abstraction. MT: not so difficult when implementing an ICE stack, just a thin
veneer EKR: no, this is a first-class object. MT: state of an M line creates
problems. Option 2 is cleaner. EKR: I hear people sad about Option 2, but I
can't tell how sad. Can anyone who can't live with Option 2 tell us that?
Justin: re 1%, that's an upper bound of people who'd break.

Cullen: we have a proposed slide on the fallout from MMUSIC, put that on the
screen now. TedH: what the chairs are thinking:
        If you have new technical arguments why you can't support this, come to
        the mic, Then a set of hums.

Magnus. proposed change to rtp-usgage.
EKR: impact of this change will be that no browser does non-mux. effectively
pulling non-mux from the web. Christer: if you still have the MAY support,
still have to do some SDP work. EKR: already the case you can configure the
browser only offer mux. If the other side doesn't support, you fail
negotiation. Christer: if you include RTC mux, only include RTP... Need to sort
out the signaling Colin: this basically says feel free to implement other
things if you feel like it Cullen: in some environments, you can use diffserv.
Some you can't. Does this make it difficult to deploy prioritization if you
can't split these up. Browsers aren't working in that environment; other
devices are. TedH: do the QoS signalings match? Cullen: in practice, they often
don't for scheduling on deterministic networks. detnet. widely supported across
nats, IOS. scheudling audio on deterministic timeslots. EKR: 1.75, apply this
chagne Option 1, and do the cascading change to allow browsers to ignore mux.
Magnus: I like the proposal that we should be able to do some signaling.

TedH. RTP usage draft is in editor queue. Seems that some of these changes
cause implementation-specific changes. Sean: You can re-do another WG LC.
Alissa: Just do IETF LC TedH: we'd re-run IETF LC for RTP usage for just these
changes.

TedH: Hum if you undersatnd the problem. [hum]
I think we have people who understand the problem.

TedH: MMUSIC decided on their list, when you do bundle, you must do mux.
decision here is whether to go to default mux.
Does anyone have a problem moving to default mux. [silence]

two positions past that. 1.75, implementaiton smay or may not support non-mux
or implementations must not support non-mux.

EKR: stop now, or apply change Magnus suggested. non-mux is optional.
@ what would be change to JSEP
EKR: implementaions require default, may error otherwise.

TedH: should support for non-mux be optional.
EKR: Case A: implemantions must support non-mux; Case B: implementations may
support non-mux Harald: Option to implement non-mux, API surface doesn't get
less complex. Implementation may, but not API.

@@: can you write a slide with draft text?

TedH: does anyone have a problem with making non-mux optional.
lots of resigned sighs, but no one saying yes.

https://github.com/rtcweb-wg/jsep/pull/183/files
[new} Implementations MAY choose to reject attempts by the  application to set
the multiplexing policy to "negotiate"

TedH: does anyone have a question?
Christer: this means you'd reject an incoming offer?
EKR: yes

TedH: do you support adoption? [hum]
do you oppose adoption? [silence]

TedH: RTP usage change.
support [hum]
oppose [silence]

TedH: RTP usage will go through second IETF LC with this text called out.
EKR: to my co-authors, please feel free to merge this PR

MT: we still have a separate decision we could make to remove the policy. It
would be difficult, but possible. I'd like to remove the frog.

#162: RFC 5888 (AGAIN!!!!) [slide 8]
Justin: Does this look right?
Cullen: yes, matches what I expected. Most legacy equipment woudl have accepted
this at step 2; I doubt it would work at reoffer, but doesn't matter much. This
is a weird edge case. Justin: what about re-offer if audio and video were not
in a single stream. Cullen: if you did 2 gum and got them unsynchronized, then
you'd fall out here. I think this is fine, even though it won't interop with
some legacy equipment. Justin: 3 options. this; go with offer; allow lipsync
groups to be unilateral. Cullen: Either would be fine. MT: recent API changes
such that you see less synchronized tracks entering the API. I suspect as a
result, you'll find tracks entering peer connection will be unsync, so we'll be
forced into reoffer.  I wonder why you have two send-only Cullen: I hope that
browser-to-browser Hello World should result in lip sync happening. Justin:
change to add track from add stream MT: we're not deprecating add stream.
Cullen: change is trivial Roni: grouping is sender-side, not receiver. Justin:
Lipsync group reflects sender's desire to have audio and video synced. EKR: I
would have assumed callee's option is to say "I don't care about sync" My
understaind of the API. If I do gum, they're synchronized Justin: you do have
to specify stream parameter Jonathan Lennox: What does a browser does if it
gets no LS group? Justin: it will assume that everything is synchronized JL: I
have live audio and video; you have live audio and screenshare; that's a
reasonable case.

TedH: look back to IETF93 slide, next one. Question about legacy equipment, any
additional comment? Anyd Hutton: almost certainly no. Cullen: you've taken
audio stream it expects to be bidirectional, and that'll cause problems. Andy:
History fo multiple audio M lines is problematic in legacy equipment Cullen:
this one doesn't bother me. Simpler might be just reject @@ Justin: some
semantics for groups can be unilateral; that's changing the rules. Cullen: that
seems more complicated, not much better, probably still won't work with legacy.
Cullen: proposal on the table, one path forward. Unidirectional vs negotiated
bi-directional? Any guesses how long that would take? Justin: I think we need
to reformulate the proposal if we go down this path. simple case, if
offer-answer differ, then there's no syncing Cullen: that sounds like the
simplest way to get 1.0 out JL: it makes me a bit sad to say, because I have a
screenshare, I see your audio-video out of sync. Justin: Application has
control over this; transceiver APIs, with more work for application. Separate M
section. JL: if there's a way for API to get it right, ok. it seems more
complicated. TedH: as chair, I favor what lets us complete our work. Simplest
solution is not to adopt this; but if you can't make it work, simply reject
Justin: I'll take an action to see if screenshare can be handled by the
application TedH: at our next meeting, there will be a PR? Justin: yes.

Updates to the Object Model [slide 10,11,12]
Peter: also, blows away any receiver state
[slide 13]
MT: @@ about half-dead receiver

@@ is getting lost @@

EKR: text consistent with agreement at TPAC
Adam: Does anyone disagree? [no]
Justin: this requires JSEP update.
MT: at a minimum, track becomes ended.
Peter: depends on what effect removeTrack has.
Justin: work through an example
MT: do you think the signal is valuable? what indication do you want to provide
when you really stop sending.  I don't think msid is quite strong enough
Justin: you might never be able to clear out. ACTION to figure out what we do
there. Also what happens on the API side, when track stops, is re-added.

[slide 14]
coupling between transceivers and mids.
MT: this is good. We have problems if we don't have unique bindings. Collisison
problem, confusion at application layer. Justin: hearing no concerns , I move
that we do this.

=Candidate gathering procedures and Privacy

[slide 15]
Talked about IP address leakage.
JL: proxy mean web proxy? Justin: yes.
JL: we've always had vague notion that TURN server is topologically equivalent
to proxy. TedH: is there no way you'd allow someone to set a preference that
would make consent a default? Justin: you could imagine extension saying
"always give me everything behavior" TedH: should something always BE VISIBLE
TO THE USER EKR: @@ Wendy: What about the case where the user wants audio-video
only if it can be done without disclosing anything? Justin: they can do that
with a plugin TedH: there are places where IP includes location. DKG: IP
address shoudln't be conflated with voice and video. Voice and video are
transmitted to the peer; EKR: you might wish that, but in most cases, voice and
video will be transmitted anywhere website is. DKG: isolated media, then voice
and video going only to peer; whereas address is going to everyone on the path
JL: restricted gathering 1, should it use fallback that the browser would use,
eg. Safari? Justin: binding to the wildcard? JL: parking lot problem. Justin:
agree we should be mirroring HTTPs behavior. JL: hopefully browsers doing that
fallback aren't for VPNs. Don't reveal anyhing HTTP wouldn't do. Justin: what
is Apple doing? advising people to use higher level APIs? JL: roughly happy
eyeballs MT: at TPAC, Adam noted they were handing out IANA-reserved CGN
addresses. Those address spaces have some characteristics in common with 1918.
Propose to treat it like 1918. TedH: Although it was set aside for CGN, it's
widely used for other things Justin: so what interfaces should in fact be
gathered. should we treat 1918 specially.  Measurement. JL: I'd be reluctant to
change the pairing algorithm. I'd do what goes on the candidate list, not the
algorithm EKR: you can't do that JL: I'd say option 1. Cullen: in this
experiment, exactly the networks in which you'd be most interested won't be
reporting data. TedH: pair 1918s with like, construction of experiment will be
interesting. disjoint or conjoint RFC 1918 ranges adminisitrative domain,
routing domain, not visible to the endpoint. if you merge all 1918 addresses,
you'll definitely exfiltrate where you shouldn't. Please have some privacy and
routing folks in the construction of the experiment. Justin: I am worried about
exfiltration. EKR: there a version of 2 that is safe. MT: not necessarily.
masking on /8 vs /24 EKR: if you're configuring local networks that way, you
deserve it. TedH: but the person impacted by the configuration isn't the same
as the person configuring it. EKR: but you're dependent on the goodwill fo the
administrator. Justin: we also need to figure out where the text ends up
Cullen: where you're depending on NAT for privacy, you must think something
about the admin of that NAT TedH: Configuration is only sometimes safe, where
configuration of the network met original goal. Sean: we're out of time.
Justin: which option, and where does text go.

​
IP handling
ted to AD - what do we need to in order to take on board the result of the IP
handling discussion - do we need to bring that into the drafts or progress the
drafts.. alyssa says keep ip stuff in separate draft because jsep will finish
one day and there will be experimentation and that ip stuff may change and you
would not want to update jsep - keep it separate. ted says it will not progress
immediately as it will wait for data to come in. uberti says that’s ok - but
the interest was probably wrt the security documents rather than jsep. ted
notes security documents still in flux. uberti asks if we need a wg action
about whether to take it forward as wg action. lots of humming in support of
adopting to be confirmed on list.

uberti - needs another review before LC of FEC draft.. magnus has notes.. mo
and paramour(?) also volunteer

mo reports older payload based identifiers are going away from simulcast and
rids are mandatory - expect in the next few weeks (mmusic)

peter thatcher(?)  what about sdp definitions? mo says [???]

rtcweb security [not recording sean’s slides]
ekr notes ecsda by default is imminent in chrome/ff
hum on whether room understands changing mti from rsa to ecdsa is strong
cullen asks whether making both mti is an option. ekr and mt say they’re ok. mt
asks if there is an objection to just ecdsa. harald: concerned about interop
with old spec implementations. mt: ff already made change and found problems
with very old versions of webrtc.org code which did not enable ecdh which
impacted cipher suite selection. harald: my concerns are addressed justin: need
to be able to support receiving ecdsa - mumble cullen: supports making ecdsa
MTI, not sure about removing RSA as MTI due to old impls ekr: would not be
shocked to find old implementations that only had rsa - but doesn’t think
people will remove rsa just because it isn’t mti.. ekr is ok with both as mti
cullen: would like boh as mti anyone object to both? no one comes forward -
sean declares it done.

secdir discuss s4.1 initial signaling
ekr: point 2 is wrong. the spec is designed to avoid that. point 1 is the ip
address privacy topic. GNT delivered to chairs ekr: data goes into the
javascript - can’t prevent exfiltration. chrome is doing gum only in https
origins. we could have a rule that says peerconnections ony in https origins -
but the consensus was not to do that years ago. should we revisit? uberti: only
considering gum chrome ekr: says we already had that argument and was voted
down alyssa: write down the other argument ekr: primary argument is as a
practical matter gum/https won’t be possible to do a video call with a http
origin

comment 5.2
ekr: browsers require external code/pref to allow full screen as a matter of
fact mt: separate prompt for screen sharing ekr: there is some non compliance
here depending on platform mt: suggests taking it out of here, and move
screensharing to w3c which is still working on that harald: throw it over the
fence bernard: agrees with mt - w3c problem ted: ok w3c. worries it does not
treat mobile app systems correctly cullen: works for me. but not a good idea to
publish documents that say you should do stuff implementations are not
currently doing alyssa: screen sharing threats are in the security docs -
update that to say these are dealt with in the w3c document alyssa gives
endorsement of going to w3c

comment s5.5
ted: you could do this with a wire,
ekr: second point is silly. you could imagine that B was imitating A and you
would want to know which source was outputting the media, but not practical to
do so ted: screenshare is the key concern. but decorating in the UI isn’t up to
us. but its good as a security consideration so the app writer can decide to
deal with it wolfgang: is the identity the ip address or a name.. are there
applications where it is desirable not to have an indication (working group hum
as an example) ekr: webrtc isn’t going to do that even if desirable patrick
linske: app level problem not spec level problem

comment s 5.7.1
ekr: answer is no
mt: draft says we have to treat rhs as a domain name with idn

comment s6.3
ekr: if we signed the whole thing people would be sad - they drop codecs, etc..
that’s the way sdp is

comment 6.4.2
ekr: if you have a server that doesn’t understand well-known you will have a
bad day already not limited to this

comment 6.4.5.[12]
ekr: this text is old and moot

secdir general
ekr: insertion thing is completely opaque.. idp that can and idp that can’t is
intentional mt: by default new cert fr every call which limits replayability
ekr: idp job to take care of replay

To be continued Thursday.

15:20-17:20  Thursday Afternoon session II

​
RTCWEB
Thursday 15:20-16:20
Draft-ietf-rtcweb-audio has expired and will be updated.
Draft-ietf-rtcweb-audio-interop will go for WGLC as informational just after
this meeting. WG chairs solicit the WG to review draft-ietf-rtcweb-fec. Magnus
Westerlund has reviewed and just needs to type it up. Mo Zanaty will review
too. Christer Holmberg informs that he has submitted a draft how to signal
support of RTCP mux-only to MMUSIC list. Review MMUSIC simulcast There have
been a few decisions in MMUSIC. The main change is that RID is now the only
identifier for simulcast, which simplifies simulcast negotiation. There will be
an update to the document in the next few weeks. Peter T: we need the resulting
SDP O/A text to import into JSEP. Mo: will post to the list. Justin: will take
this into JSEP as soon as simulcast and RID documents are stable. A hum decided
to adopt simulcast in the way currently outlined by the simulcast and RID
drafts (editor’s note: assumedly including the described changes that were
described here but are not edited into the documents yet). Security drafts
SecDir comments Draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security A
consensus call was made to adopt ECDSA instead of RSA, by taking a first hum if
the room understands the topic; significant response. After a bit of
discussion, it was asked if anyone objects to have both as MTI and no one
objects. So, it was decided to have both MTI by keeping RSA while also adopting
ECDSA as MTI. Regarding the received SecDir comment to section 5.2, Martin
Thomson accepts the token to handle screen sharing security in W3C. Other
agenda requests None.