Re: [rtcweb] Security implications of host candidates

[Justin Uberti <[e-mail]>]

Thanks for the suggestions on intermediate modes. I think we're converging
on the following potential replacements for Mode 2:
2b) IPv4 mDNS + RFC 4941 IPv6
2d) mDNS of any private IPv4/IPv6  + any public v4/v6 (as determined via
STUN query)

2d) is basically your 2c), but exposing any IPs that would already be
visible to the server. This would basically give all the privacy benefits
of Mode 3 (although, unlike Mode 3, it does allow host-host connections).

Your 2a) probably makes more sense to consider as a derivative of Mode 1,
essentially a 1b), since it exposes all interfaces. I don't know if that
provides a lot of value, since Mode 1 already requires trust, but I'd be
open to arguments for this.

I think the main outstanding question is what we want the final Mode 2 to
be (2b vs 2d), and the key sub-question is whether we think there's enough
benefit in hiding private RFC 4941 addresses. However, we may need
experimental data to properly consider the tradeoffs.



On Wed, Jul 11, 2018 at 7:22 AM Lennart Grahl <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>