Using TLS in network stacks

[Dirk Munk]

This is going to be a bit of an academic discussion, but perhaps food
for thoughts.

We all know what has to happen if you want tu use SSL/TLS with an
application, you have incorporate it in the application. At least, that
is the way it is done with IP. So if you want to use it with 20
applications, you have to incorporate in each and everyone of those 20
applications. If there is a new release of TLS, you have to rebuild 20
applications. Fun isn't it?

However TLS had been designed to be used in the OSI transport layer, The
OSI transport layer has (almost) nothing to do with the applications.
With DECnet Phase V for instance, it is completely transparent for an
application if you use the CLNS transport layer or the IP transport layer.

That also means that if you add TLS to your transport layer, it is
completely transparent for the application. No TLS in the application
itself. A new version for TLS only means an updated network stack, the
applications stay untouched. You could add TLS to the CLNS and IP
transport stack. All your DECnet Phase V and other OSI traffic would be
encrypted. That would make Hoff very happy (me too).

Perhaps VSI should add TLS to DECnet Phase V after all?

[David Froble]

Well, most of this is dependent upon implementation decisions, but not all. As
for the code, if all of it was in sharable RTLs which are used at run time, then
code can change and re-linking is not required. Assuming no changes in the
arguments. That is not how OpenSSL is implemented, as far as I'm aware.

Then there is the entirely external stuff called certificates. Perhaps such
allow lots of flexibility, don't know, I hate them too much to be knowledgeable.
It seems that to have unique encryption you have to have unique certificates.
That means that in addition to any application programming, there must also be
expertize with certificates.

Now, you are correct to wish to have encryption be part of the communications,
not part of the application. But even with IPSEC I believe there must be
outside (the communications) trading of secret data. So automatic encryption
doesn't seem to be obtainable. (Would like to be wrong.)

I'm firmly on the side of encryption being part of communications, not
applications. However, when communicating, you're going to be wanting to
communicate with anyone, and that sort of rules out DECnet. Something in IP
that has greatly reduced knowledge requirements for such as certificates would
be a good thing, in my opinion. Not sure how this would work with the other
side having the encryption in the application. I'm thinking it should work.

So, yeah, provide the capability to provide network services without the pain of
certificate management would be a selling point for VMS.

[Stephen Hoffman]

I'd much rather see something akin to Secure Transport, App Transport
Security (for HTTPS), or some variation or extension or alternative
beyond that sort of design, rather than haring off into OSI, or
otherwise expending development effort on or perpetuating what are now
problematic or limited designs or tools.

I'd rather have a far simpler API and UI for network application
development, and specifically one that deals with the entirety of the
networking requirements. An API that deals with IPv4 and IPv6, with
DNS resolution, with connection creation and error handling and
related, with certificate verification and pinning ad the rest, and
leaves me to sending over either a stream or datagrams, either
synchronous or asynchronous. Because that's what an application
developer wants to do — to securely connect with an application running
on some other host, via IP and TLS Not to go explore OSI, NCL,
DECNET_REGISTER, or otherwise.

What's underneath that preferred new API? I don't care if it's
OpenSSL, LibreSSL, VSITLS, IPSec, OSI, IPoAC / RFC 1149 transport, or
something else, so long as my OpenVMS applications can successfully and
securely connect to and interoperate with remote clients or remote
servers using sockets and OpenSSL, or using libtls or whatever.

I'd rather not get dragged back into the technical elegance and the
abject complexity of OSI and particularly of the DEC implementation of
OSI known as DECnet Phase V, though that certainly did solve almost all
the problems in networking, and was a quite elegant and inclusive
solution. Unfortunately, OSI and Phase V and OSI didn't manage to
solve the most important problems. Which problems didn't Phase V
solve? The ones that actual customers had and have now and will have,
and were and are willing to pay for, and have and will need to
interoperate with. OSI missed the market.

While sockets and an OpenSSL-like interface are minimally required and
there are applications that can and will and must use those, I'd also
rather not use those directly. Nor deal directly with DNS
translations, for that matter. Those APIs are complex, can be
error-prone, and there are things that just aren't easy to do using
some of those APIs. Yes, libtls seeks to be an easier TLS interface
for developers. But programming networking applications — securely,
reliably, effectively — extends well beyond TLS.

More than a few IP networking applications started out using the
example programs. Those have some... issues. Those examples are
rather complex, too. Can somebody code to those or sockets or
OpenSSL? Sure. (But if you haven't, go try that, and go try using
the OpenVMS OpenSSL implementations, certificates and TLS, and
verifying certificates and other necessary tasks. It's... quite
interesting. Then try using all that from a language such as BASIC or
Fortran. Sure, it's possible. So are mistakes, given the
complexities and the arcana involved.)

