Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling

[Sean Turner <[e-mail]>]

I’m going to go ahead and push this draft towards Adam (our AD) and we’ll treat this as an IETF LC comment to get fixed up before the IESG telechat (i.e., Justin just throw a PR in for whatever change, but there’s no need to spin a new version).

spt

> On Apr 19, 2018, at 21:10, Lennart Grahl <[e-mail]> wrote:
> 
> On 20.04.2018 02:02, Justin Uberti wrote:
>> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl <[e-mail]>
>> wrote:
>> 
>>> On 20.04.2018 01:29, Justin Uberti wrote:
>>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <[e-mail]>
>>> wrote:
>>>> 
>>>>> While I understand the arguments against adding more mode I still think
>>>>> the paragraph describing Mode 4 is missing details and causes confusion
>>>>> among implementers:
>>>>> 
>>>>> - It is not clear if the word “proxy” refers to a HTTP proxy or a TURN
>>>>> server.
>>>>> 
>>>>> This can easily be improved by replacing the word “proxy” with “HTTP
>>>>> proxy” everywhere in the Mode 4 paragraph.
>>>>> 
>>>> 
>>>> The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or RETURN
>>>> proxy (SOCKS is specifically noted in the para).
>>>> 
>>>>> 
>>>>> - It is unclear how an implementation should behave in the absence of
>>> such
>>>>> a proxy.
>>>>> 
>>>>> I would suggest to add a sentence the implementation should not hand out
>>>>> any candidates in the absence of a HTTP proxy.
>>>>> 
>>>> 
>>>> This is a fair point. However, my take is that the behavior should be the
>>>> same as Mode 3 in this case, as the web server already sees the client
>>> IP.
>>>> I could add a sentence to make this super clear.
>>> 
>>> The web server, yes. But not the other peer. I don't think we can assume
>>> trust towards the web server equals trust towards the other peer. I
>>> would agree with Nils that it shouldn't hand out any candidates in this
>>> case.
>>> 
>> 
>> This is not unique to Mode 4.
>> 
>> This scenario is discussed in detail in
>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4;
>> I don't think it needs special mention in this doc.
> 
> Still, I see no possibility for the user to voice it's opinion in this
> matter. However, that may simply be an issue for the browser vendors to
> resolve (by providing additional browser settings - I think at least
> Firefox does that already).
> 
> Then it probably should be clarified because if I'm not mistaken Chrome
> gets it wrong, too (no proxy = no candidates). Unless that fourth mode
> does not actually map to mode 4 (see
> https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_handling_policy.cc?q=rtcIPHandling&sq=package:chromium&dr=CSs&l=15).
> 
> Cheers
> Lennart
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb