Re: 2 questions

[Benjamin Carlyle <[e-mail]>]

On 29 March 2015 at 00:43, Glen <[e-mail]> wrote:
> 1. What were the reasons for HTTP/2 not requiring TLS?

I know this issue has been canvassed many times on the list, but I
thought since I am writing emails tonight I would share a perspective
that I think is novel on this list. To restate from my last email, I
mostly use HTTP/1.1, SPDY, and soon will h2 in the context of highly
available safety-related (not safety-critical) SCADA systems.

Firstly, I mostly like the use of TLS on the web. I think it is well
warranted. However in my environments I'm typically dealing with
"secure" networks where other protections exist at the IP layer or
below that ensure many of the properties that TLS provides. These
generally are isolated networks with air gaps to the Internet or at
least some multiple layers of networks and restrictive firewalls
before the Internet can be reached. Changes to these networks go
through processes to ensure isolation is maintained to the desired
degree, and privacy is not a concern. Rather, if there is a concern it
is potential attacks on the system and related infrastructure. In fact
eliminating privacy and having every action be fully accountable is a
requirement.

My primary concerns in this environment are about high availability,
maintainability, and durability of the system. In my line of work I
often come across systems that have been in place for twenty years,
some still with serial communications, some devices still on the
network but if they failed would require some digging through
paperwork to even find their physical location. Some using network
technologies that are obsolete and are still running only due to
careful spares management. Replacing these systems is expensive and
the accountants like to amortise the expense over a long period of
time.

Traditionally HTTP has been a good next protocol to replace some of
the older system protocols. It is generally possible to connect quite
old and quite new HTTP implementations together and have them
interoperate, and the focus on text-based communications has meant
that reverse-engineering is likely possible when an incompatibility
does come up and some form of information plumbing is possible to join
both ends together.

h2 has largely maintained these properties albeit with a compatibility
break from HTTP/1.1 and with somewhat reduced debuggability /
increased plumbing complexity due to header compression and the like.
TLS brings roughly the same hazards for both HTTP/1.1 and h2, such as:
- opaque data streams that are difficult to put a logic probe
(wireshark) into for reverse engineering purposes
- certificates that need to be acquired, or self-signed certificates
that need to be distributed. This can mean that certificate trust
needs to be installed on a replacement unit before it is sent out into
the field in case of a hardware failure
- the possibility that a certificate will unexpectedly expire. If you
have hundreds of devices around a network in awkward places across a
metropolitan-sized system then the tracking of regular maintenance
activities such as these can be non-trivial
- The cipher suites eventually become outdated, and you can end up
with a patchwork of equipment of various ages that have
old-to-the-point-of-useless encryption that newer devices won't want
to talk to, and potentially a bunch of equipment in between these
extremes. More to track, more to get right. More difficulty supporting
old equipment.
- TLS tends to couple the software implementation to end device. In
this business you tend not to want to update a device, but instead to
offload things that need regular maintenance onto a separate component
that you can physically replace. For example you might have a handful
of field units at a given location connected to an industrial router.
It is the router we would want to be taking on the encryption function
rather than the individual devices because touching one of the devices
requires much more expensive installation and revalidation work.

None of the problems are insurmountable and maybe just making sure
that TLS offload for h2 is well supported and well understood will be
enough to resolve them. But basically as it is the positives of TLS
seem generally more like net negatives in this environment. These may
also be somewhat temporary objections. The systems are always moving
closer to being core business systems rather than solely control
systems so both customer and suppliers are moving closer to
conventional IT practices. It may be that in another twenty years the
systems and practices I'm seeing will all be gone, but given the
distributed nature of the systems I think there will always be some
differences to the Web.