On Wed, May 26, 2010 at 6:25 PM, James Hess <mysidia@gmail.com> wrote:
It seems like a really a bad idea to introduce any new modes that /INVITE cannot override, as it introduces new poorly-understood methods that can be used by a channel hijacker/taker-overer.
What is the point of this +S mode, who would we expect to use it, how many users would actually want to use it immediately, and what would we expect to accomplish with it?
Can you guarantee that all IRC servers perform SSL/TLS encryption of all traffic between servers, and no non-SSL-connected IRC server is capable of JOINing a user to the channel or effecting it in any manner so as to alter settings or receive traffic from the channel?
Can you guarantee a user hasn't telnetted into a server and run an IRC client from it?
It seems like end-to-end encryption is a guarantee we can never make even at an IRC protocol level (without considering the multitude of ways a session can seem to be encrypted but be totally insecure), so trying to imply "mode +S" should make an assertion like that, is like IRCD trying to make a false promise....
IRC over SSL is rather pointless for most use cases. It's real benefits are few and far between. As you pointed out, the ircd simply cannot guarantee all traffic is encrypted and thus "secure." A lot of assumptions have to be made, for example, a.) servers are never compromised and do not log anything, b.) the server has a valid certificate with fingerprint located somewhere out of band where people can verify its authenticity, c.) servers ONLY support encrypted connections, period, d.) clients are never compromised and don't log anything (e.g., MITM attacks), etc. An easy example of IRC over SSL being "broken", most web irc clients allow SSL connections to IRC servers over HTTP. The ircd has no idea traffic is really going over unencrypted HTTP and thus would allow you to join an SSL-only channel. BNCs are another example. It's a false sense of security for most, which some would argue is worse than not having SSL at all.