search

ircv3 / ircv3-ideas

46 stars 3 forks source link

TLSMODES isupport token #46

Open slingamn opened 5 years ago

slingamn commented 5 years ago

Spinning this off from #45 because it seems to have enough traction on its own, and I don't want it to drown out the conversation about orthogonal initiatives.

Current state of the proposal: a new isupport token named TLSMODES, taking a value of the form a,b,c, where:

  1. If present, a is a user mode. If this mode is set, the server MUST NOT relay private messages between the affected user and any user who does not have TLS, in either direction.
  2. If present, b is a channel mode. If this mode is set, the server MUST NOT allow users who do not have TLS to join the channel.
  3. If present, c is a channel mode. If this mode is set, mode b MUST also be set, and moreover all users currently in the channel MUST be using TLS.

"TLS" is construed not to refer narrowly to the TLS protocol, but any case where the transport provides integrity and confidentiality, such as loopback, Tor, a VPN link, or a trusted LAN.

Example values: TLSMODES=Z,z,Z for Unreal, TLSMODES=z,z,z for Inspircd, TLSMODES=,S, for Freenode, and TLSMODES=z,z,z for Oragono (oragono/oragono#420).

slingamn commented 5 years ago

Another requirement that came out of discussion with RandomReader: if they publish this token, servers MUST be using TLS or something comparable on their server-to-server links.

realJoshByrnes commented 5 years ago

Are you suggesting that when b is set, then all insecure users leave the channel, that c is set?

b should only be able to be set when there are no insecure users in the room (whether that be by autokicking insecure users, or warning to the channel operator that it can not be set), which would make c irrelevant.

I think using wording like TLSMODES implies that all of those users are using TLS. It would be far better to use a term like SECUREMODES. As a bonus it would match the terminology used IRCv3 WebIRC extension.

We are trying to prove to a user that their data is secure, so I think Tor, a trusted LAN (trusted by who?) etc. should be considered insecure unless travelling over SSL/TLS (or their successors)

edk0 commented 5 years ago

We are trying to prove to a user that their data is secure, so I think Tor [...] should be considered insecure unless travelling over SSL/TLS (or their successors)

To what end?

realJoshByrnes commented 5 years ago

To what end?

Maybe I misunderstood. I took it to mean that a client is considered secure if connecting to the IRC Network over a trusted network (etc) using plaintext?

edk0 commented 5 years ago

Right, which in Tor's case is because connections to hidden services have network-level end-to-end encryption and one-sided authentication, the same properties TLS provides by default, and adding another layer of encryption between the same endpoints would not—on its own—increase security.

slingamn commented 5 years ago

a trusted LAN (trusted by who?)

Trusted by the server administrator, who in the end has access to all the data protected by TLS. If the LAN is approximately as secure as the TLS terminator or the underlying ircd, then there's no problem.

I'm split down the middle about calling this "SECUREMODES" or "SECMODES" rather than "TLSMODES". On the one hand, "TLSMODES" is clearly an abuse of terminology. On the other hand, "SECUREMODES" raises the question "secure how? secure from what?".