Subject: [tram] Fwd: Re: [rtcweb] draft-schwartz-rtcweb-return

From: Simon Perreault <[email-masked]>
Date: Wed, 08 Apr 2015 08:08:59 -0400

TRAMsters,

I'd like to see some discussion on how this impacts the server-discovery
draft. This part in particular...

"endpoints MUST NOT implement a	configuration based on unauthenticated
network multicast (e.g. mDNS)"

...seems at odds with what was decided in Dallas (i.e., define mDNS
discovery).

Thoughts?

I see having a coherent story for return and server-discovery as
somewhat required...

Simon

-------- Message transféré --------
Sujet : Re: [rtcweb] draft-schwartz-rtcweb-return
Date : Wed, 8 Apr 2015 00:58:29 +0000
De : Cullen Jennings (fluffy) <[email-masked]>
Pour : [email-masked] <[email-masked]>

> On Mar 26, 2015, at 9:20 AM, Cullen Jennings <[email-masked]> wrote:
> 
> I'd like to point out that the combination of ietf-tram-turn-server-discovery and draft-schwartz-rtcweb-return allow any network you are connected to more or less MITM your media and do things like rate limit it, generate analytics on who you are talking to, force your traffic through an intermediary that is in a  different legal jurisdiction and so on. 

We discussed this after the meeting and came up with a  way to resolve
this concern. Benjamin has added some text to the -06 to that
specifically addresses this issue

http://www.ietf.org/rfcdiff?url1=draft-schwartz-rtcweb-return-05&url2=draft-schwartz-rtcweb-return-06

This completely deals with the issue I raised and with that change I
support adopting this as a WG document.

After adoption, I think the WG should consider if any text is needed
around the issue of TURN credentials. (If you run TURN with no
credentials and an attacker can spoof the IP address in UDP packets, you
can end up with the TURN servers in a nasty forwarding loop that allows
an huge amplification factor for an attacker trying do DOS the turn
servers - this is still possible with authentication but you know who to
blame. When TURN was first done with was one of the reason TURN requires
auth and STUN does not). However, I believe this issue can solved and
should not block adopting the draft. )

Cullen

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 8 Apr 2015 12:40:58 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Wednesday, April 08, 2015 5:39 PM
> To: [email-masked]
> Subject: [tram] Fwd: Re: [rtcweb] draft-schwartz-rtcweb-return
> 
> TRAMsters,
> 

Yes. After TURN server is discovered using mDNS, client must authenticate the TURN server to avoid some malicious host advertising that it offers TURN service. Further mDNS http://tools.ietf.org/html/rfc6762#section-21 also refers to using DNSSEC so that the client can ensure that the service is provided by a trusted participant and not a rouge participant.

-Tiru

> 
> I see having a coherent story for return and server-discovery as somewhat
> required...
> 
> Simon
> 
> Sujet : Re: [rtcweb] draft-schwartz-rtcweb-return Date : Wed, 8 Apr 2015
> 00:58:29 +0000 De : Cullen Jennings (fluffy) <[email-masked]> Pour :
> [email-masked] <[email-masked]>
> 
> 
> > I'd like to point out that the combination of ietf-tram-turn-server-discovery
> and draft-schwartz-rtcweb-return allow any network you are connected to
> more or less MITM your media and do things like rate limit it, generate
> analytics on who you are talking to, force your traffic through an
> intermediary that is in a  different legal jurisdiction and so on.
> 
> We discussed this after the meeting and came up with a  way to resolve this
> concern. Benjamin has added some text to the -06 to that specifically
> addresses this issue
> 
> This completely deals with the issue I raised and with that change I support
> adopting this as a WG document.
> 
> After adoption, I think the WG should consider if any text is needed around
> the issue of TURN credentials. (If you run TURN with no credentials and an
> attacker can spoof the IP address in UDP packets, you can end up with the
> TURN servers in a nasty forwarding loop that allows an huge amplification
> factor for an attacker trying do DOS the turn servers - this is still possible
> with authentication but you know who to blame. When TURN was first done
> with was one of the reason TURN requires auth and STUN does not).
> However, I believe this issue can solved and should not block adopting the
> draft. )
> 
> Cullen
> 
> 
> 
> 
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Benjamin Schwartz <[email-masked]>
Date: Wed, 8 Apr 2015 10:27:18 -0400