In general, VSI wants and needs to increase the OpenVMS customer base.
To add wholly new deployments and new customers outside of the
installed base. To offset those ISVs and customers and applications
that are porting off of OpenVMS. Keeping Phase IV, Phase V, and EDT
running — more or less as they are — is certainly necessary in the
short term, but expending design and development efforts beyond that on
Phase IV, Phase V, EDT and the rest of the past are not going to be
particularly interesting to potential new OpenVMS customers, or to
current customers or ISVs considering wholly new deployments.

https://developer.apple.com/reference/security/1654508-secure_transport
https://developer.apple.com/library/prerelease/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW33

http://www.libressl.org
http://labs.hoffmanlabs.com/node/1853
etc...






--
Pure Personal Opinion | HoffmanLabs LLC

[Kerry Main]

[snip..]

Imho, given the recent high profile DDoS's and hacks of the Democrats (and imho, likely Republicans as well, but the Rep info is likely just being kept on file for future offline arm twisting), a much more secure internet is required.

Imho, it is critical to stick with where the IETF and security standards are at.

One example might be HIP - Host Identity Protocol.

Reference:
http://bit.ly/2gSUUDY
"HIP or Host Identity Protocol is a standard-track network security protocol, approved by the leading standards organization in the Internet, the Internet Engineering Task Force, in 2015. That event crowned over 15 years of HIP development, testing and deployment in co-ordination with several larger companies (such as Ericsson, Nokia, Verizon, TeliaSonera) and standard bodies (Trusted Computing Group, IEEE 802)."

"HIP provides an alternative key exchange capability for the IPsec protocol, enabling transparent and legacy-compatible security for all TCP/IP applications. HIP introduces the concept of an identifier-locator split (separating the role of IP addresses as host identity and topological location in the Internet), where hosts are identified using strong cryptographic identities in the form of 2048-bit RSA public keys.

The locator is an IPv4 or IPv6 address, but the identity is not tied to the identity of the host. Hosts can change their IP location, but retain their strong cryptographic identity. HIP remains compatible with IPv4 and IPv6 applications, utilizing a customized IPsec tunnel mode for confidentiality, authentication, and integrity of the network applications.

HIP provides strong security properties thanks to its time-tested design relying on formal verification of its state machine describing each step of protocol operation. Since hosts and network devices can use the unspoofable cryptographic ID for identification rather than ephemeral IP addresses, functionality such as host and network mobility, single sign-on, and multihoming are easily implemented.

Furthermore, in contrast to TCP, HIP was designed from the start to be robust against the Denial-of-Service (DoS) and Man-in-the-Middle (MiTM) attacks plaguing the present Internet by deploying a clever cryptographic puzzle mechanism and stateless server approach in the key establishment and authentication phase."

Original will wrap:
http://www.temperednetworks.com/wp-content/uploads/2015/09/Host-Identity-Protocol-Andrei-Gurtov.pdf


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Stephen Hoffman]

On 2016-12-03 14:47:51 +0000, Kerry Main said:

> Imho, given the recent high profile DDoS's and hacks of the Democrats
> (and imho, likely Republicans as well, but the Rep info is likely just
> being kept on file for future offline arm twisting), a much more secure
> internet is required.

Host identity is already available via different means within TLS in
conjunction with certificate-based authentication, and two of the
approaches involved in that have already been discussed in this and
other threads. Host identification is certainly something that is
interesting to some servers, though where per-user authentication is
more interesting for managing internal networks. The access into the
Democrat systems involved a completely different and more common
attack, and one not particularly related to host names. DDoSes and
other shenanigans are going to be around until platforms with security
issues — those problematic platforms including public-facing OpenVMS
systems — are updated, and where the tools and mechanisms and policies
around quickly update those platforms become more prevalent. VSI IP
will hopefully better sort out IPv6 and IPsec support, as the current
implementation is problematic and missing, respectively.

[David Froble]

Kerry Main wrote:

> Imho, given the recent high profile DDoS's and hacks of the Democrats (and
> imho, likely Republicans as well, but the Rep info is likely just being kept
> on file for future offline arm twisting), a much more secure internet is
> required.

Regardless of potentially more secure internet, there are methods today to
provide better security than some people use. When we're talking about running
the country, I'm not sure I'd want someone that has demonstrated such rather
poor security.

What's next, nuclear weapon design specs for sale on every street corner?

Perhaps rather than voting, we assign political office to those who don't get
hacked?

:-)

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of David Froble via Info-vax
> Sent: 05-Dec-16 8:30 PM
> To: info...@rbnsn.com
> Cc: David Froble <da...@tsoft-inc.com>
> Subject: Re: [Info-vax] Using TLS in network stacks
>

