Why isn't encryption baked in by default? It's optional from what I can tell. I don't know how you can design a new protocol and not include encryption.
> The IRCv3 Working Group is a collection of IRC client and server software authors working to enhance, maintain and standardize the IRC protocol using backwards-compatible extensions.
Fair enough, but I feel you're being a little pedantic since there are base extensions described which are required, and optional extensions which are not required. TLS is one of the optional extensions.
So I'll reframe my question and ask: Why isn't TLS a base extension?
Hmm, I didn't see the 3.3 spec which is still being developed, it looks like they are doing strict transport security as a base extension. So that would address most of my concerns I think. I would still prefer to see TLS required no matter what.
The 'tls' extension is not actually TLS support. It is a method of upgrading plaintext connections to TLS via the STARTTLS command. It has some design problems and is going to be replaced with something that works similar to HTTP Strict Transport Security in the upcoming IRCv3.3 release which will be a base standard.
We strongly believe that the future of IRC is TLS-only.
There have been lots and lots and lots of discussions about that, but considering it’s just an extension to the existing IRC protocol, it’s not that easy.
But it’s easily possible to enforce SSL over IRC already.
I read IRC v3 and assumed they were making major changes to the wire by bumping the major version, which is why I said what I said. I've been using IRC for 24 years but haven't implemented it before, maybe I'll do that now so I can have a better idea of what I'm talking about.
I agree. Even if it's as simple as having a way to exchange public keys baked into the protocol and allowing cyphertext in messages. Even better would be if certain channels could have their own encryption key (exchanged securely between people allowed to join the channel, and changed if someone leaves/joins).
This is like the email situation where encryption options exist, but it's too hard for mere mortals to use. If it's built into the base protocol then there's a chance that clients would implement the standard and actually use it.
Indeed, but there is something to be said for sane defaults--look at the thread on HN a few weeks ago about SSH cipher defaults. Yes, TLS and the CA ecosystem has its faults, but my stance is that any chat protocol should be using auth and encryption, especially group chat protocols like IRC. I'm less upset now after seeing that the proposed spec for IRC 3.3 includes something similar to HSTS.
It's not a new protocol.