Re: [rtcweb] Security implications of host candidates

[Manuel Kasper <[e-mail]>]

Disclosure: I work for Threema GmbH, whose main product is the "Threema" messenger (threema.ch), and would like to provide our view of the consequences of this proposal.

We use WebRTC data channels for our web client to establish a connection between the app on a smartphone and a browser on a desktop/laptop. Most of the time, the person who is using the web client connects to the same network with both devices.

The ability to send data (messages, audio, video, files, images) from and to the app without relaying it via a server is the main reason why we use WebRTC.

We have around 5 million users, and a significant portion of them use our enterprise product in corporate networks. Some of them will have IPv6 disabled, and our experience also shows that NAT loopback support is scarcer than one might think.

Because of that, I think the current proposal is a threat for our use case and would severely impact our users' experience. We are definitely on privacy's side (it is in fact our main focus along with end-to-end encryption), but at present we don't have an appropriate way to request consent from the user. Unless that is ensured by this document, the default mode should not be weakened.

- Manuel


> On 12 Jul 2018, at 01:01, Justin Uberti <[e-mail]> wrote:
> 
> 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.
> 
>