Default Port for IRC via TLS/SSL
draft-hartmann-default-port-for-irc-via-tls-ssl-07
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/SSL
draft-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, 2011
Table of Contents
1. Rationale ..................................................... 3
2. Technical Details ............................................. 3
2.1. Connection Establishment ................................. 3
2.2. Why Not STARTTLS ......................................... 3
2.3. Certiticate Details ...................................... 4
2.3.1. Server Certificate .................................. 4
2.3.2. Client Certificate .................................. 4
3. Security Considerations ....................................... 4
4. IANA Considerations ........................................... 5
5. Informative References ........................................ 5
5. Normative References .......................................... 5
6. Acknowledgements .............................................. 6
Hartmann [Page 2]
Internet Draft Default Port for IRC via TLS/SSL April 23, 2011
1. 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 Details
2.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
Show full document text