W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2021

Re: Port 80 deprecation

From: Paul Vixie <paul@redbarn.org>
Date: Mon, 7 Jun 2021 20:55:34 +0000
To: Rafal Pietrak <cookie.rp@ztk-rp.eu>
Cc: ietf-http-wg@w3.org
Message-ID: <20210607205534.pjmikarvtsjagjzq@family.redbarn.org>
On Mon, Jun 07, 2021 at 04:11:08PM +0200, Rafal Pietrak wrote:
> 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

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:
> >> I wonder if it isn't time to write a small RFC that lists the cases where
> >> encryption,... isn't appropriate. [...]
> > 
> > I'd avoid this. It can easily end up in a flame war because different
> > people have different opinions on the importance on access[i]bility,
> > 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.

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
Received on Monday, 7 June 2021 20:56:35 UTC

This archive was generated by hypermail 2.4.0 : Monday, 7 June 2021 20:57:19 UTC