Not sure which is worse - knowing a group has been hacked (Dem's)
and then taking steps to mitigate this...

or NOT knowing you were hacked (potentially Rep's by the same
hackers) and then having that information used against you
offline at some future point as black mail.

What is really scary is Rep promoter admitting on CNN that "facts
no longer matter .." and then realizing she is right.

Crazy world ...

[Stephen Hoffman]

On 2016-12-06 01:30:22 +0000, David Froble said:

> Perhaps rather than voting, we assign political office to those who
> don't get hacked?
>
> :-)

Interesting proposal. But that's to ensure you're never "assigned"
politial office, given your ongoing use of Windows 2000, right?

😈

[Dirk Munk]

I totally agree, and I think for VMS <> VMS traffic (cluster over IP +
normal IP + DECnet over IP) using IPsec should be the standard since it
covers all IP traffic.

Of course VMS <> other OS should also be over IPsec, certainly when
we're talking about constant (non ad-hoc) connections.

I hope someone will write a manual how to set it all up, covering for
instance VMS, Linux and Windows.

[Stephen Hoffman]

On 2016-12-08 17:53:21 +0000, Dirk Munk said:

> I totally agree, and I think for VMS <> VMS traffic (cluster over IP +
> normal IP + DECnet over IP) using IPsec should be the standard since it
> covers all IP traffic.
>
> Of course VMS <> other OS should also be over IPsec, certainly when
> we're talking about constant (non ad-hoc) connections.
>
> I hope someone will write a manual how to set it all up, covering for
> instance VMS, Linux and Windows.

Documentation for developers, certainly. For end users, manuals are
the exact wrong approach. That must be done transparently, correctly,
at install time.

I don't care if the network traffic is IPsec or TLS, so long as it's
securely encrypted and securely authenticated.

Having TLS and DTLS support in the kernel, and rather less of a dog's
breakfast around certificate handling and vastly upgraded network
transport APIs is also a given, of course.

[David Froble]

And what happens if it's not so easy to use?

I just implemented a relay, on weendoze, to act as a service for VMS tasks, and
a client to service providers over the internet. I needed TLS V1.2 to talk to
the service provider.

Note, this isn't the first time I've had to resort to such methods.

I could not get SSL1 to do the job. I was able to perform VMS task to VMS task
on the same system. In communications with the service provider, total failure.
I do plan on some more testing in-house, SSL1 to a non-VMS system.

Yes, the fault very well may be me, not SSL1. But the ease of use, and lack of
documentation, and apparent attitude of HP, and SSL1 not being set up for use
from all VMS languages, and the result is VMS not being used for the job.

[Stephen Hoffman]

Ayup. This is the request for the upgraded network transport API that
I'd mentioned. The existing network transport API — I'm refering to
the network API and the crypto API and the authentication processing
here, as well as dealing with common tasks such as parsing JSON data
and managing a REST connection — is far too complex, far too low level,
unfortunately far too error prone, and mixing IP sockets and OpenSSL
and DNS and related details into any OpenVMS application produces a
mountain of glue code. The existing API is great if you need that
level of access, but — for "ordinary" client and server operations and
activities — the existing APIs are a problem. Other than rolling an
entire API, or integrating with curl and dealing with what that
entails, or maybe porting over libtls and integrating that — IIRC,
libtls needs cmake, too — the choices here aren't good ones...

[Dirk Munk]

Stephen Hoffman wrote:
> On 2016-12-08 17:53:21 +0000, Dirk Munk said:
>
>> I totally agree, and I think for VMS <> VMS traffic (cluster over IP +
>> normal IP + DECnet over IP) using IPsec should be the standard since
>> it covers all IP traffic.
>>
>> Of course VMS <> other OS should also be over IPsec, certainly when
>> we're talking about constant (non ad-hoc) connections.
>>
>> I hope someone will write a manual how to set it all up, covering for
>> instance VMS, Linux and Windows.
>
> Documentation for developers, certainly. For end users, manuals are
> the exact wrong approach. That must be done transparently, correctly,
> at install time.
>
> I don't care if the network traffic is IPsec or TLS, so long as it's
> securely encrypted and securely authenticated.

IPsec is encryption at the IP level, all IP traffic between two nodes
will be encrypted. There's only one port in use (6000), very easy for
firewall rules. Furthermore IPsec can be handled by the NIC.

In the 7-layer OSI network stack, TLS can be added to the transport
layer, and it then works for all applications. Unfortunately IP has only
four layers, and that is the reason that TLS has to be added to each and
every application that needs to be encrypted, and each application has
to be updated when TLS needs an update.

>
> Having TLS and DTLS support in the kernel,

Perhaps, it would be even nicer if it also could be handled by the NIC,
but I suppose that is not possible.

> and rather less of a dog's
> breakfast around certificate handling and vastly upgraded network
> transport APIs is also a given, of course.

Sure, it would be great if it was a callable library as was suggested here.

In short, it would be nice if IP was build as modular as OSI, alas it isn't.

[Bill Gunshannon]

