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.