If the TURN server's identity is discovered over mDNS, then how can the
client authenticate the TURN server, except to prove that it's the same one
advertised over mDNS?  Assuming mDNS is trivial to forge on a broadcast
network, this does not seem like sufficient protection.  Maybe you are
saying that the TURN server's "real identity" is configured by some other
mechanism, and only its address is distributed by mDNS?

I'm not familiar with the interaction between mDNS and DNSSEC, or how this
would help to identify trusted servers.  This seems like another case in
which a trusted pre-configuration mechanism is still required.

On Wed, Apr 8, 2015 at 8:40 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> Yes. After TURN server is discovered using mDNS, client must authenticate
> the TURN server to avoid some malicious host advertising that it offers
> TURN service. Further mDNS http://tools.ietf.org/html/rfc6762#section-21
> also refers to using DNSSEC so that the client can ensure that the service
> is provided by a trusted participant and not a rouge participant.
>
> -Tiru
>
> >
> this
> around

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 8 Apr 2015 15:08:33 +0000

mDNS only helps to discover TURN service in the local network; client and TURN server still have to mutually authenticate each other using the existing long-term authentication mechanism.  Trusted pre-configuration is only required to validate the digital signature of the mDNS answer just like it’s done in DNSSEC but if client and TURN server mutually authenticate then digital signature for answers may not be required.

-Tiru

From: Benjamin Schwartz [mailto:[email-masked]]
Sent: Wednesday, April 08, 2015 7:57 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; [email-masked]
Subject: Re: [tram] Fwd: Re: [rtcweb] draft-schwartz-rtcweb-return

If the TURN server's identity is discovered over mDNS, then how can the client authenticate the TURN server, except to prove that it's the same one advertised over mDNS?  Assuming mDNS is trivial to forge on a broadcast network, this does not seem like sufficient protection.  Maybe you are saying that the TURN server's "real identity" is configured by some other mechanism, and only its address is distributed by mDNS?

I'm not familiar with the interaction between mDNS and DNSSEC, or how this would help to identify trusted servers.  This seems like another case in which a trusted pre-configuration mechanism is still required.

On Wed, Apr 8, 2015 at 8:40 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
> From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Simon Perreault
> To: [email-masked]<mailto:[email-masked]>

-Tiru

> 00:58:29 +0000 De : Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> Pour :
> [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>
>
> > On Mar 26, 2015, at 9:20 AM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:
> >
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Apr 2015 09:58:27 -0700

> mechanism, and only its address is distributed by mDNS?

That's one way to deal with the problem.  I certainly agree with the
view that you should not permit other users on the same network to
capture and potentially block traffic.  We care more about blocking
here than anything other abuse because we have (D)TLS.

It's annoying in a sense, because in many cases mDNS would be a
perfect solution: networks where you trust the devices not to
misbehave in this fashion (i.e., my home) and networks where there are
no local broadcast capabilities (i.e., most ISP access networks).

If you want a more nuanced view of this, I think that the primary
concern is that methods like mDNS allow network users in some cases to
block traffic that they would not otherwise be able to do.  An equally
"unauthenticated" discovery mechanism could rely on capture of a route
(something very different from being able to receive and send
link-layer broadcast packets).  That method would not degrade
security.  The text, as proposed, fails to allow for that possibility.

An anycast-based mDNS discovery method is a potential way of achieving
that goal.

--Martin

(p.s., mDNS + DNSSEC isn't worth pondering too hard, in my opinion.)