Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt

From: [email-masked]
Date: Sun, 11 Feb 2018 01:00:51 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF.

        Title           : WebRTC IP Address Handling Requirements
        Authors         : Justin Uberti
                          Guo-wei Shieh
	Filename        : draft-ietf-rtcweb-ip-handling-05.txt
	Pages           : 10
	Date            : 2018-02-11

Abstract:
   This document provides information and requirements for how IP
   addresses should be handled by WebRTC implementations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 11 Feb 2018 23:24:05 +0000

I forget if this was explicitly discussed before. Apologies if
it was.

I consider the following text ridiculous:

   "Mode 1 MUST only be used when user consent has
    been provided;"

The reason is that it is not possible for all WebRTC users to
ever provide real consent to something dealing with which IP
addresses are used in ICE. So assuming consent is just BS, as
people cannot provide consent to something they do not understand.
(And that won't be explained by their systems or s/w.)

For me, that means that this draft will appear pretty much as a
fig leaf, intended by us technologists to allow us to pretend
we're doing the right thing, when we're not. I think that's not
really that useful.

Is it really too late to try fix the concept of consent that's
(ab)used in WebRTC?

Even if so, I don't see any reason to make it worse, via this
draft, and especially via the quoted text above, so I'd argue
that we ought get rid of that concept from this draft.

FWIW, I reckon, if implementers liked it, that there is a
better answer here which is to provide an interface (API and/or
UI) that allows selected interfaces to be omitted from ICE.

S.

On 11/02/18 09:00, [email-masked] wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: Adam Roach <[email-masked]>
Date: Sun, 11 Feb 2018 18:08:32 -0700

> On Feb 11, 2018, at 16:24, Stephen Farrell <[email-masked]> wrote:
> 

What is your concrete proposal?

/a

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Feb 2018 01:28:59 +0000

Hiya,

> What is your concrete proposal?

Remove all mention of "consent." I'm not that fussed as to how
that's done - were it done, I'd be happy that IETF processes
would lead to a better outcome than today's.

But to try be concrete: How about we re-cast any related issues
in terms of specific actions authorised, or not, by those who
can understand the relevant issues. Often that'd be developers
of the relevant implementations, who ought be encouraged/required
to provide users with meaningful decision points - to which the
answer "no, I don't like your default" ought not be very uncommon.
(For tricky issues like this.)

In cases where the technology absolutely requires a user decision,
then IMO the onus is on us (us being the union of the relevant
sets of implementers) to enable that to be an informed decision.

Bringing that back to WebRTC/ICE, I think the better thing to
do is to define an API (in IETF or W3C, I don't care) that
allows combinations of applications (like VPN clients) and
people, to say which interfaces ought be visible to ICE at
what points in time. That way, IETF specs don't need to talk
about mythical "consent" - such issues become apparent to
end-users via configuration or e.g. VPN-client UIs.

That said, I'm not wedded to any particular manner in which
we succeed in removing the nonsense that consent is actually
in play here.

S.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 12 Feb 2018 10:26:14 +0100

> Is it really too late to try fix the concept of consent that's

I'm sorry, but I don't agree with you on this point.

The decision to go for these modes was based on the theory that if the
user has already consented to the near-perfect tracking abilities that
are implicit in offering a video stream (tracking camera defects, for
instance), and all the information that can be gleaned from a live audio
stream, then the idea of protecting the user against tracking by
restricting access to his IP addresses became of so little value that it
was moot and was worth trading away for better performance of the
functions the user asked for.

Explanations about what the IP address is for and how it is used doesn't
matter in this argument. The point is that the user has already agreed
to a degree of invasion of privacy that a) is perfectly understandable,
and b) is of significantly more significance than what's being discussed
here.

Unfortunately the way in which documents depend on each other, and the
degree to which it's desirable to have each area of concern be described
on its own, make it hard to state this in the document as explicitly as
I do when discussing it.

This thread re-raises an issue that has been hashed over many times, and
I believe the current draft represents the (rough) consensus of the WG
on this matter.

> UI) that allows selected interfaces to be omitted from ICE.

