Re: [rtcweb] Security implications of host candidates

[Harald Alvestrand <[e-mail]>]

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.

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