Minutes IETF102: rtcweb
minutes-102-rtcweb-00

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.