On Sep 15, 2014, at 5:11 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote:
> On Mon, Sep 15, 2014 at 11:24 AM, Daniel Stenberg <dan...@haxx.se> wrote: >> On Mon, 15 Sep 2014, Henri Sivonen wrote: >>> What the Chrome folks suggest for HTTP/2 would give rise to a situation >>> where your alternatives are still one one hand unencrypted and >>> unauthenticated and on the other hand encrypted and authenticated *but* the >>> latter is *faster*. >> >>> You mess up that reversal of the speed argument if you let unauthenticated >>> be as fast as authenticated. >> >> In my view that is a very depressing argument. That's favouring *not* >> improving something just to make sure the other option runs faster in >> comparision. Shouldn't we strive to make the user experience better for all >> users, even those accessing HTTP sites? > > I think the primary way for making the experience better for users > currently accessing http sites should be getting the sites to switch > to https so that subsequently people accessing those sites would be > accessing https sites. That way, the user experience not only benefits > from HTTP/2 performance but also from the absence of ISP-injected ads > or other MITMing. "Just turn on HTTPS" is not as trivial as you seem to think. For example, mixed content blocking means that you can't upgrade until all of your external dependencies have too. --Richard >> In a world with millions and billions of printers, fridges, TVs, settop >> boxes, elevators, nannycams or whatever all using embedded web servers - the >> amount of certificate handling for all those devices to run and use fully >> authenticated HTTPS is enough to prevent a large amount of those to just not >> go there. > > It seems like a very bad idea not to have authenticated security for > devices that provide access to privacy-sensitive data (nannycams, > fridges, DVRs) or that allow intruders to effect unwanted > physical-world behaviors (printers, elevators). > > For devices like this that are exposed to the public network, I think > it would be worthwhile to make it feasible for dynamic DNS providers > to run a publicly trusted sub-CA that's constrained to issuing certs > only to host under their domain (i.e. not allowed to sign all names on > the net). > > For devices that aren't exposed to the public network, maybe we should > make the TOFU interstitial for self-signed certs different for RFC1918 > IP addresses or at least 192.168.*.*. (Explain that if you are on your > home network and accessing an appliance for the first time, it's OK > and expected to create and exception to pin that particular public key > for that IP address. However, if you are on a hotel or coffee shop > network, don't.) > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
