On Monday, July 24, 2023 at 9:43:07 AM UTC-4, Johnny Billquist wrote:
> On 2023-07-24 05:54, terry-...@glaver.org wrote:
> > You can find it at https://www.glaver.org/ftp/tmk-software/mop-server
> > Give that server a little time to respond - it is hauling a virtual Alpha
> > out of the freezer to serve those files.
> That is really cool. Something to spread to the RSTS/E managers on HECnet....

They might also be interested in Finger-11:
https://www.glaver.org/ftp/tmk-software/finger11

That is a full implementation of Finger for RSTS/E. It can even reach
IP and unknown DECnet hosts if the name of a router (typically a VMS
system) is configured.

For historical amusement, there's MS-DOS Finger:
https://www.glaver.org/ftp/tmk-software/msfinger

Which can similarly reach IP and unknown DECnet hosts the same way.
If run as just "finger", the user will see:

You are the only user, of course.

8-}

On 2023-07-24, terry-...@glaver.org <terry-groups@glaver.org> wrote:
>
> If run as just "finger", the user will see:
>
> You are the only user, of course.
>
> 8-}

Are you sure about that ? :-)

https://en.wikipedia.org/wiki/DESQview

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-07-24, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Ok, you people are confusing me. (Not hard to do these days.)
>
> Is it being claimed that there are implementations of HTTP/HTTPS that do not use
> sockets?
>

No. The claim is that HTTPS in becoming the protocol "base layer"
that people write applications against instead of the underlying TCP/IP
layer.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-07-24 17:22:31 +0000, Simon Clubley said:

> On 2023-07-24, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Ok, you people are confusing me. (Not hard to do these days.)
>>
>> Is it being claimed that there are implementations of HTTP/HTTPS that
>> do not use sockets?
>>
>
> No. The claim is that HTTPS in becoming the protocol "base layer" that
> people write applications against instead of the underlying TCP/IP
> layer.

REST connections are common for apps. OpenVMS lacks integrated
libraries and frameworks for using that approach, though.

REST is good for shoveling around requests and responses, and not so
good at transactions and shoveling whole databases around.

REST is particularly good at connecting mobile apps to outside
networks, as HTTPS connections are only rarely blocked.

ActiveMQ, ActiveMQ Artemis, RabbitMQ, and ilk work better for transactions.

But these discussions all go back decades. Arguably, X is an RPC with
graphics support bolted on, for instance.

--
Pure Personal Opinion | HoffmanLabs LLC

On 7/24/2023 1:22 PM, Simon Clubley wrote:
> On 2023-07-24, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Ok, you people are confusing me. (Not hard to do these days.)
>>
>> Is it being claimed that there are implementations of HTTP/HTTPS that do not use
>> sockets?
>>
>
> No. The claim is that HTTPS in becoming the protocol "base layer"
> that people write applications against instead of the underlying TCP/IP
> layer.
>
> Simon.
>

Johnny wrote:

I know that there have even been implementations of IP over http...

???

Dave prefers sockets, and has even written his own HTTP routines ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 7/24/2023 9:28 AM, Johnny Billquist wrote:
> On 2023-07-22 20:41, Arne Vajhøj wrote:
>> Non-routed bridged-only long distance net would work around
>> the non-routable characteristics of LAT.
>>
>> But my experience with LAT (30-35 years ago) is that it is also
>> where latency sensitive. Excessive delays results in timeout errors.
>
> Been using bridge to run LAT across the whole world, carried over UDP.
> Works just fine everywhere I've tried.
>
> The internet is sooo fast these days that LAT timeouts are close to
> eternity in comparison.

As I remember it then just putting more than 2 bridges between
the two ends within the same building was enough to cause timeouts.

And while internet bandwidth has exploded then latency has not
been similarly reduced. Small technical problem called
speed of light.

Arne

On 7/24/2023 6:25 PM, Dave Froble wrote:
> On 7/24/2023 1:22 PM, Simon Clubley wrote:
>> On 2023-07-24, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> Ok, you people are confusing me.  (Not hard to do these days.)
>>>
>>> Is it being claimed that there are implementations of HTTP/HTTPS that
>>> do not use
>>> sockets?
>>
>> No. The claim is that HTTPS in becoming the protocol "base layer"
>> that people write applications against instead of the underlying TCP/IP
>> layer.
>
> Johnny wrote:
>
> I know that there have even been implementations of IP over http...
>
> ???

You can tunnel everything over HTTP.

