Internet Draft Richard Hartmann
Independent Submission
Intended status: Informational
Expires: October 23, 2011
Updates: 1459, 2812, 2813
April 23, 2011
Default Port for IRC via TLS/SSLdraft-hartmann-default-port-for-irc-via-tls-ssl-07
Abstract
This document describes the commonly accepted practice of listening
on TCP port 6697 for incoming IRC connections encrypted via TLS/SSL.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hartmann [Page 1]

Internet Draft Default Port for IRC via TLS/SSL April 23, 20111. Rationale
Although system port assignments for both plain text (TCP/UDP port
194) and TLS/SSL [RFC5246] encrypted (TCP/UDP port 994) IRC traffic
exist [IANALIST], it is common practice amongst IRC networks not to
use them for reasons of convenience and general availability on sys-
tems where no root access is granted or desired.
IRC networks have defaulted to listening on TCP port 6667 for plain
text connections for considerable time, now. This is covered by the
IRCU assignment of TCP/UDP ports 6665-6669.
Similar consensus has been reached within the IRC community about
listening on TCP port 6697 for incoming IRC connections encrypted via
TLS/SSL.
2. Technical Details2.1. Connection Establishment
An IRC client connects to an IRC server. Immediately after that, a
normal TLS/SSL handshake takes place. Once the TLS/SSL connection
has been established, a normal IRC connection is established via the
tunnel. Optionally, the IRC server may set a specific umode for the
client, marking it as using TLS/SSL. Again optionally, an IRC server
might offer the option to create channels in such a way that only
clients connected via TLS/SSL may join.
For details on how IRC works, see [RFC1459], [RFC2810], [RFC2811],
[RFC2812], [RFC2813]. Please note that IRC is extremely fragmented
and implementation details can vary wildly. Most implementations
regard the latter RFCs as suggestions, not as binding.
2.2. Why Not STARTTLS
Due to the highly asynchronous nature of IRC, everything other than
suspending the whole connection, running STARTTLS and resuming the
connection wouldn't work. As there is no concept of suspended con-
nections in IRC, this would require significant effort on the server
side and effort on the client side, as well.
The general consensus is that STARTTLS is not worth the effort and
that no one is willing to implement it.
While newer protocols can easily design for STARTTLS from the start,
IRC is a legacy protocol; implementing STARTTLS in IRC is not realis-
tic.
Hartmann [Page 3]

Internet Draft Default Port for IRC via TLS/SSL April 23, 20112.3. Certiticate Details2.3.1. Server Certificate
The IRC server's certificate should be issued by a commonly trusted
CA.
The Common Name should match the FQDN of the IRC server or have
appropriate wildcards, if applicable.
The IRC client should verify the certificate.
2.3.2. Client Certificate
If the client is using a certificate as well, it should be issued by
a commonly trusted CA or a CA designated by the IRC network.
The certificate's Common Name should match the main IRC nickname.
If the network offers nick registration, this nick should be used.
If the network offers grouped nicks, the main nick or account name
should be used.
If the network offers nick registration, the client certificate
should be used to identify the user against the nick database. See
[CERTFP] for a possible implementation.
3. Security Considerations
The lack of a common, well established listening port for IRC via
TLS/SSL could lead to end users being unaware of their IRC network of
choice supporting TLS/SSL. Thus, they might not use encryption even
if they wanted to.
It should be noted that this document merely describes client-to-
server encryption. There are still other attack vectors like mali-
cious administrators, compromised servers, insecure server-to-server
communication, channels that do not enforce encryption for all chan-
nel members, malicious clients or comprised client machines on which
logs are stored.
Those attacks can by their very nature not be addressed by client-to-
server encryption. Additional safe-guards are needed if a user fears
any of the threats above.
This document does not address server links as there are no commonly
accepted ports or even back-end protocols. Ports and back-end
Hartmann [Page 4]

Internet Draft Default Port for IRC via TLS/SSL April 23, 2011
[RFC2811] C. Kalt, Internet Relay Chat: Channel Management
[RFC2812] C. Kalt, Internet Relay Chat: Client Protocol
[RFC2813] C. Kalt, Internet Relay Chat: Server Protocol
[RFC5246] T. Dierks, E. Rescorla, The Transport Layer Security (TLS)
Protocol Version 1
6. Acknowledgements
Thanks go to the IRC community at large for reaching a consensus.
Special thanks go to the IRC operators who were eager to support port
6697 on their respective networks.
Special thanks also go to Nevil Brownlee and James Schaad for working
on this document in their capacities as RFC Editor and Reviewer,
respectively.
APPENDIX A: Supporting data
As of October 2010, out of the top twenty IRC networks
[TOP100],[MAVERICK], ten support TLS/SSL. Only one of those networks
does not support TLS/SSL via port 6697 and has no plans to support
it. All others supported it already or are supporting it since being
contacted by the author. A more detailed analysis is available but
does not fit within the scope of this document.
Authors' Address
Richard Hartmann
Munich
Germany
Email: richih.mailinglist@gmail.com
http://richardhartmann.de
Version History
00 - initial version
01 - fixed [MAVERICK]
02 - removed self-reference as RFC
added reference to [RFC1700]
03 - removed reference to RFC 1700 as per RFC 3232Hartmann [Page 6]