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

Reply via email to