First session
=============

Minute taker: Magnus Westerlund


1. WG chairs went through status. Noted that the STUN Origin will require
significant changes due to Privacy concerns.

Turn Server discovery Received a significant amount of WG LC comments for
authors to process.

STUNbis: Look at user name hiding that HTTP already used. Will enable common.
Needs review, please make it a priority. Brandon volunteered.
Justin asked if user name hiding is applicable to. It is applicable to long term
user names in any STUN usage. Justin want this for also short term usage. Marc
noted that for ICE the short term is already random.
Justin noted that based on length one can derive clients.

Martin asked about if it was intended to do negotiation for using the hiding.


2. STUN Traceroute

No feedback

3. Turn bandwidth probe

No interoperable issues. Question about an IANA allocation.

Justin why is the mandatory to use loop back packets TURN packet? No need to
specify the wire format.

An application level could open a data channel that is looped through the TURN
server back to the same endpoint.

Justin asked about what the intention was, just a debugging tool? What about
end-to-end tests? Pål-Erik noted that it was simple and not make it complex.

Eric Rescorla you can't let the JS do this. Justin responded that it can be done
on application, and then it will learn the result.

4. Path MTU Discovery using STUN

Chairs asked if there are an one wanting this or already using it. Jonathan
Lennox said he do have use for it to determine MTU to maximize the video encoder
to header overhead efficiency.

Justin: About one or more document. Either one or combining MTU and Path
Discovery and having bandwidth different.

It looks like it doesn't using ICMP. Yes, it will use it if an ICMP error is
received. Not clear if that information is echoed back to the sender. There was
a proposal for how you get ICMP back from the relay on the return leg. But that
is not fully applicable for this proposal.

On documentation: Joining them would help reduce redundancy as there are a lot
of small things that are common between them.


Justin asked about the IPR on bandwidth probe. Standard Cisco license terms
apply, see declaration for details.

5. RETURN

Martin Thomson, don't use the current implementation of HTTP proxy is
motivation. That is setting the bar to low.

Discussion around if autodiscovery using mDNS and other non authenticated
solution can be used to hijack the traffic is target. The threat model was
discussed. Similar attacks on the same lan segment was possible. Martin raised
this to principle. Is it acceptable that anyone can force one to use a
particular proxy. Answer has been no so far. If there are ways of securing mDNS
etc to ensure that you trust the TURN proxy, then you could use it.

The draft should make clear which mechanism are untrusted and which may be more
trusted.

Eric Rescorla requested a more clear threat model. Justin agreed that should be
done. 


Second session
==============

Minute taker: Simon Perreault


STUN ORIGIN
- Alan Johnston presenting. He agrees with Stephen's and Alissas's DISCUSSes.
- Alan's most preferred way forward: make ORIGIN an extension to RETURN.
- Brandon Williams: If ORIGIN is used for policy enforcement then lying is a
  trivial attack.
- Brandon: For a third-party TURN service, ORIGIN is not critical. This data can
  be in the third-party auth token.
- Justin Uberti: Agrees that ORIGIN is not necessary with third-party auth.
- Brandon: Problem is for third-party TURN server to know which key to use to
  authenticate and decrypt.
- Jonathan Lennox: What if it was the same as the Host HTTP header instead of
  Origin?
- Justin: Exactly the same problem would arise.
- Patrick ?: We need a set of origins, not a single one.
- Cullen Jennings: First solution is the best to fulfill the goal of punching
  holes in enterprise firewalls.
- Brandon: DTLS would break inspection by firewalls.
- Hum on pursuing options for ORIGIN:
	- 1st bullet: quite a few hums
	- 2nd bullet: no hums
	- 3rd bullet: one or two hums
	- no opinion: many hums

TURN-Lite
- Justin: Fatal flaw is having to set up a relationship between the ISP and the
  application provider.
- EKR: Why not simply use DNS SRV record for selecting a relay? What is the
  purpose of the relay selector?

WebRTC firewall
(missed some comments)
- Alyssa: Go and convince Stephen Farrell about your proposal. Then come back if
  you succeed.
(discussion to be continued)