---(X)--->program that pack in HTTP---(payload with
X/HTTP/TCP/IP)--->program that unpack from HTTP---(X)--->

X could be IP packets.

I have not heard about it but I can not see why it can't be done.

Arne

On 7/24/2023 6:24 AM, Fred. Zwarts wrote:
> Op 23.jul..2023 om 02:18 schreef Arne Vajhøj:
>> On 7/22/2023 7:07 PM, Scott Dorsey wrote:
>>> LAT is not decnet.  Vaxcluster isn't decnet either.  LAT is its own
>>> protocol,
>>
>> Yes.
>>
>> 0800 IPv4
>> 0806 ARP
>> 6001 MOP load
>> 6003 DECnet
>> 6004 LAT
>> 6007 SCA/LAVC
>
> 86DD    IPv6
>
> For a complete list see https://en.wikipedia.org/wiki/EtherType

https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml

got more.

Arne

On Monday, July 24, 2023 at 6:50:22 PM UTC-4, Arne Vajhøj wrote:
> You can tunnel everything over HTTP.
>
> ---(X)--->program that pack in HTTP---(payload with
> X/HTTP/TCP/IP)--->program that unpack from HTTP---(X)--->
>
> X could be IP packets.
>
> I have not heard about it but I can not see why it can't be done.

There are published tools to tunnel IP inside DNS requests. For
example, https://github.com/yarrick/iodine

On 7/24/2023 9:58 AM, Johnny Billquist wrote:
> On 2023-07-24 14:56, Simon Clubley wrote:
>> On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
>>> Andy Burns  <usenet@andyburns.uk> wrote:
>>>> Scott Dorsey wrote:
>>>>
>>>>> This is culturally very different than modern systems where everything
>>>>> is running IP and only what is on top of TCP or UDP is different.
>>>>
>>>> We're pretty close to the next stage where everything is running on top
>>>> of HTTPS, aren't we?
>>>
>>
>> Good.
>
> Not.
>
>>> Please don't remind me.  It's a horrible idea to contemplate, isn't it?
>>
>>  From a security point of view, it (or something similar) is a really
>> good idea.
>
> Have you ever heard of "all eggs in one basket"? It's generally not a
> good idea. When a security issue appears, *everything* is then
> voulnerable. Having multiple solutions, implementations and technologies
> carries a cost, but it also reduces risks in one way. Yes, you might
> have a higher chance of having an exploit, but the consequences are much
> less damaging. And you will always have exploits. And thus, any argument
> about the number of exploits have to acknowledge that first of all,
> there will be exlpoits. So, talking about limiting the damages is the
> more reasonable/interesting thing to do.

I don't see HTTP as being particular relevant for security - so neither
good nor bad.

We have stack like:

application protocol
HTTP protocol
transport - either plain TCP or SSL

The application protocol may or may not contain security
features and if it does then they may be good or bad.

TCP has no security features. SSL has security features
that are constantly attacked which is why anything below
TLS 1.2 is no good today.

But HTTP?

It defines some standard headers and allow for custom
headers and a BLOB body.

I really don't see anything security relevant.

Which is probably also why there is a gap of 18 years
between version 1.1 and 2.0. The vulnerabilities was
never at the HTTP level.

And HTTP 2.0 (by convention called HTTP/2) is not
about security fixes but about performance fixes.

Arne

On 7/24/2023 4:40 PM, Stephen Hoffman wrote:
> REST connections are common for apps. OpenVMS lacks integrated libraries
> and frameworks for using that approach, though.
>
> REST is good for shoveling around requests and responses, and not so
> good at transactions and shoveling whole databases around.
>
> REST is particularly good at connecting mobile apps to outside networks,
> as HTTPS connections are only rarely blocked.

I am sure Hoff knows but just so that everyone gets it:
* REST style web services and RPC style web services are two
different styles of API - REST style is based on CRUD of
data - RPC style is mimicking method calls
* RESTful (REST style) web services are typical either
JSON/HTTP(S) or XML/HTTP(S)
* today JSON/HTTP(S) is way more common than XML/HTTP(S)
(more compact format)
* among those not familiar with the history of web services
REST is sometimes used as synonym for JSON/HTTP(S) also
if the service really is more RPC style

> ActiveMQ, ActiveMQ Artemis, RabbitMQ, and ilk work better for transactions.

Yes.

The support both normal transactions and XA transactions.

Today message queues are part of most transaction processing
solutions.

Arne

