Re: 2 questions

You might find that durability is improved by using TLS.  As long as
the other considerations aren't more significant, TLS is far more
resilient to bit-level errors.  TCP, on the other hand, has a
non-negligible rate of undetected errors if the underlying medium
isn't properly robust.

Incidentally, you might be interested in reading the recent traffic on
the TLS working group list, there's some discussion of similar sorts
of environments to what you describe.

I will also note that if you have a high level of control, the primary
value in using standard protocols is in the existence of robust
implementations.  If certificates don't work for you, try PSK; if you
don't like the cipher suite flexibility, pick one that fits and stick
with it.  Obviously, every variation increases the work and risk, but
that's engineering.

Consider yourself privileged.  The rest of us have to deal with the
swamp that is the Internet.

On 9 April 2015 at 07:25, Benjamin Carlyle
<benjamincarlyle@soundadvice.id.au> wrote:
> On 29 March 2015 at 00:43, Glen <glen.84@gmail.com> 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.
>

Received on Thursday, 9 April 2015 16:56:46 UTC