Subject: Port 80 deprecation

From: "Soni L." <[email-masked]>
Date: Wed, 2 Jun 2021 08:12:10 -0300

So uh, with TLS-SRP around, there's no real reason to keep supporting
port 80, as every use-case supported by port 80 can be handled with
TLS-SRP instead.

In particular, LAN/embedded can be handled with TLS-SRP, with great
benefits:
- It's TLS, which, for browsers, makes it a secure context.
- Deprecating port 80 would free it up for other uses. There are only
65535 port numbers, but way more than 65535 applications that use them.
Not only that, but a single application may even use multiple ports!
- Actually encourages IoT devices to provide security by default.

Thoughts?

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 03 Jun 2021 00:23:08 +0000

Let's not get ahead of ourselves.

Port 80 is still heavily used.

Suggest revisiting this idea in maybe 50 years.

Adrien

---

From: Paul Vixie <[email-masked]>
Date: Thu, 3 Jun 2021 02:15:42 +0000

> Suggest revisiting this idea in maybe 50 years.

TCP/80 will remain in use for vm-internal and hypervisor-scale API's
for much longer than 50 years. it's nice that we have a null-crypto
option on TCP/443 now, but negotiating that across shared silicon when
the endpoints all share a von neumann domain is complexity we would
never be grateful for. it may also have a long life on disconnected
LANs.

so, +2.

-- 
Paul Vixie

---

From: "Soni L." <[email-masked]>
Date: Wed, 2 Jun 2021 23:54:55 -0300

> never be grateful for. it may also have a long life on disconnected
Have you heard of asymmetric PAKE (TLS-SRP)? It's kinda, perfect for LAN
(and by extension VM-internal/hypervisor-scale). Would be great to
replace TCP/80 with PAKEs on TCP/443 and UDP/443.

There are definitely enough paths for the deprecation of TCP/80. We just
have to use them. Less error prone than DIY CA and doesn't involve
configuring null-crypto.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Jun 2021 05:22:01 +0200

> replace TCP/80 with PAKEs on TCP/443 and UDP/443.

You seem to be in favor of purposely ignoring 30 years of deployed
components, applications and contents that are readily available and
working fine and that don't need to be trashed every single time a
new protocol extension suggests it could work for them.

I know that destroying human-created digital contents will be the
specificity of the 21th century but I don't see any compelling reason
for accelerating this (sad) trend. What is accessible can remain
accessible for as long as there are people interested in it.

Instead maybe you should write an article recommending the use of TLS-SRP
for a number of use cases where you think it will provide a benefit
over using port 80 (or clear communication over any other port), but
I think you'll have to orient it towards "if you were considering
deploying over 80 to avoid the hassle of configuring and managing
TLS, there's another option that might work for you".

Regards,
Willy

---

From: Paul Vixie <[email-masked]>
Date: Thu, 3 Jun 2021 04:05:15 +0000

> replace TCP/80 with PAKEs on TCP/443 and UDP/443.

forgive me for referring to it informally as "a null-crypto option on
TCP/443" above. but yes, i know about that.

> have to use them. Less error prone than DIY CA and doesn't involve

non-upgradable devices will never go out of style. this installed base is
not subject to deprecation pressure. industrial control systems are far less
tractible than web browsers.

the analogue to this is IPv4. at some point the IETF said, everybody should
switch to IPv6, and to facilitate that, there will be no more protocol
enhancement actions to IPv4. if you want to innovate, do it in IPv6.

we could say that about TCP/80. but we won't be taken seriously if use the
word "deprecate".

-- 
Paul Vixie

---

From: Eric J Bowman <[email-masked]>
Date: Wed, 02 Jun 2021 21:40:09 -0700

If Port 80 is deprecated, we'll need to re-brand. I propose SSS... Spherical Sweeping Snare. ;)

-Eric

---- On Wed, 02 Jun 2021 21:05:15 -0700 Paul Vixie <[email-masked]> wrote ----

 

 
 
-- 
Paul Vixie

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Jun 2021 13:43:24 +0200

Which RFC that is updating RFC8446 is providing null crypto ?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 3 Jun 2021 17:31:53 +0200

On Thu, Jun 03, 2021 at 01:43:24PM +0200,
 Toerless Eckert <[email-masked]> wrote 

> Which RFC that is updating RFC8446 is providing null crypto ?

