[meebi]

CPU load is not the primary issue. SSL on IRC networks for client connections cannot assert that the communication is secure (for example, that all clients in a channel actually bothered to verify the SSL certificate properly). This issue will remain until client verification techniques such as DANE and DNSSEC are widely adopted on for IRC usage.

[ahf]

It's not true that this is up to the clients authors alone to do this work, and it's not fair for the users to tell them that you are awaiting client adoption of various technology, when the current Quakenet ircd implementation is currently incapable of even accepting SSL connections. Or at least it was, last time I checked.

Also, the DANE support in Irssi was announced in September last year and I have only heard of one network where some of its servers have adopted to this technology. Even though there is only one client that currently supports DANE+DNSSEC verification, we still need the (big) networks to start preparing for the support of it, and help us reaching the point where we can secure our user connections even better :-)

Having SSL on IRC, even without DANE+DNSSEC, is still better than having no SSL at all.

[pferde]

This is why I am disappointed that SILC[1] never got off the ground in the mainstream. It could have been an elegant successor to IRC.

1. http://silcnet.org

[jevinskie]

It still helps in the "coffee shop wifi" scenario. I'll take my defense in depth, thank you. =)