On 2023-07-25 00:41, Arne Vajhøj wrote:
> On 7/24/2023 9:28 AM, Johnny Billquist wrote:
>> On 2023-07-22 20:41, Arne Vajhøj wrote:
>>> Non-routed bridged-only long distance net would work around
>>> the non-routable characteristics of LAT.
>>>
>>> But my experience with LAT (30-35 years ago) is that it is also
>>> where latency sensitive. Excessive delays results in timeout errors.
>>
>> Been using bridge to run LAT across the whole world, carried over UDP.
>> Works just fine everywhere I've tried.
>>
>> The internet is sooo fast these days that LAT timeouts are close to
>> eternity in comparison.
>
> As I remember it then just putting more than 2 bridges between
> the two ends within the same building was enough to cause timeouts.
>
> And while internet bandwidth has exploded then latency has not
> been similarly reduced. Small technical problem called
> speed of light.

Well. If you refuse to believe me when I say that around the whole world
on a bridged ethernet running LAT works fine, then there isn't much I
can do for you.

You can fetch the bridge here: http://mim.stupi.net/bridge.tar
and then you can try yourself.

Johnny

On 2023-07-24 17:52, terry-...@glaver.org wrote:
> On Monday, July 24, 2023 at 9:43:07 AM UTC-4, Johnny Billquist wrote:
>> On 2023-07-24 05:54, terry-...@glaver.org wrote:
>>> You can find it at https://www.glaver.org/ftp/tmk-software/mop-server
>>> Give that server a little time to respond - it is hauling a virtual Alpha
>>> out of the freezer to serve those files.
>> That is really cool. Something to spread to the RSTS/E managers on HECnet...
>
> They might also be interested in Finger-11:
> https://www.glaver.org/ftp/tmk-software/finger11

I remember seeing implementation of that one for RSX as well.
I wrote my own, which works over IP, but I never bothered with DECnet.
Maybe I should...

> That is a full implementation of Finger for RSTS/E. It can even reach
> IP and unknown DECnet hosts if the name of a router (typically a VMS
> system) is configured.
>
> For historical amusement, there's MS-DOS Finger:
> https://www.glaver.org/ftp/tmk-software/msfinger
>
> Which can similarly reach IP and unknown DECnet hosts the same way.

Hmm. MS-DOS and DECnet? You'll need Pathworks then?

> If run as just "finger", the user will see:
>
> You are the only user, of course.
>
> 8-}

:-)

On 2023-07-25 01:02, Arne Vajhøj wrote:
> On 7/24/2023 9:58 AM, Johnny Billquist wrote:
>> On 2023-07-24 14:56, Simon Clubley wrote:
>>> On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
>>>> Andy Burns  <usenet@andyburns.uk> wrote:
>>>>> Scott Dorsey wrote:
>>>>>
>>>>>> This is culturally very different than modern systems where
>>>>>> everything
>>>>>> is running IP and only what is on top of TCP or UDP is different.
>>>>>
>>>>> We're pretty close to the next stage where everything is running on
>>>>> top
>>>>> of HTTPS, aren't we?
>>>>
>>>
>>> Good.
>>
>> Not.
>>
>>>> Please don't remind me.  It's a horrible idea to contemplate, isn't it?
>>>
>>>  From a security point of view, it (or something similar) is a really
>>> good idea.
>>
>> Have you ever heard of "all eggs in one basket"? It's generally not a
>> good idea. When a security issue appears, *everything* is then
>> voulnerable. Having multiple solutions, implementations and
>> technologies carries a cost, but it also reduces risks in one way.
>> Yes, you might have a higher chance of having an exploit, but the
>> consequences are much less damaging. And you will always have
>> exploits. And thus, any argument about the number of exploits have to
>> acknowledge that first of all, there will be exlpoits. So, talking
>> about limiting the damages is the more reasonable/interesting thing to
>> do.
>
> I don't see HTTP as being particular relevant for security - so neither
> good nor bad.
>
> We have stack like:
>
> application protocol
> HTTP protocol
> transport - either plain TCP or SSL
>
> The application protocol may or may not contain security
> features and if it does then they may be good or bad.
>
> TCP has no security features. SSL has security features
> that are constantly attacked which is why anything below
> TLS 1.2 is no good today.
>
> But HTTP?

Did you miss the "S" at the end? As in "HTTPS".