On 12/9/16 12:51 PM, Dirk Munk wrote:
> Stephen Hoffman wrote:
>> On 2016-12-08 17:53:21 +0000, Dirk Munk said:
>>
>>> I totally agree, and I think for VMS <> VMS traffic (cluster over IP +
>>> normal IP + DECnet over IP) using IPsec should be the standard since
>>> it covers all IP traffic.
>>>
>>> Of course VMS <> other OS should also be over IPsec, certainly when
>>> we're talking about constant (non ad-hoc) connections.
>>>
>>> I hope someone will write a manual how to set it all up, covering for
>>> instance VMS, Linux and Windows.
>>
>> Documentation for developers, certainly. For end users, manuals are
>> the exact wrong approach. That must be done transparently, correctly,
>> at install time.
>>
>> I don't care if the network traffic is IPsec or TLS, so long as it's
>> securely encrypted and securely authenticated.
>
> IPsec is encryption at the IP level, all IP traffic between two nodes
> will be encrypted. There's only one port in use (6000),

Are you sure about that? 6000 is X-windows and most sites block it
for good reason. I think what you want is ports 500, 50 and 51.

> very easy for
> firewall rules. Furthermore IPsec can be handled by the NIC.

By what NIC? I remember working for companies that were developing
smart NICs (where did you think all those 80186 cpus went) and they
went over like a lead baloon.

bill

[Michael Moroney]

Dirk Munk <mu...@home.nl> writes:

>IPsec is encryption at the IP level, all IP traffic between two nodes
>will be encrypted. There's only one port in use (6000), very easy for
>firewall rules. Furthermore IPsec can be handled by the NIC.

>In the 7-layer OSI network stack, TLS can be added to the transport
>layer, and it then works for all applications. Unfortunately IP has only
>four layers, and that is the reason that TLS has to be added to each and
>every application that needs to be encrypted, and each application has
>to be updated when TLS needs an update.

I wondered why they didn't just create a new transport layer that
replaces TCP, handles all the encryption, but otherwise acts to a
higher layer like TCP. It would be sort of a layer violation as
it would have two sublayers, the encryption itself and a lower layer
that perhaps was similar to TCP itself, at least handling all the stuff
TCP does. Instead of the 3 packet TCP connection setup, there would be
a multi packet exchange that handled all the key exchanges etc.,
transparent to the client.

[Stephen Hoffman]

On 2016-12-09 17:51:59 +0000, Dirk Munk said:

> Stephen Hoffman wrote:
>> On 2016-12-08 17:53:21 +0000, Dirk Munk said:
>>
>>> I totally agree, and I think for VMS <> VMS traffic (cluster over IP +
>>> normal IP + DECnet over IP) using IPsec should be the standard since it
>>> covers all IP traffic.
>>>
>>> Of course VMS <> other OS should also be over IPsec, certainly when
>>> we're talking about constant (non ad-hoc) connections.
>>>
>>> I hope someone will write a manual how to set it all up, covering for
>>> instance VMS, Linux and Windows.
>>
>> Documentation for developers, certainly. For end users, manuals are
>> the exact wrong approach. That must be done transparently, correctly,
>> at install time.
>>
>> I don't care if the network traffic is IPsec or TLS, so long as it's
>> securely encrypted and securely authenticated.
>
> IPsec is encryption at the IP level, all IP traffic between two nodes
> will be encrypted.

Ayup. TLS is encryption and authentication integrated directly into
the application source code either linked in or via DLL or via OO or
other such interface, with this application-integrated approach used
due to the lack of ubiquitous IPsec support. Not that IPsec itself
won't also require application integration, and not that IPsec
addresses anywhere near all of what's involved in
application-to-application communications. IPsec is a great approach,
but it's still not common. OpenVMS lacks it within the vendor IP
stack, for instance. TLS is more portable, and more common. Neither
IPsec nor TLS target the entirety of what clients and servers are
looking to do, too.

All of this has been going 'round and 'round, and TLS and IP have been
irritating

> There's only one port in use (6000), very easy for firewall rules.
> Furthermore IPsec can be handled by the NIC.

An increasing number of network services are using REST via TLS on TCP
443, for better or worse.

Getting the rest of the 'net to move to TCP 6000 just isn't happening.

> In the 7-layer OSI network stack,

As HBVS and particularly ZFS have clearly shown, the classic layering
abstractions can sometimes introduce problems and limitations, too.
But I digress.

> TLS can be added to the transport layer,

Hmmmm.... I wonder what the T in TLS represents?

> and it then works for all applications.

For some definitions of "it works", because it doesn't work for all
applications. But then that's been the fundamental problem with OSI,
it solved everything, and utterly missed the market because of that.

> Unfortunately IP has only four layers, and that is the reason that TLS
> has to be added to each and every application that needs to be
> encrypted, and each application has to be updated when TLS needs an
> update.

