Re: Draft finding - "Transitioning the Web to HTTPS"

"henry.story@bblfish.net" wrote:
> 
> 1. Internet of Things and caches
> 
> The internet of things is probably going to pretty localised. We
> imagine sensors in houses, etc… If these sensors use anything to
> communicate then they would probably be using udp over tcp/ip.
>

Agree.

>
> And whatever they do, they probably should not be communicating over
> the wider internet, but only within the space at which they are
> located. ( or else we get huge problems with privacy ).
>

Agree, sorta.

If I had a home-security system with http-enabled sensors, I'd want a
NAT appliance to aggregate those sensors, upload data to a home-
security provider, and allow that provider to download video from the
appliance, in a secure fashion.

Unfortunately, the arguments against WAN access for individual sensors
tend to preclude WAN access for the appliance (which may or may not be
a cache in either direction). Because on the LAN, I don't need
encryption -- more feasible to bring a can of spray paint to the job,
if you follow.

>
> If that is so then we should imagine a setup where these communicate
> with something like a local server. The local server can then
> communicate over the web with remote server to exchange larger chunks
> of information that what any single device can communicate.
>

Agree, I said "appliance".

>
> So I don’t see the case for internet things and internet caches.
> 

And yet I do, based on the very points you make. One thing a security
appliance might cache for the sensors, are firmware updates, but these
would best be downloaded (and re-shared) via P2P not HTTP -- you say
Internet cache, I say BitTorrent. HTTP or BitTorrent, I certainly see
use cases for both Web and Thing caches, with no real distinction
between them based on protocol.

> 
> 3. Unneeded cryptography
> 
> First I think TLS has a mode with 0 encryption. This should of course
> be visible in the UI. ( just verification that the content has not
> been changed en route) This may cover some of the issues brought up,
> such as those related to encrypting large video files.
> 

Agree, up to a point. The zero-encryption mode to me, is passing a
HTTPS-derived digest in HTTP authentication headers. IMO, there's no
downside to caching either the same video for anyone authorized to
watch it, or a login page for those not authorized, at the same HTTP
URL, without requiring the video to be encrypted.

Unless we're talking about home-security videos, in which case requests
from the security provider to the home appliance, should be responded to
with encryption, of course.

>
> 4. Binary Caches
> 
> These form the larges amount of data on the web of course, but tend
> to be things that don’t change very often. With 0 encryption TLS
> perhaps proxies could be changed to cache non encrypted content, with
> the original site publishing a hash of the original binary conent. 
> 

+.5

Zero-encryption TLS isn't necessary unless we accept ubiquitous HTTPS.
+1 to other solutions not requiring ubiquitous HTTPS.

-Eric

Received on Tuesday, 20 January 2015 00:50:28 UTC