- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 19 Jul 2012 20:17:29 +1200
- To: ietf-http-wg@w3.org
On 19/07/2012 5:31 a.m., Roberto Peon wrote: > > There are number of technical issues here. > 1) speed of experience > 2) deployability of protocol > 3) privacy against wireless sniffers (I call this point-to-point privacy) > 4) authentication of the server to the client. > 5) runtime cost > > #5 goes up with TLS, in the short run, though in the long run this > isn't necessarily true if we use a long-lived multiplexed thing on tip > of it-- at least for less optimized stuff that allows the kernel to > handle accept(), etc. It is easy to forget about the cost of dealing > with multiple connections at the system level in the server. > For highly optimized proxies such as haproxy TLS will likely end up a > net cost, no question. > > For #4: This is typically indicated by use of the http scheme. If one > used TLS in transporting such a query, the browser should not be in > the business of server auth-- there should be no chance of a cert > warning. If you get point-to-point privacy without auth here, it is > strictly better from a security perspective, even assuming TLS's trust > chain is compromised. > > #3: TLS does help with this, even without authentication. It isn't > perfect, but it is better than http by quite a bit. > > #2: Experience has shown, unfortunately, that deploying something new > from browser to server is either extremely difficult or unreliable. > That is the only case where mandating anything like TLS makes sense to me. > > #1 isn't obvious one way or another. For the first request TLS > potentially harms latency as compared to http/1.1. For subsequent > requests it comes out as better (given application protocol changes). > More interestingly, negotiating http/2 over port 80 will require a > round trip, which is the same latency penalty one will pay for using > TLS at a site that you have recently visited assuming we use false-start. > Not necessarily. The framing design we wrote in network-friendly draft allows servers and proxies to auto-detect whether the client is using HTTP/1 or HTTP/2 [1] and adjust with zero RTT delay. The client is in a more diffcult position and has to suffer using HTTP/1 syntax on the first request with an Upgrade:HTTP/2.0, but there we propose several headers which the client can use to seed HTTP/2 details with zero delay on the upgrade. The only potential RTT in sight is an HTTP/2 client attempting to start with HTTP/2 when contacting an HTTP/1-only server. They can expect an HTTP/1 error message RTT before anything useful happens (if at all). I am confident we can specify client implementers to use the HTTP/1 upgrade methodology until servers have had time to roll out their part of HTTP/2 and reduce the impact of initial requests. We have done a bit more work since publishing that draft and now have a header design which may eliminate the need for even those transitional headers. At worst the first request from a client has some HTTP/1 syntax bloat and self-corrects into HTTP/2 efficiency on the response - there is never any handshake or option detection RTTs. This is at the proposed lowest level framing syntax of the protocol. Underneath channel encryption, compression, header compaction, data integrity pull/push semantics - the lot. AYJ > -=R > > On Jul 18, 2012 12:16 AM, "Willy Tarreau" <w@1wt.eu <mailto:w@1wt.eu>> > wrote: > > On Tue, Jul 17, 2012 at 11:54:00PM -0700, Mike Belshe wrote: > > > The issue with HTTP/2 will indeed be the same as with IPv6 : > HTTP/2 will > > > be deployed between the browser and the load balancer, and > everything > > > behind will remain HTTP/1 due to the added nuisances of > deploying 2.0 > > > everywhere. Almost nobody does IPv6 between LB and server > nowadays, it's > > > added cost for no benefit. > > > > > > This will force us to continue to support the crappy parsers > of 1.1 > > > forever and not to have MUX between the LB and the server, and > that's > > > precisely the situation I'd like to avoid, by having a > protocol which > > > *supports* more privacy but does not impose it where it's not > expected. > > > > > > > This is not true; you can use whatever you want in your > backoffice. I've > > talked about this many times before, with or without TLS; > whatever you > > want. It's the browser channel which will be TLS only. > > That's why I want the protocol not to rely on TLS but to be > self-sufficient. > If we can use HTTP/2 over TCP then I can disable TLS in the > backoffice. > Otherwise I cannot and am forced to use HTTP/1 instead. > > > > I'm really against making such a thing mandatory because it > will only > > > improve privacy on a few services which actually do not need > it and will > > > globally deteriorate the overall security by lowering the > level of control > > > of users. > > > > > > > We just disagree. And I keep going back to the same argument > over and over: > > > > Show me the user that will stand up and say, "Yes, I would like my > > communications to be snoopable and changeable by 3rd parties > without my > > knowledge." > > I am one of these users. When I'm browsing in clear text, I know my > communications are snoopable and changeable and I don't care. When I > care I use https. Using cleartext has many benefits for me as a user. > It's faster and I don't have to constantly click "I accept" on every > pop-up that is raised due to too difficult certificate management for > the server, or the mess of keeping a CA list up to date. > > So I am one such user who doesn't want to be forced to face all the > discomfort of TLS when it does not make sense. TLS for no reason is > already badly used, there is no reason it will suddenly become better > when made mandatory. It's the opposite, sites having it good will not > improve and remain the same, but the number of sites which will have > to deal with it when not expected will increase the number of false > alarms on the user side. We don't want to accustom users to blindly > click on this warning anymore. > > Willy > >
Received on Thursday, 19 July 2012 08:18:29 UTC