RTCWEB IETF 102 Chairs: Cullen Jennings, Sean Turner, Ted Hardie Scribe: Jonathan Lennox Jabber: Wendy Seltzer Chair slides: Chairs eat crow about meeting in North America again Note Well is reviewed. SDP Examples isn't yet complete, but nothing to discuss so far. We want to finish! Magnus Westerlund: One outstanding document in Payload (Flexfec) which is a dependency of FEC, would be very good if people reviewed it IP Handling: mDNS names for host candidates: (draft-mdns-ice-candidates) - Justin Uberti / Youenn Fablet Ted Hardie (from the floor): With the flag, are you presenting both public and mDNS, or just mDNS? Youenn: without consent, just mDNS Martin Thomson: Do you determine V6 addresses are public by observing it as reflexive? Justin: yes, that seems to be the only way, will discuss later EKR: Does the UUID dereference to both addresses? Youenn: Just use the IPv6 address. You will not have all three host candidates. Martin: I don't think this changes the nature of this at all Ted Hardie: There will be cases where the IPv6 address has a different scope. Use a UUID per address Jonathan Lennox: ICE says take one address per candidate, for names, preferring v6 Justin: we need to update in MMUSIC [Ed: he probably means ICE] to tell people to use mDNS Chairs: we would prefer to split out mDNS into a separate document, so security architecture isn't gated on it. Adjust IP handling to note that other modes may be published. mDNS would be the first of the new modes. Justin: we may need to amend the problem statement too. EKR: I roughly concur with this proposal. We could add an informative reference to this draft. Lennart Grahl: do I understand correctly that the default mode would not change from -09 Adam Roach: The intention would be to publish mDNS elsewhere? Chairs: No, just don't block Cluster 238. Keep the group open to publish this. Adam Roach: You'll have to eat more crows. Chairs: hopefully smaller ones. DKG: It makes me nervous to leave the default as something that leaks private addresses. Justin: We do note the problems in the current specification. Each browser has already made its decision as to what it's going to do. Bernard Aboba: We've made a change in WebIDL about carrying mDNS names. Please do it quickly so we don't have an argument. EKR: We're interested in this mode, we'd like to know how well it works, but having these documents stuck in the RFC Editor's queue for a year and a half won't help anyone. Cullen Jennings: A lot of questions; does this allow you to do DDOS attacks on the multicast, etc. Also cases where hairpinning on the NAT isn't a problem. This also forces traffic that previously stayed on local networks now to go out to the network, can cause worse security. Hums: Do you think you understand this problem? [Substantial hum] Can you live with this being in a separate document? (Separate from having it be a working group draft.) [Slightly quieter hum] Can you not live with this being in a separate document? [Silence] Strong consensus for separating the document out of IP handling Hum for adopting as a working group draft: Substantial for, none against Chairs will work with ADs to add milestone Justin will update the document to update the problem statement and add informative reference Harald Alvestrand: You can't tell from an address whether it's private or not. Justin: Yes, but STUNv4 is well-deployed. Harald: It also means no application that doesn't have STUN servers will work, even if your correspondent has a public IP. Martin: If this is not the IP address the site is seeing, why are we giving it out? Justin: Lean toward the principled decision, but need to see impact. Youenn: Will be a browser decision. Harald: Registration of an mDNS address takes a second, when are you doing it? Youenn: With our testing, there's no one second delay. For the first connection, maybe a small delay (200 ms), Highly depends on whether you're on WiFI or not. Martin: I don't think you need to worry about collisions, these are high-entropy values. Harald: So you're saying you can get away with breaking the protocol on mDNS. Martin: We can talk to DNSSD and get an explicit exception carved out for it. Cullen: It gets more complicated if address goes out on multiple interfaces. EKR: No, you're going to generate a new address for each host candidate. If network is bridged you might get different advertisements for the same address. Nils: Do you need the STUN server just for NAT64, or for other cases? In the room: NAT66 exists. Context Linkage EKR: Context Linkage is an issue, all our worst nightmares have come true, compared to SPECTRE this is nothing. There are lots of ways to tell you're on the same host. I think it's fine to document this in the IP handling document but it's really an open research problem. Cullen: In the same way we identify fingerprinting issue in W3C documents. The only way to identify this is to add huge latency to our real-time communications system. Youenn: This shouldn't be high-priority, but solving it should be on the roadmap. Perhaps block mDNS on third-party iframes. Chairs: we'll document this in the IP handling doc, and address in the follow on doc. DKG: I'm for documenting the issue, but this a webRTC issue not an mDNS issue. Chairs/EKR: Yes. May have an interim meeting to discuss this. - RTCweb Security Architecture: Identity Attribute (https://github.com/rtcweb-wg/security-arch/pulls) - Christer Holmberg Christer: Assumption is that Identity can use something other than fingerprint for identity, outside the scope of rtcweb document. Ted Hardie (from floor): You mean SDP can, not JSEP? Christer: yes Martin Thomson: WebRTC specs are clear, once you have an identity for a peer, all subsequent SDP offers/answers must list the same identity. If you want to have a new identity, make a new PeerConnection. Christer: If you want to keep the same identity, you MUST include it in subsequent offer/answer. Removing it means deleting identity. Cullen: It's not like we're losing transfer, most SBCs use different mechanisms for transfer just for reasons like this. Christer: We need initial offer, answer, subsequent offer text, etc., sections. I can help. EKR: I'm reluctant to modify the major document structure at this point Chairs: Suggest you generate pull request and have it reviewed, but it's up to the editor's discretion as to whether to merge. Important thing is that text is correct and complete. EKR: All current PRs are merged. Christer: Suggest we issue a new rev with the current PRs. EKR: I can do that in minutes. Chairs: when do you think you can do this PR? Christer: Within a month. Chairs: we will WGLC the SDP examples draft, please do take some time and review it. Sample a few, give comments as fast as you can.