Johnny

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
>> Andy Burns <usenet@andyburns.uk> wrote:
>>>Scott Dorsey wrote:
>>>
>>>> This is culturally very different than modern systems where everything
>>>> is running IP and only what is on top of TCP or UDP is different.
>>>
>>>We're pretty close to the next stage where everything is running on top
>>>of HTTPS, aren't we?
>>
>
>Good.
>
>> Please don't remind me. It's a horrible idea to contemplate, isn't it?
>
>From a security point of view, it (or something similar) is a really
>good idea.

Are you sure about that? It sure seems like putting all your eggs into
one basket to me. Not to mention the added overhead from all those layers.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 7/24/2023 7:33 PM, Johnny Billquist wrote:
> On 2023-07-25 01:02, Arne Vajhøj wrote:
>> On 7/24/2023 9:58 AM, Johnny Billquist wrote:
>>> On 2023-07-24 14:56, Simon Clubley wrote:
>>>> On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
>>>>> Please don't remind me.  It's a horrible idea to contemplate, isn't
>>>>> it?
>>>>
>>>>  From a security point of view, it (or something similar) is a really
>>>> good idea.
>>>
>>> Have you ever heard of "all eggs in one basket"? It's generally not a
>>> good idea. When a security issue appears, *everything* is then
>>> voulnerable. Having multiple solutions, implementations and
>>> technologies carries a cost, but it also reduces risks in one way.
>>> Yes, you might have a higher chance of having an exploit, but the
>>> consequences are much less damaging. And you will always have
>>> exploits. And thus, any argument about the number of exploits have to
>>> acknowledge that first of all, there will be exlpoits. So, talking
>>> about limiting the damages is the more reasonable/interesting thing
>>> to do.
>>
>> I don't see HTTP as being particular relevant for security - so neither
>> good nor bad.
>>
>> We have stack like:
>>
>> application protocol
>> HTTP protocol
>> transport - either plain TCP or SSL
>>
>> The application protocol may or may not contain security
>> features and if it does then they may be good or bad.
>>
>> TCP has no security features. SSL has security features
>> that are constantly attacked which is why anything below
>> TLS 1.2 is no good today.
>>
>> But HTTP?
>
> Did you miss the "S" at the end? As in "HTTPS".

HTTPS is not really a protocol. HTTPS is HTTP over SSL.

I don't see problem at the HTTP level.

At the SSL level maybe.

It is an observable fact that there has been numerous
vulnerabilities related to SSL usage. Which is why it
is constantly being updated.

But there are two types of problems with SSL usage.
Those that relate to SSL itself and those that
relates to the underlying algorithms.

If an alternative transport protocol XXX was invented
and HTTPX as HTTP over XXX was defined, then HTTPX would
be just as vulnerable to the algorithmic problems.

But a HTTPX would not change anything about web service
technology and its usage. URL's would start with httpx://
instead of https:// or http:// and they would need to
define a new default port instead of 443 and 80. But otherwise
business as usual.

Arne

On 7/24/2023 7:53 PM, Scott Dorsey wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
>>> Andy Burns <usenet@andyburns.uk> wrote:
>>>> Scott Dorsey wrote:
>>>>> This is culturally very different than modern systems where everything
>>>>> is running IP and only what is on top of TCP or UDP is different.
>>>>
>>>> We're pretty close to the next stage where everything is running on top
>>>> of HTTPS, aren't we?
>>
>> Good.
>>
>>> Please don't remind me. It's a horrible idea to contemplate, isn't it?
>>
>> From a security point of view, it (or something similar) is a really
>> good idea.
>
> Are you sure about that? It sure seems like putting all your eggs into
> one basket to me.

I will assume you are really talking about SSL.

Tt is only the TLS protocol itself that is all eggs in one
basket.

For the underlying algorithms then:
* TLS offers multiple choices for each category of algorithm
* an alternative algorithm would use the same algorithms and be
just as vulnerable if a problem in an algorithm was found

> Not to mention the added overhead from all those layers.

Are those layers that bad?

Sure SSL handshake takes time, but that is not due to the layers
but due to the nature of the key exchange.

Arne

