Minutes IETF103: rtcweb
minutes-103-rtcweb-00

RTCWEB Agenda, IETF 103
Chairs: Cullen Jennings, Sean Turner, Ted Hardie
Responsible AD: Adam Roach

Note taker: Jonathan Lennox

Administrivia

Note well presented.  This note taker claimed (falsely) never to have seen it
before.

Cullen stepping down as chair.  Presented with fine and less fine whiskey.

Issues raised during AD review of sdp, security, security
architecture, and IP handling drafts (Adam Roach)

Security-arch

Invalid identity in initial answer:
Proposal: Tear down session.  No objection.

Invalid identity in updated offer:
Martin: is this if there previously was identity, or not?
Adam: Not sure
Martin: I think it says in the W3C doc
Adam: We should be consistent with that, replicate its document

Martin checks W3C doc.  It says it triggers an error.

Invalid identity in updated answer:
...

Conclusion: treat every invalid offer/answer the same way. 
SetRemoteDescription fails.  Up to web app as to what to do next.  Default is
to remain in previous state.

Christer: if you previously had identity and then you don't, what happens?
Martin: Identity says it's up to the app.  W3C doc says it's a fatal error.

EKR: What my doc says is that invalid offer is rejected, invalid answer is tear
down. Martin: That's not what W3C doc says EKR: Then they're wrong Nils: That's
different than every other SDP error Harald: It would be quite new to have
errors cause a transition to close; every other garbage shoved into
setRemoteDescription causes it to do nothing. EKR (or Zanzibar Buck-Buck
McFate): Then the answer to question 1 is also stay in initialOffer state?
Adam: The problem is we're trying to use 3264-style handling here, but the 3264
handling is in the JavaScript. Proposal: If the identity is invalid, it's
treated like any other invalid SDP. [agreement]

