Re: [rtcweb] Security implications of host candidates

[Justin Uberti <[e-mail]>]

On Thu, Jul 12, 2018 at 5:52 AM Harald Alvestrand <[e-mail]>
wrote:

> Den 12. juli 2018 01:01, skrev Justin Uberti:
> > 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.
> >
>
> I must be missing something - if both endpoints hide public v4/v6
> addresses using mdns (whether they are host addresses or learned via
> STUN), we preclude communication outside the local mDNS domain.
>
> Either there's an use case I haven't thought about, or this means that
> only local-to-local connections can be set up.
>
> If one endpoint reveals its public IP and the other doesn't,
> communication outside the local domain will only happen if initial
> packets can make it from the one who's hiding its IP to the one who isn't.
>
> That's a *severe* restriction.
>
>
In neither case would we hide public addresses. The key distinction between
2b and 2d is that 2b does not hide *private* IPv6 addresses (e.g., NAT64
addresses) because they already have short lifetimes (unlike private IPv4s).


> >
> >
> > On Wed, Jul 11, 2018 at 7:22 AM Lennart Grahl <[e-mail]
> > <mailto:[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 <http://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] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>