On Monday, July 24, 2023 at 7:28:36 PM UTC-4, Johnny Billquist wrote:
> On 2023-07-24 17:52, terry-...@glaver.org wrote:
> > On Monday, July 24, 2023 at 9:43:07 AM UTC-4, Johnny Billquist wrote:
> >> On 2023-07-24 05:54, terry-...@glaver.org wrote:
> >>> You can find it at https://www.glaver.org/ftp/tmk-software/mop-server
> >>> Give that server a little time to respond - it is hauling a virtual Alpha
> >>> out of the freezer to serve those files.
> >> That is really cool. Something to spread to the RSTS/E managers on HECnet...
> >
> > They might also be interested in Finger-11:
> > https://www.glaver.org/ftp/tmk-software/finger11
> I remember seeing implementation of that one for RSX as well.
> I wrote my own, which works over IP, but I never bothered with DECnet.
> Maybe I should...
> > That is a full implementation of Finger for RSTS/E. It can even reach
> > IP and unknown DECnet hosts if the name of a router (typically a VMS
> > system) is configured.
> >
> > For historical amusement, there's MS-DOS Finger:
> > https://www.glaver.org/ftp/tmk-software/msfinger
> >
> > Which can similarly reach IP and unknown DECnet hosts the same way.
> Hmm. MS-DOS and DECnet? You'll need Pathworks then?

Yup - it's in the readme. It uses the DECnet stack from Pathworks
(or the nom de jour). I could have added IP, but the combination
of Pathworks, 3Com TCP/IP and QEMM-386 on MS-DOS was
quite a feat, and since the interest came from DEC, Pathworks
was in and TCP/IP was out.

> > If run as just "finger", the user will see:
> >
> > You are the only user, of course.
> >
> > 8-}
> :-)

terry-...@glaver.org wrote:

> There are published tools to tunnel IP inside DNS requests.

I have indeed used that to get free internet connection from hotel wifi

Arne Vajhøj wrote:

> Sure SSL handshake takes time, but that is not due to the layers
> but due to the nature of the key exchange.

QUIC cuts down on the handshake roundtrips

On 2023-07-24, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> But these discussions all go back decades. Arguably, X is an RPC with
> graphics support bolted on, for instance.
>

And unlike its replacement, this means it 1) actually works, and 2) can be
efficiently used across the network to display GUI applications running
on another server.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-07-24, Scott Dorsey <kludge@panix.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
>>> Andy Burns <usenet@andyburns.uk> wrote:
>>>>Scott Dorsey wrote:
>>>>
>>>>> This is culturally very different than modern systems where everything
>>>>> is running IP and only what is on top of TCP or UDP is different.
>>>>
>>>>We're pretty close to the next stage where everything is running on top
>>>>of HTTPS, aren't we?
>>>
>>
>>Good.
>>
>>> Please don't remind me. It's a horrible idea to contemplate, isn't it?
>>
>>From a security point of view, it (or something similar) is a really
>>good idea.
>
> Are you sure about that? It sure seems like putting all your eggs into
> one basket to me. Not to mention the added overhead from all those layers.

You should always take a multi-layered approach to security if possible
so if one layer gets breached, there's a good chance they will be stopped
by another layer.

Running over HTTPS is just one more added layer. Nothing more, but still
a very important additional layer.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 7/24/2023 8:06 PM, Arne Vajhøj wrote:
> On 7/24/2023 7:53 PM, Scott Dorsey wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
>>>> Andy Burns <usenet@andyburns.uk> wrote:
>>>>> Scott Dorsey wrote:
>>>>>> This is culturally very different than modern systems where everything
>>>>>> is running IP and only what is on top of TCP or UDP is different.
>>>>>
>>>>> We're pretty close to the next stage where everything is running on top
>>>>> of HTTPS, aren't we?
>>>
>>> Good.
>>>
>>>> Please don't remind me. It's a horrible idea to contemplate, isn't it?
>>>
>>> From a security point of view, it (or something similar) is a really
>>> good idea.
>>
>> Are you sure about that? It sure seems like putting all your eggs into
>> one basket to me.
>
> I will assume you are really talking about SSL.
>
> Tt is only the TLS protocol itself that is all eggs in one
> basket.
>
> For the underlying algorithms then:
> * TLS offers multiple choices for each category of algorithm
> * an alternative algorithm would use the same algorithms and be
> just as vulnerable if a problem in an algorithm was found
>
>> Not to mention the added overhead from all those layers.
>
> Are those layers that bad?

X + 1 is always greater than X ...

> Sure SSL handshake takes time, but that is not due to the layers
> but due to the nature of the key exchange.
>
> Arne
>
>
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2023-07-25 02:06, Arne Vajhøj wrote:
> On 7/24/2023 7:53 PM, Scott Dorsey wrote:
>>                    Not to mention the added overhead from all those
>> layers.
>
> Are those layers that bad?
>
> Sure SSL handshake takes time, but that is not due to the layers
> but due to the nature of the key exchange.