We have that API offered in Javascript already. It's called "skipping
the candidates". But JS API surface helps the JS provider defend against
other attackers; it has no benefit when the JS provider *is* the attacker.

Non-JS-visible APIs discussed have included the ability to specify
"corporate" TURN servers in browser configs and requiring that these be
used. These are typically out of scope for standards; I haven't seen
anything published on whether or not those have been implemented.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Feb 2018 11:12:25 +0000

Hiya,

> I'm sorry, but I don't agree with you on this point.

Fair enough.

> functions the user asked for.

I understand that logic. It does however seem to have caused
issues for at least some people who don't agree that the this
leakage is moot. I'm not claiming that all such claims are
well founded, but I think at least some are.

> I believe the current draft represents the (rough) consensus of the WG

I'm willing to accept that I'm in the rough in terms of how
the WG is using the term "consent."

Nonetheless, if the term can be avoided here, then I still
think that'd be an improvement.

> other attackers; it has no benefit when the JS provider *is* the attacker.

Right - I wasn't suggesting a JS API but rather one such as
you describe below...

> anything published on whether or not those have been implemented.

Nor have I. I agree that specifying such an API in this draft
wouldn't be right. I don't agree that such an interface ought
be out of scope for standardisation, but do agree that figuring
out where to define one could be tricky.

The interface I have in mind for this case would be something
that'd allow e.g. an operating system UI to state that "tun0
isn't to be used for ICE until I say otherwise" or that'd
allow a VPN client application to call a browser-specific API
of some sort to do the same. I guess even a browser command
line argument could help some - then the folks who care about
this issue could then have a different icon/button/whatever
for starting a browser for webrtc-without-tun0 or whatever.

What this draft could do however, is get rid of the idea of
consent, and define the modes as involving all addresses
except those that are omitted due to local policy, e.g. if
such an interface exists and has been used.

Lastly - the above is only worthwhile if implementers were
likely to provide some way to omit addresses/interfaces
from ICE - if WebRTC clients just weren't ever going to offer
any way to e.g. omit tun0, then there'd be no point in
talking about that. If it was something that could be done
now or in future, then it'd be good to talk about it here
though.

And FWIW, I still consider talk of user consent for ICE as
ridiculous:-)

Cheers,
S.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 13 Feb 2018 12:46:23 -0800

> well founded, but I think at least some are.

So this document tries to address two sets of issues:
a) leakage in contexts when the user is not intentionally using a WebRTC
application
b) leakage in contexts when the user is intentionally using a WebRTC
application

The 'consent' discussion is focused around a), with the result being that
the ISP address will not be provided when using a VPN unless the user has
consented to use of their camera. The WG went back and forth and came to a
rough consensus on this being a reasonable solution to the problem.

However, b) is also discussed in the document, and browsers could implement
their own local policy, e.g., their own default or perhaps a preference to
exclusively use Mode 2, regardless of webcam consent.

Such an approach wouldn't provide as much nuance as your suggested
per-interface permission list, but there already are examples of this
(various browser extensions that set the ip-handling mode), and I think we
can all admit that asking OSes to indicate which interfaces are OK to use
for ICE would be a long-term project.

If it would help, I could rework the section around the recommended
defaults to make it clear that users or browsers could choose not to use
Mode 1, and/or discuss the defaults and how they relate to a)/b) above.

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Feb 2018 22:06:06 -0500

> On Feb 13, 2018, at 15:46, Justin Uberti <[email-masked]> wrote:
> 
> 
> 
> On Mon, Feb 12, 2018 at 3:12 AM, Stephen Farrell <[email-masked]> wrote:
> 
> Hiya,
> 
> a) leakage in contexts when the user is not intentionally using a WebRTC application
> b) leakage in contexts when the user is intentionally using a WebRTC application
> 
> The 'consent' discussion is focused around a), with the result being that the ISP address will not be provided when using a VPN unless the user has consented to use of their camera. The WG went back and forth and came to a rough consensus on this being a reasonable solution to the problem.
> 
> However, b) is also discussed in the document, and browsers could implement their own local policy, e.g., their own default or perhaps a preference to exclusively use Mode 2, regardless of webcam consent.
> 
> Such an approach wouldn't provide as much nuance as your suggested per-interface permission list, but there already are examples of this (various browser extensions that set the ip-handling mode), and I think we can all admit that asking OSes to indicate which interfaces are OK to use for ICE would be a long-term project.
> 
> If it would help, I could rework the section around the recommended defaults to make it clear that users or browsers could choose not to use Mode 1, and/or discuss the defaults and how they relate to a)/b) above.

