4 ms·

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.

mtgx 10y ago
Exactly what I wanted to say. Why even bother if encryption is not included by default in the new protocol?
- ChoHag 10y ago
  Encryption is not a panacea. It's not a magic button that makes everything it touches "Secure!".
  - nocarrier 10y ago
    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.
daenney 10y ago
> 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. It's not a new protocol.
- nocarrier 10y ago
  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?
  - nocarrier 10y ago
    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.
  - SaberUK 10y ago
    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.
kuschku 10y ago
> Why isn't encryption baked in by default? 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.
vardump 10y ago
> ...a new protocol and... IRC was new in 1988. It's 28 years old protocol now.
- nocarrier 10y ago
  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.
jandrese 10y ago
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.

mtgx 10y ago

Exactly what I wanted to say. Why even bother if encryption is not included by default in the new protocol?

ChoHag 10y ago
Encryption is not a panacea. It's not a magic button that makes everything it touches "Secure!".
- nocarrier 10y ago
  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.

daenney 10y ago

> 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. It's not a new protocol.

nocarrier 10y ago
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?
- nocarrier 10y ago
  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.
- SaberUK 10y ago
  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.

kuschku 10y ago

> Why isn't encryption baked in by default? 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.

vardump 10y ago

> ...a new protocol and... IRC was new in 1988. It's 28 years old protocol now.

nocarrier 10y ago
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.

jandrese 10y ago

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.