And pardon a crypto-ignorant, but what is the relationship between
PAKEs and "null crypto"? (Yes, I've read RFC 2945 and 5054.)

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 5 Jun 2021 11:05:15 +0300

>From IANA registry (despite not having "NULL" in name, these are NULL
ciphersuites):

    0xC0,0xB4   TLS_SHA256_SHA256  Y N   [draft-camwinget-tls-ts13-macciphersuites]
    0xC0,0xB5   TLS_SHA384_SHA384  Y N   [draft-camwinget-tls-ts13-macciphersuites]

The "Y N" there means: OK for DTLS, Not recommended.

However, these might not deliver the best throughput. If platform has
SIMD but no hardware SHA-2 acceleration, Chacha20-Poly1305 likely
delivers better throughput. If platform has hardware AES-GCM
acceleration, AES-GCM is likely higher throughput regardless of if
there is hardware SHA-2 acceleration or not (E.g., AMD Zen2 has both,
and AES-GCM is a lot faster).

And then record protection throughput might not be the biggest problem.
Having to do handshake and deal with possible peer authentication might
cause much more problems at application level, and NULL ciphers do
nothing for these issues.

-Ilari

---

From: Paul Vixie <[email-masked]>
Date: Sat, 5 Jun 2021 18:07:30 +0000

just be aware that i can't get a "localhost" certificate from an X.509 CA, and
that the overhead of running an in-house CA just to accomplish this unneccessary
purpose so that i can encrypt and decrypt data between processes who share a CPU,
is unthinkable. (the plaintext will be visible inside the process endpoints, so
there are literally not "on-path advesaries" to protect against.)

for web-style API's inside a system image or hypervisor, TLS will mostly not be
used. where it is used, global/universal domain names and IP addresses will have
to be used (to get the X.509 CA system to work), or a private CA will be used.
this would be all cost no benefit, so, infinitely bad cost:benefit ratio. "nope."

HTTP over TCP/80 is forever. but we can say something else if politically nec'y,
but that outcome will not change. i've already had to avoid a GoLang SMTP module
which had no non-SMTPS outbound capability and so could not talk to my private
PostFix server. the TLS-uber-alles mantra is going to lead to some real trouble.

-- 
Paul Vixie

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 07 Jun 2021 03:38:15 +0000

I'm waiting for someone to propose https for accessLocation for OCSP

Then we will have a nice little Gordian knot.

CRL checks also have to use http.

------ Original Message ------
From: "Paul Vixie" <[email-masked]>
To: "Ilari Liusvaara" <[email-masked]>
Cc: "Toerless Eckert" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 6/06/2021 6:07:30 am
Subject: Re: Port 80 deprecation

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 7 Jun 2021 13:25:26 +0900

I wonder if it isn't time to write a small RFC that lists the cases 
where encryption,... isn't appropriate. (Not that I have the expertise 
or the necessary cycles, sorry.)

Regards,   Martin.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 7 Jun 2021 07:27:32 +0200

On Mon, Jun 07, 2021 at 01:25:26PM +0900, Martin J. Dürst wrote:
> I wonder if it isn't time to write a small RFC that lists the cases where
> encryption,... isn't appropriate. (Not that I have the expertise or the
> necessary cycles, sorry.)

I'd avoid this. It can easily end up in a flame war because different
people have different opinions on the importance on accessbility,
confidentiality, integrity, tracing etc, and we can be sure that even
the most stupid examples will be defended to death to argument for or
against. Let's just leave it to common sense for as long as we can,
even if it results in a request for deprecation once in a while.

Just my two cents,
Willy

---

From: "Soni L." <[email-masked]>
Date: Mon, 7 Jun 2021 08:28:15 -0300

> CRL checks also have to use http.

Strictly speaking, they do not. You can, in fact, just skip those checks
when checking the certificates of those services. It's more accurate to
say OCSP is incompatible with OCSP, than to say HTTPS is incompatible
with OCSP.

---

From: Rafal Pietrak <[email-masked]>
Date: Mon, 7 Jun 2021 16:11:08 +0200

Hi Everyone,

This is not my field (and I apologise to cut in), but...

If not a list of "unnecessary" encryption, may be a list of "know
cases", where in "ordinary use", there is little to gain by encryption.

...since it is usually good know (explicitly) the state of the matter.

-R

-- 
Rafał Pietrak

---

From: Paul Vixie <[email-masked]>
Date: Mon, 7 Jun 2021 20:55:34 +0000

