Re: [rtcweb] Security implications of host candidates

[Lennart Grahl <[e-mail]>]

On 10.07.2018 09:56, Harald Alvestrand wrote:
> Thoughts:
> 
> - If I want to find out that I'm on the same host as another context
> that I can communicate with in *any* fashion, I've got lots of games I
> can play.
> 
> Example: Measure memory pressure, allocate 1 Gbyte in one context,
> measure memory pressure again. This works for any measurement that's
> available to both contexts and relates to the whole system.
> Example: Measure the local clock's skew compared to some reference clock
> (NTP-fashion). If the skew is the same down to the nanosecond, same host
> is likely.
> Example: Allocate any resource that can only be accessed from one
> context at a time. Loop, asking for it, in the other context. Release it
> in the first context, and check the timing on when the other one gets it.
> 
> In general, anything that can potentially be used as a covert channel
> can be used more easily to figure out if we're on the same host.
> 
> My conclusion: Defending against this attack isn't worth the trouble.
> We've already lost.
> 
> - Nevertheless, we're finding that the MDNS mode has implications that
> we don't perceive fully yet.
> 
> My conclusion: This is an additional mode, not a replacement for one of
> the other modes. We should continue to specify both.

I'm treating this thread as a follow-up to the "IP handling: Using mDNS
names for host candidates" thread, so this refers to both drafts and the
PR for ip-handling (https://github.com/juberti/draughts/pull/103).

Harald, I second your conclusions. Regarding mDNS, I see potential for
the following three "intermediate" modes:

- Mode 2.a: Enumerates all addresses but only the default route's
interface addresses are exposed as host candidates. All other addresses
are hidden via mDNS.
- Mode 2.b: The mode 2 as described in ip-handling-09.
- Mode 2.c: Only expose the default route's interface addresses hidden
via mDNS.

2.a is a minor improvement but will fix issues for users who would be
able to establish a direct connection over a different route but the
default one.

2.c is a major restriction over 2.b and 2.a. since it will break the
ability to establish direct connections in a corporate network.

Regarding the ip-handling document: It's probably okay to restrict the
default mode further from ip-handling-09's mode 2. FWIW, it might even
be okay to give implementations the freedom to choose any of the
available modes as their default (let's be honest, many browser vendors
have already done so anyway). But only if all use cases have access to
an adequate way to request consent to achieve mode 1 or at least 2.a.
Specifically, this should be a MUST in the ip-handling document. Because
if that is not guaranteed, some less obvious already existing use cases
(think of sharedrop.io for example) will be further discriminated and
without a TURN server can be completely broken. Not to mention the
impact on delay and throughput caused by hairpinning or even relaying.

Cheers
Lennart