- From: Hirotaka Nakajima <hiro@w3.org>
- Date: Thu, 11 Dec 2014 10:29:43 +0900
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, GALINDO Virginie <Virginie.Galindo@gemalto.com>, "public-web-security@w3.org" <public-web-security@w3.org>
- Message-Id: <E996AF5D-BC50-41B8-8900-6A787F67F083@w3.org>
Hi Mark, > If you're referring to OppSec, that's not HTTPS, it's HTTP-over-TLS, and it's a very contentious topic in the W3C; probably best not go there, for now. I’d like to clarify that this document only indicates that moving from http to https and not mentioning opportunistic encryption which is http-over-tls? Thanks! Hiro > On Dec 11, 2014, at 10:11 AM, Mark Nottingham <mnot@mnot.net> wrote: > > Hey Hannes, > >> On 11 Dec 2014, at 5:26 am, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote: >> >> It is a good idea to build on the earlier IAB announcement with regard >> to security of the Web. >> >> I read through the document and I like it. > > Thanks. > >> >> Only three comments/questions: >> >> 1) I was hoping to read that a strong incentive for using HTTPS is to >> secure the distribution of code, which is uses more an more. (Code = >> JavaScript). > > That's implied here: > > """ > Furthermore, security on the Web has proven to be quite subtle. If an attacker can modify content in transit, the power of the Web platform we are defining can easily be turned against the user (or the site they are using). > """ > > Happy to make that more explicit. > > >> 2) You write: >> >> " >> Likewise, we realize that transitioning to HTTPS may not be easy for all >> sites. While the CPU overhead of TLS has been largely overcome by >> advances in processor technology, the Web platform itself makes changing >> schemes difficult, both because URLs themselves need to change, and >> because the URL scheme is also used to trigger different behavior in >> many platform features. These problems ought to be viewed as >> opportunities for improvement in the platform, rather than reasons to >> stop adoption of encryption. >> >> TLS has been optimized quite a bit to deal with the performance impact. >> Here is a relevant link: >> https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html > > Yep. > >> Also, you don't have to change the URLs to enable HTTPS. > > Au contraire, you very much do. If you're referring to OppSec, that's not HTTPS, it's HTTP-over-TLS, and it's a very contentious topic in the W3C; probably best not go there, for now. > >> >> 3) You write: "Another source of friction is deploying HTTPS in some >> networks; for example, in private network address ranges [RFC1918]." >> >> Maybe you can expand a bit on the problems you see there. > > Will try to do so. > > > Thanks! > > >> >> Ciao >> Hannes >> >> >> On 12/10/2014 07:05 PM, Stephen Farrell wrote: >>> >>> >>> On 10/12/14 17:02, GALINDO Virginie wrote: >>>> About secure origin discussion, and for the ones who missed it, there >>>> is an interesting conversation going on in W3C TAG mailing list >>>> (transitioning the Web to HTTPS [1]), based on the finding edited by >>>> Mark Nottingham https://w3ctag.github.io/web-https/ >>> >>> Good stuff. >>> >>>> I guess all >>>> opinion are welcome on that matter on the public tag list. >>> >>> Go for it where possible. When not, then go for HTTP URIs via >>> TLS as per [1], or at least recommend experimenting with [1]. >>> More generally, considering how [2] applies could well be useful >>> here. ([2] btw is an approved IETF document and is currently >>> in the RFC editor queue.) >>> >>> I'm sure its known but all of this is nicely in line with RFC 7258 >>> (already referenced) but also with the recent IAB statement [3] >>> which should also be a useful reference. >>> >>> S. >>> >>> [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption >>> [2] https://tools.ietf.org/html/draft-dukhovni-opportunistic-security >>> [3] >>> https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ >>> >> > > -- > Mark Nottingham https://www.mnot.net/
Received on Thursday, 11 December 2014 01:30:19 UTC