Justin: Since you offered ;) Go ahead and take a stab at it.

Everybody: Hoping this won’t be too controversial since it appeared that we were getting very close to being done with this draft.

> think that'd be an improvement.

Stephen: The only thing I’d add to Harald's point is that this draft hasn’t yet been through WGLC, but the draft has basically had the same recommendations since before it was a WG draft (the draft was adopted about two years ago).  Namely, Mode 1 (enumerate all addresses) is recommended only if the user has done something explicit else Mode 2 (default route + associated local addresses) is recommended.  While Justin might be reworking the section around the recommended defaults, I don’t think the recommended defaults are going to change (unless of course there’s a pretty substantial outcry that’s going to upset what appeared to be the emerging rough consensus).

spt

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Feb 2018 12:58:54 +0000

Hiya,

On 14/02/18 03:06, Sean Turner wrote:
> Stephen: The only thing I’d add to Harald's point is that this draft
> hasn’t yet been through WGLC, but the draft has basically had the
> same recommendations since before it was a WG draft (the draft was
> adopted about two years ago).  Namely, Mode 1 (enumerate all
> addresses) is recommended only if the user has done something
> explicit else Mode 2 (default route + associated local addresses) is
> recommended.  While Justin might be reworking the section around the
> recommended defaults, I don’t think the recommended defaults are
> going to change (unless of course there’s a pretty substantial outcry
> that’s going to upset what appeared to be the emerging rough
> consensus).

Sure, I do get that I'm likely in the rough here, so I won't
keep on arguing about it, esp if others aren't.

I'll just leave it as this: IMO the use of the term consent
in the web generally is broken and has been mis-used by web
sites in various ways. I'm sad that we're seeming to join in
that, even if only a little, and I continue to think that if
we could remove the term from this draft, that'd improve the
draft.

I do agree that the camera/mic "ok, and remember that" is an
understandable signal for a person who's involved in making a
(set of) call(s) with/via a web site that uses https.

I do not agree that anybody will understand that that means
that the origin in question can subsequently expose addresses
via ICE when no calls are being made (from the user POV), so
I do not agree with the WG consensus that leveraging the
camera/mic signal is a good choice here.

I also do accept that there is a lack of other good choices
and I've also already said that I don't think the address
exposure is gigantic flaw, but that there are non-crazy people
who think it's bad.

Cheers,
S.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 26 Feb 2018 22:53:58 -0800

PTAL at https://github.com/juberti/draughts/pull/96, which tries to explain
that implementations may choose different defaults a bit more clearly.

On Tue, Feb 13, 2018 at 7:06 PM, Sean Turner <[email-masked]> wrote:

> > The 'consent' discussion is focused around a), with the result being
> that the ISP address will not be provided when using a VPN unless the user
> has consented to use of their camera. The WG went back and forth and came
> to a rough consensus on this being a reasonable solution to the problem.
> >
> > However, b) is also discussed in the document, and browsers could
> implement their own local policy, e.g., their own default or perhaps a
> preference to exclusively use Mode 2, regardless of webcam consent.
> >
> Everybody: Hoping this won’t be too controversial since it appeared that
> we were getting very close to being done with this draft.
>
> hasn’t yet been through WGLC, but the draft has basically had the same
> recommendations since before it was a WG draft (the draft was adopted about
> two years ago).  Namely, Mode 1 (enumerate all addresses) is recommended
> only if the user has done something explicit else Mode 2 (default route +
> associated local addresses) is recommended.  While Justin might be
> reworking the section around the recommended defaults, I don’t think the
> recommended defaults are going to change (unless of course there’s a pretty
> substantial outcry that’s going to upset what appeared to be the emerging
> rough consensus).
>
> spt