Re: Mandatory encryption

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