Unfortunately IP is what we have, so we get to work within that.

>> Having TLS and DTLS support in the kernel,
>
> Perhaps, it would be even nicer if it also could be handled by the NIC,
> but I suppose that is not possible.

DESNC, but — in this era — that would still require interaction with
the host software and application around pinning and authentication.

>> and rather less of a dog's breakfast around certificate handling and
>> vastly upgraded network transport APIs is also a given, of course.
>
> Sure, it would be great if it was a callable library as was suggested here.

Other than none of what you're suggesting addresses any of what I'm
referring to here, sure.

> In short, it would be nice if IP was build as modular as OSI, alas it isn't.

OSI is now and will remain dead. It was and is an elegant and
inclusive (and complex) approach, but one that utterly missed the
market. The delays in recognizing and adapting to what the customers
were actually using — and to cease trying to convince those same folks
to adopt and adapt to OSI — continues to have repercussions to this
day, too.

We will hopefully see better support for IPsec within OpenVMS over time
— and better IP support, for that matter — and we will have and will
use TLS for the foreseeable future, and will use the existing APIs and
OpenSSL APIs until something better becomes available. We will not be
particularly using is OSI, and we will be using less DECnet as existing
DECnet-based applications are extended or overhauled and as new
applications are created.

But again, I don't care if the network traffic is IPsec or TLS, so long
as it's securely encrypted and securely authenticated, and preferably
without having to deal (much) with glue code and sockets or TLS or DNS
or related and the associated error handling and
connection-verification processing. But then most of what I'm
communicating with is not using nor particularly even supporting an OSI
stack, either.

[Stephen Hoffman]

On 2016-12-09 20:14:49 +0000, Michael Moroney said:

> ...create a new transport layer that replaces TCP, handles all the

> encryption, but otherwise acts to a higher layer like TCP.

More than a few applications use REST via HTTPS for
application-to-application communications. It's less than elegant, but
it's ubiquitous, routable through most server- and client-side
firewalls, authenticated and encrypted, and there are various libraries
available that abstract most of the effort. This all gets back to
higher-level APIs, rather than needing the complexity and the glue code
and the code cruft — and the associated bugs — we had to deal with in
earlier years. Mucking around with TCP and OSI and the rest is a slog
that's a decade or more old, and rapidly getting older.

[David Froble]

The problem with NICs implementing something is that there will sooner or later
be the requirement for some type of upgrade. Maybe firmware could handle it.
But if not, with software, you just use it, with HW it's discard and buy new.

Other than that, sure, it would be great if the encryption was totally in the
communication HW.

[David Froble]

This always confuses me. For just about any IP communication, dig down far
enough and there is a socket. Perhaps masked from the user, but, it's there.

All HTTP, and such are, is agreed upon formatting of the data going between
sockets. Yes, sometimes helpful. For example, retrieving a piece of data
requires knowing the tags, and some simple parsing. But building all that
including data and the tags is a lot of work. Nor is there much "standard"
about it. Everyone uses the tags and data they require, and it's meaningless to
others.

Yeah, going to column such and such and getting x number of bytes can be maybe a
bit more complex to set up, but, when done, works as well as anything else.

Maybe it's just me, and everyone else likes the formatting, but, I cannot help
but think of it as "bloat".

[Bill Gunshannon]