DTLS MTI Version:
Different docs say MUST, SHOULD NOT, MUST NOT do DTLS 1.0.
Martin: we should mandate DTLS 1.2, don't mention anything else.
Ted: Should we reference oldversions-deprecate?
Martin: No. Don't pull anything else into Cluster 238.
EKR: Two possibilities: Mandate no 1.0 ourselves, or else let
oldversions-deprecate do it. Ted: Any objection to deprecating 1.0 ourselves,
without reference to oldversions-deprecate Bernard: A very large user of a
forked version of an old libwebrtc has been using DTLS 1.0 for a long time. 
(The world's largest provider of webrtc services).  As of the last tiem I
looked they hadn't moved to DTLS 1.2. Martin: I don't expect browsers to turn
this off tomorrow, but I think this working group can create their own signal
that we no longer consider this good.  We can give large deployments
encouragement. Cullen (from the floor): Don't confuse MTI with what's
deprecated.  I can certainly imagine our MTI is 1.2, but there are *several*
large deployments of 1.0. EKR: Break this up into pieces.  First, make 1.2 MTI.
Ted: Any objections to this? Cullen: Adding 1.2 to MTI list, or the only MTI?
Ted: I don't want anyone new to implement 1.0 EKR: Currently, doc has two
parts, MUST 1.0, SHOULD 1.2.  Anyone object to MUST 1.2? [No objections] EKR:
Three possibilities. MUST 1.0; SHOULD NOT/MUST NOT 1.0; say nothing. Ted: When
do we expect oldversions-deprecate? EKR: six months to a year. Cullen: we need
to recognize that taking our largest deployments and making them not compliant
with our spec would be bad. Adam: Would just saying nothing be enough? Cullen:
It's a bit unfortunate, but I could live with it.  Browsers will do whatever
they do regardless of the specs. Bernard: These deployments have been very slow
to upgrade in a lot of ways.  I probably agree with EKR to say nothing, and let
individual browser vendors decide what to do. Martin: We're not going to pull
the plug right away. EKR: All the browsers do measurements of what the world
looks like, we're not going to turn it off until it's time.  Two things we want
to do: encourage people what we want them to do, and let them know what they
need for interop.  Include non-normative text to say what they need to talk to
existing deployments.  Let oldversions-deprecate update this doc to forbid 1.0.

Hum: Say nothing, or give deployment advice?
Result: Rough consensus to include implementation advice.

Identity: A-label or U-label in Identities?
Adam: U-label is probably easier to debug
Ted: A-label is guaranteed to have passed through punycode validation, removing
invalid characters (unless someone constructs one by hand). Adam: These things
are used for display, this identity has been vouched for by this authority Ted
(now at the floor mic): There are a bunch of things that can happen if someone
tries to construct a domain portion of an identity.  U-labels also in the realm
of confusabiles.  A-label matching is easier. Adam: This will be handled to the
Javascript for display to the user. Ted: Javscript already has to translate
from Punycode for any IDN name already. Martin: We're just comparing this with
labels we get elsewhere. Harald: Slight preference for U-labels; A-labels are a
hack to get around the limitations of domain name systems.  If we have systems
that handle U-labels we should just use that.  If you require that they're
valid U-labels then anything that's not a valid U-label is invalid anyway.
Adam: It's going to be compared with the domain anyway. Harald: Browsers do
interesting things with IDNs. Bernard: Looking at the WebRTC identity spec, and
it's disturblingly vague.

Ted as chair: If you think you understand this problem, put your hand up now.
[No one] Ted: If you understand this problem enough to be afraid of it, put
your hand up. [Lots] Cullen: Alternative dispute mechanism...

Hum: if you would prefer A-labels, hum now [hardly anyone]
If you would prefer U-labels, hum now [hardly anyone]
EKR: Rough non-consensus.

EKR: Suggestion that Ted Hardie decides.
Ted: Suggest asking implementors what they have.
Martin: I believe it's U-labels.  But it's been three years.
Adam: You probably didn't test against IDNs.
Martin: no.

Ted: Suggestion, U-labels unless someone tells us why.
Hum: consensus.

Identity User Portion Escaping:
Says @ signs must be escaped, does not say how.  Example implies
percent-escaping.  Suggestion: say we mean that. Martin: it's not that simple. 
Confusability.  If they can put an @ in their user namespace, then example.com
can make an assertion about adam@nostrum.com. Adam: That's very user-hostile.
Firefox.com knows me as adam@nostrum.com.  Presenting adam%40nostrum.com to a
non-technical user is user-hostile. Martin: But any other domain can claim
adam@nostrum.com also. Adam: Suggest making it clear in the UX that Firefox.com
is claiming I am adam@nostrum.com. Martin: I want to be user-hostile, I'd
rather that only nostrum.com can claim that. Adam: That's not how lots of
services work.

Hum: percent-encoding or implementation-dependent transform?
[Very slight hum for first option, none for the second]
Ted: Take it to the list?
EKR: Prepare a PR for option 1, and bikeshed it on the list.
Sean: Can we start IETF last call, and note that we have a pull request on it?
Adam: I'd rather not.
Cullen: What does STIR say?
Adam: STIR doesn't have this problem.

EKR: Martin and I have prepared PRs for all three issues.

Late JSEP Changes (Justin Uberti Cullen Jennings)
See github PRs 849, 850, and 851

ICE->ICEbis. No objection.

Stop using appdata.  W3C is removing it.
Harald: MSID draft says you put the track ID in.  Do we need to pull MSID
draft?  Put in text to say generate random track ID. Cullen: MSID is IESG
approved? Harald: yes.  It's just a matter of consistency.  JSEP already says
this. Ted: MSID is an MMUSIC document. Flemming (MMUSIC chair): If Harald is
willing to do the work and the ADs don't mind, we're happy to do whatever
RTCWeb needs. Ted: If MMUSIC process runs to completion, does anyone object to
this?  (No.)

Reject all sections in a BUNDLE group if you reject the offerer tagged m=
section. EKR: This doesn't reflect my understanding of how BUNDLE works.
Bernard: No, Cullen is right.  If you reject the first one you don't know what
to take. EKR: bundle-only has this property, but not otherwise? [Attempt to
read what bundle says] EKR: I think this is a mistake in bundle. Ted: Suggest
mini-meeting, get a PR in late next week. Harald: please write tests for this?
Nils: not sure how Ted: Answer is in Christer, EKR, and Taylor's hands.

Change 4: contradictary advice on whether subsequent offers specify proto field
ICE selected EKR: This came out of BFCP overriding ICE mashing SDP proto field.
We should say that JSEP overrides ice-sip-sdp

Session and version fields in SDP
Nils: Session should be at most 2^63 since it's stable, version at most 2^62
since it increments. Sean: Can you produce a PR? Nils: Sure

Bernard: Harald raised an issue about offer to receive simulcast
Harald: Text in JSEP currently says offerer can't include anything about what
simulcast it accepts in an offer.  This is silly, should be removed. Ted: Are
you volunteering to write a PR? Harald: Yes.

Ted: I believe once these PRs are merged we run through another WGLC and IETF
LC, and you decide what to do with it? Adam: Yes, and I plan to put it in front
of the IESG again.

draft-ietf-rtcweb-mdns-ice-candidates (Youenn Fablet)

Stuart Cheshire: You only have to mDNS, and I appear in the meeting.  Do you
mean .local, or a service? Youenn: A .local David Schenazi: What do you mean by
"mDNS succeeds"? Youenn: You have no multicast-capable interfaces? 
Deliberately not specified.

[When to use mDNS for Host Candidates - include host candidate if public
according to STUN server] Nils: STUN server might be inside your network
Youenn: In the case when you might want to do this, there will be no local
network stun server. Cullen: local network stun servers are quite common

mDNS names should be limited by origin/life of web page
??: Why SHOULD not MUST?
Youenn: In a browser, MUST.  Otherwise, may not be.
??: Isn't draft concerning only web pages
Yerunn??  (Google, co-author):
Ted: What if I have the same page open twice (say once incognito, one not): is
origin scope enough? Youenn: SHould be Cullen: In networks where you have
relays, etc. -- how quickly can you delete these names? Stuart: Three quarters
of second delay on announcing a name. Youenn: In practice we've observed no
delay Stuart: With what software? Youenn: macOS Stuart: You can skip the check
for uniqueness, but in principle you might stomp on someone. Youenn: With
UUIDv4 that's very unlikely Stuart: You could use a different record type,
since no one's expecting to ssh to it.  You could use the _ice service, to
avoid stomping on anyone else. Youenn: Interesting. Stuart: On cleanup, as soon
as you stop using it, machine sends announcement with TTL 0, cleaning up.

Martin: I think we want scope on communication peer; in browser this matches
origin.  Two entities we want to conceal identity from, web app and application
peer.

David Schinazi (chair of DNS-SD): Can you please post your draft on DNS-SD
mailing list? Youenn: sure

Tim Panton: I don't see any downside to making scope to peer connection
instance. Martin Thomson: I agree. Youenn: Page can open tens of thousands of
peer connections.  Would flood mDNS. Martin: We already have this problem with
STUN/TURN, I would throw this in the same rate limit bucket.

Martin: Do you have to announce that you have a name, or could you just respond
to queries? Stuart: In theory you could, but would require changes to APIs.

EKR: Agree these should be scoped to PC.
Cullen: I think we should discuss the rate limiting.
Youenn: mDNS implementation rate limits it.
Cullen: What is it?  I think mDNS was not written with the assumption that
hostile drive-by web pages would be doing this. Christer: I thought you said
limit of one per page, but would need two for IPv4/IPv6. Youenn: Yes, one per
IP address. Martin: Rate limiting is analogous to STUN Cullen: No, STUN isn't
multicast Yerunn?? 2 (Google): Thought of creating pool of these Cullen: We
already have similar pool for STUN EKR: I don't see how this fixes rate
limiting Youenn: Limited per top origin EKR: I'll just nav.  Register domains
1-one billion.example.com.  Web security's hard.  Requires more thinking than
I'm getting from this doc. Martin: I'll open an issue on not broadcasting the
name.  Might help on not stressing the network. Cullen: No, doesn't help

Tim Panton: Is .local fully standardized?
Stuart: RFC 6762, recorded in IANA special use domain registry.  Also, networks
don't support mDNS; networks support multicast. Adam: Issues with this would
arise in enterprise, who turn off telemetry, not clear how much we could tell
this Nils: One mDNS per where you fetched your webpage from.  Shouldn't be that
high, but may be. Cullen: We should do flooding analysis and data before we
start experimenting on large corporate networks, this is a congestion control
issue. Stuart: I'm not sure why you're concerned about picking one address. 
Every mac here has one .local name for all its interfaces.  Also, announcements
reduce

Yerunn??: Implemented in Chrome Canary, will land today

Ted: Would like to close the working group.  Please let's get Cluster 238 to
Heather as soon as possible.

Timeline for closing the working group.