[Info-vax] DECserver/LAT across DECnet areas?

[Arne Vajhøj]

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 at panix.com> wrote:
>>> Andy Burns  <usenet at 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