Well, the one we did when I was working for TRWIND (Yes, that TRW)
downloaded the firmware so from the host (PC's, it was an EISA card)
so changes were actually fairly easy. Fact is, it was being done
to offload the work from the system CPU in order to get better
performance. That didn't happen so the idea died on the vine.

On a side note, weren't there there cards for the VAX that had some
or all of the networking on them? EXCELAN?

bill

[Stephen Hoffman]

On 2016-12-09 21:55:58 +0000, David Froble said:

> Stephen Hoffman wrote:
>> On 2016-12-09 20:14:49 +0000, Michael Moroney said:
>>
>>> ...create a new transport layer that replaces TCP, handles all the
>>> encryption, but otherwise acts to a higher layer like TCP.
>>
>> More than a few applications use REST via HTTPS for
>> application-to-application communications. It's less than elegant, but
>> it's ubiquitous, routable through most server- and client-side
>> firewalls, authenticated and encrypted, and there are various libraries
>> available that abstract most of the effort. This all gets back to
>> higher-level APIs, rather than needing the complexity and the glue code
>> and the code cruft — and the associated bugs — we had to deal with in
>> earlier years. Mucking around with TCP and OSI and the rest is a slog
>> that's a decade or more old, and rapidly getting older.
>
> This always confuses me. For just about any IP communication, dig down
> far enough and there is a socket. Perhaps masked from the user, but,
> it's there.

Yeah, I was once blind to the amount of glue code involved, too.

> All HTTP, and such are, is agreed upon formatting of the data going
> between sockets. Yes, sometimes helpful. For example, retrieving a
> piece of data requires knowing the tags, and some simple parsing. But
> building all that including data and the tags is a lot of work. Nor is
> there much "standard" about it. Everyone uses the tags and data they
> require, and it's meaningless to others.

Ayup. Application-specific stuff is application-specific, whether
it's REST via HTTPS, or the CORBA RPC of an earlier era, or
who-knows-what.

> Yeah, going to column such and such and getting x number of bytes can
> be maybe a bit more complex to set up, but, when done, works as well as
> anything else.

Message-based operations make upgrades and changes somewhat easier to
roll out. That's akin to what itemlists provide for flexibility
around system service calls, or what descriptors provide BASIC, but an
order or two of magnitude easier and more flexible and with less glue
code, too. RMS record-level definitions or byte-encoded fields are
great, right up until you have to change or migrate them. If you have
a window for an outage, then migrations are easier. If you have to
run across versions or otherwise change field sizes — where you have to
support old and new clients or old and new servers in parallel — not so
much.

> Maybe it's just me, and everyone else likes the formatting, but, I
> cannot help but think of it as "bloat".

It's trade-offs all the way down. Bloat that makes it easier and/or
faster to develop and/or more reliable and more secure applications for
a developer can be worth the added bloat. Much like the ~forty year
old debates over the bloat added by HLLs over the (usually) more
run-time efficient assembler programming, or the debates between the
all-encompassing and elegant solutions such as OSI over the far less
elegant but ubiquitous IP networking, HLLs were bloat and IP was and
still is a mess, but it works well enough to have carried the day.
There are undoubtedly times when we might still need to bum
instructions — other than playing code golf — and stuff application
code into constrained RAM or EEPROM or some capacity-limited
distribution medium, or carefully tune and tweak application
performance at the instruction level, but those requirements are a
whole lot less common than they used to be. Time to market with a
product customers via as sufficiently viable for their needs at a price
they're willing to pay — unlike what happened with OSI, for instance.

[Dirk Munk]

Bill Gunshannon wrote:
> On 12/9/16 12:51 PM, Dirk Munk wrote:
>> Stephen Hoffman wrote:
>>> On 2016-12-08 17:53:21 +0000, Dirk Munk said:
>>>
>>>> I totally agree, and I think for VMS <> VMS traffic (cluster over IP +
>>>> normal IP + DECnet over IP) using IPsec should be the standard since
>>>> it covers all IP traffic.
>>>>
>>>> Of course VMS <> other OS should also be over IPsec, certainly when
>>>> we're talking about constant (non ad-hoc) connections.
>>>>
>>>> I hope someone will write a manual how to set it all up, covering for
>>>> instance VMS, Linux and Windows.
>>>
>>> Documentation for developers, certainly. For end users, manuals are
>>> the exact wrong approach. That must be done transparently, correctly,
>>> at install time.
>>>
>>> I don't care if the network traffic is IPsec or TLS, so long as it's
>>> securely encrypted and securely authenticated.
>>
>> IPsec is encryption at the IP level, all IP traffic between two nodes
>> will be encrypted. There's only one port in use (6000),
>
> Are you sure about that? 6000 is X-windows and most sites block it
> for good reason. I think what you want is ports 500, 50 and 51.

Correct, my mistake.

>
>> very easy for
>> firewall rules. Furthermore IPsec can be handled by the NIC.
>
> By what NIC? I remember working for companies that were developing
> smart NICs (where did you think all those 80186 cpus went) and they
> went over like a lead baloon.
>

The Intel 82599 for instance. There may be more, but unfortunately
finding proper specification sheets is getting more and more difficult.

Every $10 NIC has a TCP offload engine these days, and there are NIC's
with iSCSI and FCOE offload engines as well.

The encryption engines will be in hardware, not in software.


> bill
>
>

[Dirk Munk]

I don't understand what you mean. As far as I'm aware, IPsec has nothing
to do with any application (except for management perhaps). It is
completely transparent for all IP traffic, for all applications that use
IP.

A very simple example. Your touter at home can set up a tunnel with
another router. It's done using IPsec, and all traffic between both
routers is encrypted.

The same applies to two hosts connected using IPsec. That's the beauty
of it.

> IPsec is a great approach, but it's still not
> common.

Not commonly in use perhaps, but present in any decent IP stack. If
we're talking about a company connecting it's servers locally or over
the internet, setting up IPsec to connect all nodes would certainly be a
priority for me. Perhaps a bit of a headache to set it up (that's why I
asked for a good manual), but once it's running you can sit down and
relax, all your IP traffic will be safe. No need for firewalls, only
ports 500, 50 and 51 are in use.

> OpenVMS lacks it within the vendor IP stack, for instance.

Yes, but it is in the new 10.5 stack.

> TLS is more portable, and more common. Neither IPsec nor TLS target
> the entirety of what clients and servers are looking to do, too.
>
> All of this has been going 'round and 'round, and TLS and IP have been
> irritating
>
>> There's only one port in use (6000), very easy for firewall rules.
>> Furthermore IPsec can be handled by the NIC.
>
> An increasing number of network services are using REST via TLS on TCP
> 443, for better or worse.
>
> Getting the rest of the 'net to move to TCP 6000 just isn't happening.
>
>> In the 7-layer OSI network stack,
>
> As HBVS and particularly ZFS have clearly shown, the classic layering
> abstractions can sometimes introduce problems and limitations, too.
> But I digress.
>
>> TLS can be added to the transport layer,
>
> Hmmmm.... I wonder what the T in TLS represents?
>
>> and it then works for all applications.
>
> For some definitions of "it works", because it doesn't work for all
> applications. But then that's been the fundamental problem with OSI,
> it solved everything, and utterly missed the market because of that.
>

Yes I know, quick and dirty is still the preferred approach in ICT land.
However in the end it will always be more costly, and more cumbersome
then a better approach would have been. The present IPv4 to IPv6
migration is a beautiful example of that.

>> Unfortunately IP has only four layers, and that is the reason that TLS
>> has to be added to each and every application that needs to be
>> encrypted, and each application has to be updated when TLS needs an
>> update.
>
> Unfortunately IP is what we have, so we get to work within that.

I know

>
>>> Having TLS and DTLS support in the kernel,
>>
>> Perhaps, it would be even nicer if it also could be handled by the
>> NIC, but I suppose that is not possible.
>
> DESNC, but — in this era — that would still require interaction with the
> host software and application around pinning and authentication.
>
>>> and rather less of a dog's breakfast around certificate handling and
>>> vastly upgraded network transport APIs is also a given, of course.
>>
>> Sure, it would be great if it was a callable library as was suggested
>> here.
>
> Other than none of what you're suggesting addresses any of what I'm
> referring to here, sure.
>
>> In short, it would be nice if IP was build as modular as OSI, alas it
>> isn't.
>
> OSI is now and will remain dead. It was and is an elegant and
> inclusive (and complex) approach, but one that utterly missed the
> market.

Or perhaps the market missed OSI

[Paul Sture]

On 2016-12-08, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2016-12-06 01:30:22 +0000, David Froble said:
>
>> Perhaps rather than voting, we assign political office to those who
>> don't get hacked?
>>
>> :-)
>
> Interesting proposal. But that's to ensure you're never "assigned"
> politial office, given your ongoing use of Windows 2000, right?
>
> 😈
>