Let me put a question for you? Are there any number of layers, in your
opinion, where it becomes a problem?

1 layer? 10? 100? 1000? At which point does it become a problem, and
why? And if you say 100, for example. Why is 99 not a problem, but 100
is then?

And if everything is depending on TLS to provide security, then it means
if SSL is compromised, you have no security anywhere suddenly. That's
the "all eggs in one basket" point.

The fact that TLS supports multiple cryptos does not suddenly make it
several different baskets.
TLS have a common framework, which is one single piece, and it's also
always a negotiation between the two sides on cryptos. So if you
identify a problem with a crypto, it's basically an open exploit
everywhere where you can negotiate that crypto. Which then would mean
pretty much everywhere, until that crypto is removed, which will
certainly take some time for a lot of places.

Yes, if someone else is also using that crypto, even without TLS, then
yes, that is just as vulnerable. But if they had used TLS, they would
not have been any less vulnerable. But if they have some other crypto,
or if the problem found would be in the TLS code itself, then you likely
dodged that bullet.

Anyway, this thread don't seem to be about VMS much at all anymore, and
not really contain much of interest in general, so let's lave it to die.

Johnny

On 7/25/2023 6:24 PM, Johnny Billquist wrote:
> On 2023-07-25 02:06, Arne Vajhøj wrote:
>> On 7/24/2023 7:53 PM, Scott Dorsey wrote:
>>>                    Not to mention the added overhead from all those
>>> layers.
>>
>> Are those layers that bad?
>>
>> Sure SSL handshake takes time, but that is not due to the layers
>> but due to the nature of the key exchange.
>
> Let me put a question for you? Are there any number of layers, in your
> opinion, where it becomes a problem?
>
> 1 layer? 10? 100? 1000? At which point does it become a problem, and
> why? And if you say 100, for example. Why is 99 not a problem, but 100
> is then?

Good question. And we all know how it is with answers to good
questions. :-)

It is in many ways similar to "how many software layers in an
application are too much?" and "how few lines per
routine/function/method is too much splitting up?".

There is not a single provable correct answer. Based on
some industry experience most have a feeling for when
a good thing becomes too much.

application protocol (the web service API's - not what is called
application layer in typical network stack pictures)
HTTP
TLS
TCP
IP
the more physical stuff

does not seem to be too much. It get used. And the number of
layers is not a frequent complaint.

The (in)famous OSI model was considered to be too much. Not only
because of the number of layers, but still.

So it seems to me that experience shows around 7-8 being too
much.

> And if everything is depending on TLS to provide security, then it means
> if SSL is compromised, you have no security anywhere suddenly. That's
> the "all eggs in one basket" point.
>
> The fact that TLS supports multiple cryptos does not suddenly make it
> several different baskets.
> TLS have a common framework, which is one single piece, and it's also
> always a negotiation between the two sides on cryptos. So if you
> identify a problem with a crypto, it's basically an open exploit
> everywhere where you can negotiate that crypto. Which then would mean
> pretty much everywhere, until that crypto is removed, which will
> certainly take some time for a lot of places.

TLS has a single point of failure in itself (unless one
consider 1.2 and 1.3 to be sufficient different to provide
some redundancy) but some redundancy in the algorithms.

Redundancy in algorithms is I believe a design goal in itself.
SHA-3 was not created because SHA-2 was considered weak - it
was create to have two alternatives.

It does not take that long time to disable old algorithms and
enable new ones. In case of emergency it could happen very
quickly. Servers get patched and people have to update their
browsers if they want to access the servers.

It takes extremely long time to create and check new
algorithms. Which is why it makes sense to have more than
one algorithm in a given category on the shelf.

I have no idea about how long time it takes to create
a new TLS version. If it takes years then having an
alternative on the shelf may make sense. 1.4A and 1.4B
that are sufficiently different to not be vulnerable to
same problem.

> Yes, if someone else is also using that crypto, even without TLS, then
> yes, that is just as vulnerable. But if they had used TLS, they would
> not have been any less vulnerable. But if they have some other crypto,
> or if the problem found would be in the TLS code itself, then you likely
> dodged that bullet.

Algorithm ABC used in TLS and algorithm ABC used in XXX are
obviously the same.

But unless XXX would a standard with huge industry support, then
XXX would be more risky than TLS.

The effort that goes into checking TLS is huge. It would cost
thousands maybe tens of thousands of man years to check
XXX to the same level as TLS.

Arne