- From: William Chow <wchow@mobolize.com>
- Date: Thu, 6 Nov 2014 02:10:32 +0000
- To: "Mishra, Sanjay" <sanjay.mishra@verizon.com>, Mark Nottingham <mnot@mnot.net>
- CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "diego.r.lopez@telefonica.com" <diego.r.lopez@telefonica.com>
>- Authentication / Authorisation — how does the browser know that the proxy is who they say they are (e.g., “from my >network”) and that they’re allowed to act in this capacity? We should probably define what we mean by "authentication" and "authorization", since they are related but quite distinct. Authorization is the process of deciding who you want to go to for the WPD (i.e., the "WPD authority"), such as via a whitelist or some other mechanism. Authentication is then the process of securely verifying that you are really communicating with that WPD authority, such as requesting the WPD from that authority using HTTPS. IOW, authorization must obviously come first and bootstraps the entire WPD process. >> So far, the most promising direction for this that I’ve heard seems to be having a whitelist of authorities which the browser is willing to trust advertisements from, and then requiring cryptographic proof before trusting such an advertisement. A whitelist makes a lot of sense for authorization. A key question is how is this whitelist used. For example, is it used by the UA for "probing" for a WPD by preemptively issuing requests for the WPD URI to each authority in the whitelist? This works well for simple 1:1 relationships between a client/UA and a WPD authority, such as a browser that has a specific hardcoded WPD authority it checks for when it starts up, or a smartphone that checks its PDP-specified WPD authority when it attaches to the mobile network. Yet, there are myriad other scenarios where WPD can be used to provide significant end user benefits. This mailing list has talked a lot about privacy proxies, which is a great use case, but let's not forget that there are many different interests among the ~3B (and growing) internet-connected end users. Many of these folks want a faster internet and many *need* a cheaper internet. And of course, these users often connect to multiple different networks in a single day, e.g. home, school/work, internet café, hotel, satellite broadband, etc. It seems possible that these other network scenarios would have WPD authorities that can also go into a whitelist (perhaps different UAs have different whitelists). However, there will likely be multiple whitelist entries where it doesn't make sense for the UA to probe every one of them on every network change. One way to make this whitelisting work is to allow the current network to advertise its WPD authority and the UA can then check whether that authority is in its whitelist, before retrieving the WPD via HTTPS. --Will -----Original Message----- From: Mishra, Sanjay [mailto:sanjay.mishra@verizon.com] Sent: Tuesday, November 04, 2014 12:45 PM To: Mark Nottingham Cc: ietf-http-wg@w3.org; diego.r.lopez@telefonica.com Subject: RE: WPD - Proxy Discovery On Monday, November 03, 2014 4:39 PM Mark Nottingham wrote: >- Authentication / Authorisation — how does the browser know that the proxy is who they say they are (e.g., “from my >network”) and that they’re allowed to act in this capacity? >- User Experience — how does the user of the browser become aware of and give permission to (or opt out of) the >proxy, considering that UX around security and configuration is so tricky? Questions you raised in regards to Authentication, Authorization and User Experience are all worthy and will need to be addressed if there is interest in this group to pursue a proxy discovery approach. Creation of a white-list or UA retrieving configuration from a device (static discovery) or UA determining authority of the network advertising WPD (dynamic discovery) can potentially be a starting point for authentication and authorization. The browser/user interaction for presenting an authorized list of proxies and user selection (optional), is surely far from trivial and can only occur with input from the browser community if this aspect is to be considered as part of solution to WPD discovery. Thanks Sanjay -----Original Message----- From: Mark Nottingham [mailto:mnot@mnot.net] Sent: Monday, November 03, 2014 4:39 PM To: Mishra, Sanjay; diego.r.lopez@telefonica.com Cc: ietf-http-wg@w3.org Subject: Re: WPD - Proxy Discovery Hi Sanjay and Diego, To summarise where I think we’re at — the fundamental issues with discovery are: - Authentication / Authorisation — how does the browser know that the proxy is who they say they are (e.g., “from my network”) and that they’re allowed to act in this capacity? - User Experience — how does the user of the browser become aware of and give permission to (or opt out of) the proxy, considering that UX around security and configuration is so tricky? These issues have come up consistently when we’ve discussed discovery in the past. Right now, the “default” answer for discovery is an intercepting proxy. That’s a layer violation (which makes many people sad, including HTTP people because it’s difficult to disambiguate between the proxy and the origin), but it has *better* security properties than e.g., WPAD, because it isn’t trusted more than the network itself, and it’s harder to spoof. Any solution which automatically inserts an intermediary (with or without user interaction) is going to see a fair amount of scrutiny and pushback, I think, because it’s introducing a new attack vector. So far, the most promising direction for this that I’ve heard seems to be having a whitelist of authorities which the browser is willing to trust advertisements from, and then requiring cryptographic proof before trusting such an advertisement. How that whitelist gets populated, however, would likely be contentious (and may not even be suitable for standardisation). At any rate, we’ll have time for discussion in HNL; should be interesting. Cheers, > On 4 Nov 2014, at 2:48 am, Mishra, Sanjay <sanjay.mishra@verizon.com> wrote: > > Hi everyone. Staying with WPD, I too have some additional input to the WPD draft. > > I believe, WPD assumes, or even requires, that the initial WPD authority is explicitly configured somehow*. That configuration implies that authorization occurs prior to any discovery. Discovery is pretty much limited to finding a valid instance. [*For this email, assuming that this can happen as a result of a direct user action; or it could be baked into the client somehow. From the outside, these are basically indistinguishable] > > I have a suggestion. How about, have the network advertise the availability of proxies? This would invert the order of operations, so that an advertisement could be made, the client would acquire the WPD and a user would - if they choose to use a proxy at all - be able to select from the list of advertised proxies. > > Automatic discovery of proxies presents some challenges. Of all of the discovery mechanisms the IETF has produced (and the multitude proposed outside of the IETF), there isn't a single one that is universally applicable. Most of these mechanisms rely on layer 2 features, where the only common layer on the Internet is layer 3. > > Would like to hear if anyone has any thoughts on this. > > Thanks > Sanjay -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 6 November 2014 02:11:05 UTC