Internet DRAFT - draft-hartmann-default-port-for-irc-via-tls-ssl
draft-hartmann-default-port-for-irc-via-tls-ssl
Internet Draft Richard Hartmann
Independent Submission
Intended status: Informational
Expires: July 22, 2014
Updates: 1459
January 22, 2014
Default Port for IRC via TLS/SSL
draft-hartmann-default-port-for-irc-via-tls-ssl-10
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 January 22, 2014
Table of Contents
1. Rationale ..................................................... 3
2. Technical Details ............................................. 3
2.1. Connection Establishment ................................. 3
2.2. Certiticate Details ...................................... 3
2.2.1. Server Certificate .................................. 3
2.2.2. Client Certificate .................................. 3
3. Security Considerations ....................................... 4
4. IANA Considerations ........................................... 4
5. Informative References ........................................ 4
5. Normative References .......................................... 5
6. Acknowledgements .............................................. 5
Hartmann [Page 2]
Internet Draft Default Port for IRC via TLS/SSL January 22, 2014
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. Certiticate Details
2.2.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.2.2. Client Certificate
If the client is using a certificate as well, it should be issued by
Hartmann [Page 3]
Internet Draft Default Port for IRC via TLS/SSL January 22, 2014
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 proto-
cols are normally established in a bilateral agreement. All opera-
tors are encouraged to use strong encryption for back-end traffic, no
matter if they offer IRC via TLS/SSL to end users.
4. IANA Considerations
An assignment of TCP port 6697 for IRC via TLS/SSL will be requested.
The proposed keyword is "ircs-u" and the description "Internet Relay
Chat via TLS/SSL":
ircs-u 6697/tcp Internet Relay Chat via TLS/SSL
5. Informative References
[IANALIST] http://www.iana.org/assignments/port-numbers , Sep 15,
Hartmann [Page 4]
Internet Draft Default Port for IRC via TLS/SSL January 22, 2014
2010
[TOP100] http://irc.netsplit.de/networks/top100.php , Sep 15, 2010
[MAVERICK] http://irc.netsplit.de/networks/lists.php?query=maverick ,
Sep 27, 2010
[CERTFP] http://www.oftc.net/oftc/NickServ/CertFP , Mar 17 2011
5. Normative References
[RFC1459] J. Oikarinen, Internet Relay Chat Protocol
[RFC2810] C. Kalt, Internet Relay Chat: Architecture
[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
Hartmann [Page 5]
Internet Draft Default Port for IRC via TLS/SSL January 22, 2014
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 3232
04 - added section "Technical Details"
expanded section "Security Considerations"
Changed "Intended status" to "Experimental" at RFC authors'
suggestion
05 - Moved "Abstract" to the top of the document
Changed "Intended status" back to "Informational"
Added renaming suggestions for old assignments
Removed section "Comments"
Removed ".txt" from document name
Removed "Full Copyright Statement"
Other minor clean-ups
06 - Introduced unique port keys
07 - Extended document based on feedback by James Schaad and
Mykyta Yevstifeyev
08 - Removed naming updates to 6665-6669/TCP and 994/TCP (i.e. unique port keys)
at the request of Pearl Liang (IANA staff) and Nevil Brownlee (RFC Editor)
09 - New version as -08 is stuck in the submission queue
10 - Removed updates to RFCs 2812 and 2813, and to STARTTLS
Hartmann [Page 6]
