There's a trend I've noticed in the past few years. It's tempting when designing new protocols and software (for example, Gemini or Mastodon) to *require* the use of TLS. Privacy is important, and making it non-negotiable in the protocol design is becoming more commonplace.
But TLS is far from perfect. It allows the global certificate authority cabal subvert your privacy, is burdensome over localhost and some LANs, and many overlay networks (Tor, yggdrasil, cjdns) have end-to-end encryption at layer 3, making TLS redundant. Alternative domain name systems also have problems with mandatory TLS.
Perhaps the compromise position is to require that all connections carry *some* level of privacy guarantees. Forcing TLS is a bad idea if you ask me.
I think the Official Recommendation I would make to protocol designers is the following:
In the SECURITY CONSIDERATIONS section of your RFC, add the following text:
All $protocol connections over a public or shared network MUST utilize a form of end-to-end encryption, such as TLS. User agents SHOULD display a visible warning to the user if the connection is not end-to-end encrypted.
I say "SHOULD" here for the user agent because sometimes it's out of scope for it to do the due diligience here, for example with yggdrasil or .onion addresses.
@sir Clarification: while Gemini does require TLS, it’s not reliant on the CA system. Clients are free to use whichever form of verification they deem appropriate, with TOFU being the suggested approach.
@sir Of course they're not. That's for old boring people. The new hip kids just write a shitty node.js implementation that just everybody should run to 'save the internet'...
@sir TLS is not always end-to-end though. Depending on protocol, the server you're intending to connect to may not be considered an "end". Eg. for ActivityPub it isn't.
@wolf480pl hm, good point. Something to think about more
@sir It'd be nice to have a generic term for what TLS does. "client-to-server" encryption maybe?
"All FFP connections over a public or shared network MUST utilize some form of transport encryption"
and then someone reads it and thinks "TLS is ok, onion... well it operates on transport layer so that's ok as well.... cjdns? well it encrypts stuff in network layer, that's no good, need TLS on top of that"
@wolf480pl right, but im presuming we can at least knock out worries like "Does end to end encryption work in our model?", unlike earlier where we had to word our way around how TLS might be e2e in some places and not others.
@kline yeah, I guess
@sir why focus on protocol encryption instead of content encryption? would not having protocol encryption be more backwards-compatible, allowing more content-agnosticism? looking at ipfs and requests for encryption in that protocol, it seems to result in removal of its ability to deduplicate. how would gemini fare?
@sir how about only requiring TLS for connections over the public Internet?
Though both this and requirement of "some level of privacy" would be hard to implement in a client. It'd require the client to be aware if any layer 3 encryption schemes are in place.
@wolf480pl I wouldn't even go so far as to say "the public Internet". I would stick with what I said: "public or shared networks"
@sir yeah I only later noticed that other post of yours
@wolf480pl also, you can burden the system operator with fulfilling this promise of the RFC, it doesn't have to be the implementation
I've had to go to great pains to work around mandatory TLS when the network is already behind a reverse-proxy that terminates TLS.
Like, I'm already inside my own isolated network, and in some-cases (service meshes) I'm already inside the instance/container/vm that the server is running on.
But noooo, TLS between NGINX and The Server _on the same node_ is required for "privacy" and "security" reasons.
I think making it the default is okay, but making mandatory is just condescending.
@sir agreed fully. Configuring TLS correctly is way to hard (which version, what suites, are Pins overruled by your system certs, etc.).
At least these days you can pick something like the Noise framework and pick your desired flavor (mutual auth, etc) if you cant go for a full overlay.
@sir If I remember correctly, activitypub is just an API protocol like REST and GraphQL as opposed to a transfer protocol like HTTP.
having TLS on HTTP is just a "band-aid" for an underlying issue that HTTP isn't encrypted by itself.
Many overlay networks have encryption yes, but this comes with it's own issues.
Like you can use HTTP over CjDNS just fine but what if that service also is available over the clearnet? Are you gonna make your server not serve TLS just on CjDNS?
>having TLS on HTTP is just a "band-aid" for an underlying issue that HTTP isn't encrypted by itself.
This doesn't make any sense, TLS is used industry-wide to add privacy to otherwise plaintext protocols and is a much better option than rolling your own encryption for whatever thing you just built
>Are you gonna make your server not serve TLS just on CjDNS?
Yes, and it's not even difficult
> TLS is used industry-wide to add privacy to otherwise plaintext protocols.
Yes, so isn't that a "band-aid" for fixing the underlying issue of not having encryption in the protocol itself?
> is a much better option than rolling your own encryption for whatever thing you just built
So you're complaining about it at first but then say it's better than spinning your own?
> Yes, and it's not even difficult
It's not no, but it's pointless extra hassle.
@finlaydag33k no, it's not a band-aid, it's working by design.
>So you're complaining about it at first but then say it's better than spinning your own?
No, I'm saying that how the connection is encrypted is none of the application-level protocol's business. They shouldn't roll their own OR use TLS.
>no, it's not a band-aid, it's working by design.
it's a band-aid to a certain degree... they noticed issues with HTTP being plaintext then slapped a wrapper around it using TLS.
That's a band-aid.
> They shouldn't roll their own OR use TLS.
So first you're saying Forcing TLS is a bad idea... and then you're saying people shouldn't roll their own but also that they shouldn't use TLS...
How the hell do you want it to be? not rolling their own or not using TLS?
@finlaydag33k I'm talking about PROTOCOLS. The PROTOCOLS should not use TLS. The IMPLEMENTATIONS very well might want to use TLS. The point is that TLS is not a universally correct solution.
@sir So then ehm... If you say protocols shouldn't use TLS... there where the hell do you want to implement them?
(I do agree that TLS is not a universally correct solution though)
@finlaydag33k do you understand the difference between a protocol and its implementation?
@sir Yes, I do.
You don't want protocols to use TLS but you do allow their implementations to do so.
I think you're the one that doesn't know the difference between a protocol and it's implementation.
as well as an understanding of the word "protocol" to begin with.
(no offenses given ofc)
@finlaydag33k and I think you're a fucking moron, no offenses given ofc
@sir Ah yes, the all famous "and I think you're a moron for me not understanding what I am even saying myself"...
Seriously, you do not want protocols to tinker with encryption... but then the implementation of said protocols may?
Imagine how that'd look like if 1 HTTP site used TLS, the other used double-ratched, another one used GPG, another one used HacksMahFiddleDeeDee...
Yea ehm... that's just asking for trouble...
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!