what bothers me about universal TLS is that it doesn't facilitate local
operations. when i speak to localhost, or to other endpoints on my
subnet, or indeed to other endpoints in my campus, i may not be using a
globally unique domain name. creating TLS certs for such names and
making sure there is a CA root trusted where it needs to be trusted is
intensely difficult -- and the design assumption by TLS-first protocol
developers is that i'll stop doing the thing that hurts so much and just
virally depend upon "the internet" for all my local operations. policy,
as well as part-time or dismal connectivity, may overrule this
assumption. especially for "localhost" which isn't unique even inside my
campus.
i understand how long running and egregious abuses by on-path actors
like ISPs and national security agencies led to these assumptions, but
the internet is a network of networks, and our protocols should still be
able to work on a network which is not completely or always connected to
the internet.
in a discussion with an open source SMTP library author i tried to
explain why i needed to speak to "localhost" in clear text, but i ended
up in a discussion of whether this could ever be secure against
eavesdropping, and i just didn't know where to take it from there.
the DNS industry long ago figured out how to support behind-the-NAT
operation with local root name servers and local root DNSSEC keys. i'd
like the QUIC community and every other TLS-first protocol teams to
realize that local operations in plain text are either (1) just fine, or
(2) at the discretion of the local operator.
as an example, QUIC could be a huge boon to near-scale file sharing
operations but not if it includes an X.509 penalty, or forbids
"localhost" as an endpoint, or if it needs a bounce buffer for memory
mapped sinks.
secure private edge network operators are not an enemy of freedom.
vixie