Subject: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 03 Aug 2016 07:51:29 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-rtcweb-transports-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'd like to briefly chat about one aspect of this...

Section 3.4: Allowing configuration of STUN/TURN servers
from JS makes it easier for a calling server to track a
user's call meta-data, if the JS supplied configuration is
e.g. always preferred.  Shouldn't a browser prefer locally
configured servers if those exist and can be used?  Or are
there other things to be said about which STUN/TURN
servers to use when there are multiple choices? (Apologies
if this is handled by ICE already, I forget;-)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 3.1: Would "TURN/TLS" not be better than "TURN/SSL"?

- 3.2: Would s/or its TURN server/or the peer's TURN
server/ be better?

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Aug 2016 17:39:59 +0200

Den 03. aug. 2016 16:51, skrev Stephen Farrell:
> e.g. always preferred.

I'm a bit confused by this remark.

Yes, doing "pc = new RTCPeerConnection({iceservers: {urls:
"turn:trackserver.net"}) will cause packets to be sent to
"trackserver.net" whenever the PC attempts to open a connection.

What is the tracking attack that is facilitated by this ability, which
isn't more simply facilitated by some variant of <img
src="http://trackserver.net"> or its Javascript equivalent?

>  Shouldn't a browser prefer locally

I have understood the lists of servers to be additive: That the browser,
if provided with two lists, would attempt all of them. It would then be
up to corporate policy to block access to all but the corporate,
locally-configured server, if that's their desire.

Yes. I have changed this in
https://github.com/rtcweb-wg/rtcweb-transport/pull/35.

> - 3.2: Would s/or its TURN server/or the peer's TURN

Yes, it would. I'll change this.

Added to https://github.com/rtcweb-wg/rtcweb-transport/pull/31/files
since that PR was changing the next line of the draft.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 3 Aug 2016 16:44:51 +0100

Hiya,

> src="http://trackserver.net"> or its Javascript equivalent?

The one I thought of is call duration if there are keep-alives.
There could I guess be more meta-data visible via STUN/TURN
but it seems like at least the above is a new thing that the
call-server can get at, and possibly desirable (to a tracker).

> locally-configured server, if that's their desire.

Ack. So I guess my discuss then comes down to whether the
additional call meta-data that a call server might access via
selection of it's preferred STUN/TURN servers is sufficiently
worrisome to be more prescriptive in how a browser handles
the various lists.

Cheers,
S.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Aug 2016 17:57:18 +0200

> call-server can get at, and possibly desirable (to a tracker).

Well, you only get call duration if you get the server chosen as a TURN
server, since the client won't notify the TURN server about a decision
not to use an address.

You can also get call duration by setting a trigger on a
PeerConnection's "onstatechange" handler and firing off a query to
"trackserver.net" inside that handler once the state goes to "closed".

The Javascript that created the PeerConnection is able to attach pieces
of itself to very many events that happen over the PeerConnection's
lifetime - PeerConnections are very far away from "fire and forget".

> worrisome to be more prescriptive in how a browser handles

The meta-data available at call setup time seems to be available to the
script that's configuring the call anyway, through SDP and inspecting
the state variables or stats records. This is a lot richer than anything
I can see being exposed to the TURN servers that are configured from the
same script by using these lists.

I may have overlooked it, but I don't see the new attack.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 3 Aug 2016 17:02:24 +0100

> "trackserver.net" inside that handler once the state goes to "closed".

Ah - good point. I don't recall seeing that mentioned in any of
the webrtc stuff I've scanned, but then maybe it's obvious if
one has coded this stuff up. (I've clearly not:-)

> I may have overlooked it, but I don't see the new attack.

And seems to me like you're correct. I've cleared.

Thanks,
S.