Re: [rtcweb] Security implications of host candidates

[Justin Uberti <[e-mail]>]

One other potential complication: while S 4.3
<https://tools.ietf.org/html/draft-mdns-ice-candidates-00#section-4.3>
indicates that mDNS names should not be registered when running in a
private browsing context, it would still be possible for an endpoint
running in a private browsing context to connect to an mDNS address
registered by an endpoint running in a normal browsing context.

On Tue, Jul 3, 2018 at 2:40 PM Justin Uberti <[e-mail]> wrote:

> Updated fiddle (outputs to display as well as console):
> https://jsfiddle.net/juberti/x7a8ut0q/37/
>
> On Tue, Jul 3, 2018 at 11:16 AM Justin Uberti <[e-mail]> wrote:
>
>> I wasn't able to get that example to work (tried with 2 Chrome and 2
>> Safari instances, got a setRemoteDescription error both times), but I was
>> able to make a JSFiddle <https://jsfiddle.net/juberti/x7a8ut0q/25/>
>> which does something similar in a single page. At present, even host-host
>> connections were seeing a 2 ms RTT, possibly because of the clamping
>> <https://developer.mozilla.org/en-US/docs/Web/API/Performance/now> that
>> has been applied to performance.now() to deal with Spectre et al.
>>
>>
>>
>>
>>
>> On Tue, Jul 3, 2018 at 9:21 AM youenn fablet <[e-mail]> wrote:
>>
>>> Maybe I don't understand the attack well enough, but if a page running
>>>> in a private browsing context tried to communicate with a page not running
>>>> in a private browsing context, they would probably see < 1ms RTTs for both
>>>> host-host and srflx-srflx candidates in many cases (including cases where
>>>> the contexts are on different machines).
>>>>
>>>
>>> This is probably true for good ethernet connections.
>>> Connections over wifi have usually a bigger/less stable latency than
>>> local loop connections.
>>> I uploaded a small example (
>>> https://evening-thicket-98446.herokuapp.com/src/content/peerconnection/datachannel-b2b/)
>>> that computes ping-pong host-host latency through data channel.
>>>
>>