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

Small PR for improved text:
https://github.com/juberti/draughts/pull/100/files

On Fri, Apr 20, 2018 at 5:50 AM Sean Turner <sean@sn3rd.com> wrote:

> 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 <lennart.grahl@gmail.com>
> wrote:
> >
> > On 20.04.2018 02:02, Justin Uberti wrote:
> >> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl <lennart.grahl@gmail.com>
> >> wrote:
> >>
> >>> On 20.04.2018 01:29, Justin Uberti wrote:
> >>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <nohlmeier@mozilla.com>
> >>> 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
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>