The trouble with such a proposal is that it raises a challenge to
those capable of meeting it.

--
Irregular English verbs:
I have an independent mind
You are an eccentric
He is round the twist

[Bill Gunshannon]

But how many will actually use them that way? TRWIND sold lots
of those smart NICs. I had a small handful when I left them and
used them until ISA went the way of the dodo. Most people just
popped the 80186 out and used them as standard dumb NICs.

bill

[Bill Gunshannon]

Not to mention running apps in SSH over IP. The University blocked port
6000 for probably my last 15 years but I still ran it with a display at
home by tunneling over SSH. There is almost always more than one way to
solve these problems.

bill

[Stephen Hoffman]

On 2016-12-10 11:33:43 +0000, Dirk Munk said:

> I don't understand what you mean.

Um, that dragging the corpse of OSI out of the crypt during even a
severe network thunderstorm won't ever reanimate it? 😀

> As far as I'm aware, IPsec has nothing to do with any application
> (except for management perhaps). It is completely transparent for all
> IP traffic, for all applications that use IP.

Nothing is ever completely transparent, as applications have to deal
with at least requesting the security required and contending with the
errors and notifications that inevitably arise. Having a connection
blow up in the middle, or to get MITM'd successfully or otherwise, or
to ascertain the identity of the specific client or server based on a
certificate, are details that a secure application are probably going
to want to know about, after all.

But as I have repeatedly stated here, I really don't care if it's IPsec
or TLS underneath.

> A very simple example. Your touter at home can set up a tunnel with
> another router. It's done using IPsec, and all traffic between both
> routers is encrypted.

Few folks want to recreate a DESNC-style connection in this era.
End-to-end is preferred. Particularly over what is an explicitly
MITM'd connection, and one that inherently cannot verify the end-points
of the connection.

Put another way, I cannot imagine setting up a connection such as this,
save for connecting to a system with utterly incompetent security.

> The same applies to two hosts connected using IPsec. That's the beauty of it.

Other than that there's no IPsec on OpenVMS via the vendor stack, and
other than that IPsec isn't as ubiquitous as any of us would prefer,
sure.