> ...since it is usually good know (explicitly) the state of the matter.

thank you for your wisdom. i fear that the decision of when to encrypt will
already have been taken, perhaps at birth or in university, and that advice
received later won't be heeded.

the internet was once a network of networks, and each network came into the
internet with total autonomy and self-sufficiency. gradually this model has
morphed, and the modern internet is quite viral. there is usually no way to
discover or reach internal resources without first consulting assets in the
internet "core" such as Root and TLD DNS servers, and CRL servers. while we
still have much RFC1918 addressing, we don't always have the corresponding
X.509 CA, private Root DNS zone, or keys and signatures for private DNSSEC.

in an age where the vast majority of developers and innovators have never
used a "disconnected" network in production, it's should not surprise us
when new technologies like TLS lack support for earlier norms. i'm not
going to make a private X.509 certificate, with or without a private CA,
to authenticate "localhost". nor for hypervisor-private network addresses
and their private names. and possibly not for campus-private or datacenter-
private network addresses and their private names. but, that may be just me.

snowden's disclosures in 2013 famously included evidence that google's edge
encryption model had been successfully attacked by the NSA using packet
snooping inside google's infrastructure. from this example one could argue
that there is no such thing as system-local, hypervisor-local, campus-local,
or datacenter-local traffic. given the constancy of broadening, where a
service that runs on localhost today runs across the public cloud tomorrow,
it's possible that an opportunistic-nonencryption mindset is dangerous.

for my part, the internet is too viral and we err grieviously by depending on
access to "the core" while trying to reach our own local resources. i'm not
going to encrypt traffic on my loopback network or similar local networks,
even if this requirement leads me towards or away from a solution or provider
for no other qualification reason than this one.

and that's why i agree with the previous author on this thread, who wrote:

> W dniu 07.06.2021 o??07:27, Willy Tarreau pisze:
> > On Mon, Jun 07, 2021 at 01:25:26PM +0900, Martin J. D??rst wrote:
> >> encryption,... isn't appropriate. [...]
> > 
> > people have different opinions on the importance on access[i]bility,

i don't want that flame war either. at most we can enumerate implications,
but stop well short of recommendations. reachability may connote trust of
some kinds in some situations, but since this is explicitly incompatible
with "zero trust", we would reach the limits of consensus very early on if
we tried to document the trade-off's.

-- 
Paul Vixie

---

From: Rafal Pietrak <[email-masked]>
Date: Tue, 8 Jun 2021 09:51:57 +0200

Sir,

> thank you for your wisdom. i fear that the decision of when to encrypt will

OK. I get it. ... and believe me, I was already ashamed, when I stroked
first chars of that response.

But pls let me explain myself before I fell silent. Just last words.

> received later won't be heeded.

[------------]

> private network addresses and their private names. but, that may be just me.

That may be more of us.

Still, we may be forced to.... in order to avoid explaining to our
bosses, why so many vulnerability alerts are there in our internal networks.

[-------------]

>> W dniu 07.06.2021 o??07:27, Willy Tarreau pisze:

[-----------]

> we tried to document the trade-off's.

Sorry to hear that, but OK. On the other hand I think that those flame
wars could be avoided.

then again:
1. a lot of people wouldn't encrypt local :80 traffic, for a lot of
reasons (a list here?), out of which one is the burdon of running
private/local SA.
2. still, some local traffic is "automagically" encrypted for us, like
encrypted SMB.

And this is the actual meaning of my ill advised initial response here:
if there are a lot of sensible reasons for leaving :80 as is (a list
would help), then may be there is a way to supplement HTTP (headers) for
some sort of "automagical" encryption? No "admin actions" (unlike CA),
just a configuration "yes/no" (similar to snakeoil certificate, but
"better/simpler")? I'd personally (as one of those who takes care of
localnets) would really appreciate it.

Now, I really don't want to bother you with things I should know, you
already know. So, I'm not following up here unless explicitly addressed.

Thank you and best regards.

-- 
Rafał Pietrak

---

From: [email-masked]
Date: Tue, 08 Jun 2021 20:19:12 +1200

>> received later won't be heeded.

IMO it depends on how the advice is presented.

The document suggested may be better phrased as the current known 
limitations *preventing* HTTPS use everywhere. Use-cases where TLS fails 
outright, or can lead to unwanted behaviours. That should get support 
from both sides of the debate towards writing it.

Amos