Re: Re-org of web-https

Hi Henri,

Thanks for the comments. Responses below.

> On 12 Jan 2015, at 10:36 am, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

[…]
> But then this follows:
>> However, it is still useful, and in some cases (in particular, access from limited
>> networks), highly desirable; in some cases, it might be so desirable that networks
>> require users to accept TLS Man-in-the-Middle. Therefore, we encourage
>> exploration of alternative mechanisms that preserve security more robustly,
>> such as certain uses of Subresource Integrity [SRI].
> 
> This doesn't seem to match what you said on the list and doesn't seem
> to match the actual data that Henry Thompson provided. Frankly, this
> looks like compromise language based on someone getting cold feet
> about treating forward proxies as YAGNI.

The text is about shared caching, NOT forward proxies — forward proxies are one way to achieve shared caching. What we’re saying is that it’s useful to explore other, better ways to get the benefit of shared caching, now that using them in forward proxies is seeing diminished value. 

[…]

> Also, "in some cases (in particular, access from
> limited networks), highly desirable" comes with a high risk of getting
> read too broadly. (Forward proxies [that only cache and don't
> recompress] don't even theoretically help when the network limitation
> is between the browser and the proxy.)

*nod* I’ll try to improve this text.

[…]

> If the TAG is shy to confidently put forward proxies in the YAGNI
> category and needs some non-committal language, please don't claim
> things like "is still useful" without evidence and please avoid giving
> ammo to those who want to MITM. I suggest something like this for
> hand-wavy non-committal language (in place of the quoted part starting
> with "However" above):

Again, that text isn’t about forward proxies; they work perfectly well with HTTPS, and are not bad actors. They problem you’re talking about is interception / “reverse” proxies, in conjunction with some aggressive policies / attacks.


> "However, it is still possible that networks whose link to the
> Internet backbone is very constrained could benefit from shared
> caching. We encourage more research of such networks and, if the
> research shows that there are still notable benefits to be had from
> shared caching, exploration of mechanisms how such networks could be
> better accommodated without compromising the confidentiality,
> integrity and authenticity of Web traffic.”

Noted. I’m going to rework the text to clarify, thanks.

> 2:
> 
> Under "Browser Policy APIs", please replace "as new APIs in Web
> browsers" with "as new APIs for Web browser extensions" to make it
> clearer that Web content shouldn't be allowed to put your browser in
> prison mode. (It might also be worthwhile to edit the text the look
> less accepting of "think of the prisoners" line of anti-https rhetoric
> when the rhetoric is addressed.)

Good suggestion, thanks again.


--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 12 January 2015 18:26:54 UTC