Subject: [rtcweb] JSEP and -return- ICE Candidate Policy

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 20 Jul 2015 12:35:34 +0000

https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-11#section-3.4.3 talks about the application having control over the ICE Candidate Policy (RTCIceTransportPolicy) but it also contains the following statement regarding local policy:

"In addition, administrators may also wish to control the set of ICE candidates, and so the browser SHOULD also allow control via local policy, with the most restrictive policy prevailing".

This seems to imply that the admin and application policies are controlling the same functionality in the browser but is this really true?

https://tools.ietf.org/html/draft-ietf-rtcweb-return-00#section-4.3 also refers to to the ICE candidate policy section of JSEP and indicates states that:

"Proxy configuration, including leakiness, maybe set by local policy ([I-D.ietf-rtcweb-jsep], "ICE candidate policy") or other mechanisms".

It seems something is wrong here and probably JSEP should not be talking about the local policy as I assume this would not use the PeerConnection API and the -return- draft should not be referring to JSEP regarding this local policy as again this will not use the PC API.

Andy

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Jul 2015 10:11:46 +0200

Andrew said:

"It seems something is wrong here "

[BA] I do not believe that is true.  With respect to privacy, we have had
two parallel discussions, reflecting two distinct threats.  The original
discussion centered around API-based control of ICE candidate policy, but
the most recent one has been about malevolent JS that requires mitigation
outside of the API, such as browser settings that could be considered
"local".

On Mon, Jul 20, 2015 at 2:35 PM, Hutton, Andrew <[email-masked]>
wrote:

> https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-11#section-3.4.3 talks
> about the application having control over the ICE Candidate Policy
> (RTCIceTransportPolicy) but it also contains the following statement
> regarding local policy:
>
> "In addition, administrators may also wish to control the set of ICE
> candidates, and so the browser SHOULD also allow control via local policy,
> with the most restrictive policy prevailing".
>
> This seems to imply that the admin and application policies are
> controlling the same functionality in the browser but is this really true?
>
> https://tools.ietf.org/html/draft-ietf-rtcweb-return-00#section-4.3 also
> refers to to the ICE candidate policy section of JSEP and indicates states
> that:
>
> "Proxy configuration, including leakiness, maybe set by local policy
> ([I-D.ietf-rtcweb-jsep], "ICE candidate policy") or other mechanisms".
>
> It seems something is wrong here and probably JSEP should not be talking
> about the local policy as I assume this would not use the PeerConnection
> API and the -return- draft should not be referring to JSEP regarding this
> local policy as again this will not use the PC API.
>
> Andy
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 21 Jul 2015 08:27:42 +0000

On: 21 July 2015 10:12 Bernard Aboba Wrote:
> [BA] I do not believe that is true.  With respect to privacy, we have
> had two parallel discussions, reflecting two distinct threats.  The
> original discussion centered around API-based control of ICE candidate
> policy, but the most recent one has been about malevolent JS that
> requires mitigation outside of the API, such as browser settings that
> could be considered "local".
> 

Understood the only thing that I think is wrong is that the -return- drafts refers to the ICE Candidate Policy in JSEP as the mechanism for controlling the local policy which as you say should be something outside of the API.

Unless I misunderstood something we are in agreement.

Andy

---

From: Justin Uberti <[email-masked]>
Date: Tue, 21 Jul 2015 06:36:23 -0700

I think the confusion is regarding the use of RTCIceTransportPolicy.
Clearly that doesn't make sense in the RETURN context.

The point though is that the browser may have additional local policy,
separate from RTCIceTransportPolicy, that governs what candidates it
exposes.

On Tue, Jul 21, 2015 at 1:27 AM, Hutton, Andrew <[email-masked]>
wrote:

> Understood the only thing that I think is wrong is that the -return-
> drafts refers to the ICE Candidate Policy in JSEP as the mechanism for
> controlling the local policy which as you say should be something outside
> of the API.
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 21 Jul 2015 14:11:36 +0000

> Clearly that doesn't make sense in the RETURN context.

Exactly the current -return- draft refers to RTCIceTransportPolicy,

> separate from RTCIceTransportPolicy, that governs what candidates it

Agreed.

Andy

---

From: Justin Uberti <[email-masked]>
Date: Tue, 21 Jul 2015 07:20:24 -0700

> Exactly the current -return- draft refers to RTCIceTransportPolicy,

Well, not exactly - it refers to the "ICE Candidate Policy" section in
JSEP, which says that there may be additional local policy. But I agree
that this is confusing and could be better explained in JSEP.