But as I've repeatedly stated, I don't care what's downstairs from a
(simpler!) API, wither it's TLS or IPsec or such, or a slightly
higher-layer HTTPS or otherwise.

>> IPsec is a great approach, but it's still not common.
>
> Not commonly in use perhaps, but present in any decent IP stack.

Not commonly used is not commonly used.

If I have to set up a DESNC or a VPN server on the target network, or
install and configure OSI or IPsec or whatever else, beauty and
elegance can lose some of its luster, and the installation and support
costs can go up.

But I'm not inclined to continue the TLS versus IPsec debate — that
debate raged fifteen years ago. For uses where arbitrary connections
are required for application-to-application communcations, TLS largely
won. For VPNs and dedicated connections, IPsec or various other VPN
protocols or even network bridging over a secure link — how DECnet
Phase IV can connect site-to-site, for instance — all works fine.

For those interested in and unfamiliar with the discussion and the
trade-offs, here's a decent write-up:
https://www.k2esec.com/network-security-protocols-ipsec-vs-tlsssl-vs-ssh-part-ii/


Added atop that debate is my preference for a vastly improved API, as
part of an effort to improve or overhaul the crypto and authentication
support and the general socket-level and DNS-related efforts within
OpenVMS. There's way too much glue code involved in that, and some of
the sequences are quite arcane. Much like how many of the OpenVMS
programming languages abstracted the complexity of RMS through various
language extensions, the network stack needs to be much simpler and
more abstract for the most common client and server operations, with
sockets or $qio or $io_perform interfaces and the libtls or OpenSSL
APLs remaining available for those applications and tasks that need
that control. I'd prefer OO here for ease of future work, but that's
probably a bridge too far for existing applications and designs.

> If we're talking about a company connecting it's servers locally or
> over the internet, setting up IPsec to connect all nodes would
> certainly be a priority for me.

I am discussing the utterly absurd state of the OpenVMS APIs available
for establishing and securing network connections, and the associated
difficulties around that, when communicating with a variety of remote
hosts where I may or may not have control over the other end of the
connection and the remote gateway box, If you want to set up a
DESNC-secured OSI link for DECnet Phase V or other such, or a
gateway-to-gateway VPN, have at. Those are certainly valid for some
applications. Those approaches do utterly lack the ability to
establish end-to-end connections, they also mean there's no way to
verify remote identity within the applications, and DESNC- or
gateway-based VPNs do pile prerequisites into the network
infrastructure; dependencies and setup steps outside of the constituent
client and server application code.

> Perhaps a bit of a headache to set it up (that's why I asked for a good
> manual), but once it's running you can sit down and relax, all your IP
> traffic will be safe. No need for firewalls, only ports 500, 50 and 51
> are in use.

I'm guessing you were referring to a mix of ports and protocols there,
as AFAIK ports 50 and 51 aren't used in any context related to what I'm
discussing. Again, if you can institute requirements on the remote
network, then IPsec or a VPN or even OSI is certainly feasible. And I
don't really care what's underneath the particular application API, so
long as I can authenticate the connection, and the network traffic is
securely encrypted.

> Yes I know, quick and dirty is still the preferred approach in ICT
> land. However in the end it will always be more costly, and more
> cumbersome then a better approach would have been. The present IPv4 to
> IPv6 migration is a beautiful example of that.

Ayup. Now imagine how long it'll take to get everybody over to IPsec
or over to OSI.

>> OSI is now and will remain dead. It was and is an elegant and
>> inclusive (and complex) approach, but one that utterly missed the
>> market.
>
> Or perhaps the market missed OSI

Thankfully.

For anybody reading that might be planning to attend business school,
you might want to research where the OSI effort went wrong, why an
all-inclusive and complex solution that arrived late is problematic,
and why the customers decided to roll out the good-enough IP stack, and
where that's all led. OSI tried to do everything up front, IP did
less and rolled out with incremental changes in the stacks and in
applications. It's rather fascinating stuff to ponder, including
around what happened to the products and platforms that didn't adapt to
and accept the ascendence of IP as quickly as others.

[Dirk Munk]

The drivers will take care that the functionality will be used. I'm not
an expert on how the Windows or Linux IP stacks are build, but I didn't
have to do anything to use the TCP offload engine of the Realtek NIC in
my laptop. The only thing I do is enabling jumbo packets.

[Dirk Munk]

Well, since today we know you would be without a government.

[Richard Maher]

On 03-Dec-16 4:33 AM, Dirk Munk wrote:
>
> We all know what has to happen if you want tu use SSL/TLS with an
> application, you have incorporate it in the application. At least, that
> is the way it is done with IP. So if you want to use it with 20
> applications, you have to incorporate in each and everyone of those 20
> applications. If there is a new release of TLS, you have to rebuild 20
> applications. Fun isn't it?
>

IPSEC?

[David Froble]

Don't tease me ....