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

[Martin Thomson <[e-mail]>]

On 8 April 2015 at 07:27, Benjamin Schwartz <[e-mail]> wrote:
> 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?

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.)