wdiff rfc7194.original rfc7194.txt

Internet Draft Richard Hartmann
Independent Submission
Intended status: Informational
Expires: July 22, R. Hartmann
Request for Comments: 7194 August 2014
Updates: 1459
January 22, 2014
Category: Informational
ISSN: 2070-1721

Default Port for IRC Internet Relay Chat (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 Internet Relay Chat (IRC) connections
encrypted via TLS/SSL.

Status of this This Memo

This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not a candidate for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list
Standard; see Section 2 of RFC 5741.

Information about the current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
http://www.rfc-editor.org/info/rfc7194.

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.

Table of Contents

1. Rationale ..................................................... 3 .......................................................2
2. Technical Details ............................................. 3 ...............................................2
2.1. Connection Establishment ................................. 3 ...................................2
2.2. Certiticate Certificate Details ...................................... 3 ........................................3
2.2.1. Server Certificate .................................. 3 ..................................3
2.2.2. Client Certificate .................................. 3 ..................................3
3. Security Considerations ....................................... 4 .........................................3
4. IANA Considerations ........................................... 4
5. Informative References ........................................ 4 .............................................4
5. Normative References .......................................... 5 ............................................4
6. Informative References ..........................................4
7. Acknowledgements .............................................. 5 ................................................5
Appendix A. Supporting Data ........................................6

1. Rationale

Although system port assignments exist for both IRC traffic that is plain
text (TCP/UDP port 194) and or 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 systems
where no root access is granted or desired.

IRC networks have defaulted to listening on TCP port 6667 for plain
text connections for a considerable time, 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.
TLS/SSL [RFC5246].

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 user mode
(umode) for the client, marking it as using TLS/SSL. Again 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], and [RFC2813]. Please note that IRC is extremely fragmented
fragmented, and implementation details can vary wildly. Most
implementations regard the latter RFCs as suggestions, not as
binding.

2.2. Certiticate Certificate Details

2.2.1. Server Certificate

The IRC server's certificate should be issued by a commonly trusted
CA.
certification authority (CA).

The Common Name should match the FQDN Fully Qualified Domain Name (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
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 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
malicious administrators, compromised servers, insecure server-to-server server-to-
server communication, channels that do not enforce encryption for all chan-
nel
channel members, malicious clients 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 safeguards 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
protocols are normally established in a bilateral agreement. All opera-
tors
operators 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. has been made.
The proposed keyword service name 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,
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 J. and D. Reed, "Internet Relay Chat Protocol Protocol",
RFC 1459, May 1993.

[RFC2810] C. Kalt, Internet C., "Internet Relay Chat: Architecture Architecture", RFC 2810,
April 2000.

[RFC2811] C. Kalt, Internet C., "Internet Relay Chat: Channel Management Management", RFC
2811, April 2000.

[RFC2812] C. Kalt, Internet C., "Internet Relay Chat: Client Protocol Protocol", RFC
2812, April 2000.

[RFC2813] C. Kalt, Internet C., "Internet Relay Chat: Server Protocol Protocol", RFC
2813, April 2000.

[RFC5246] T. Dierks, T. and E. Rescorla, The "The Transport Layer Security
(TLS) Protocol Version 1 1.2", RFC 5246, August 2008.

6. Informative References

[IANALIST] IANA, "Service Name and Transport Protocol Port Number
Registry", <http://www.iana.org/assignments/
service-names-port-numbers>.

[TOP100] netsplit.de, "IRC Networks - Top 100",
<http://irc.netsplit.de/networks/top100.php>.

[MAVERICK] netsplit.de, "IRC Networks - in alphabetical order",
<http://irc.netsplit.de/networks/
lists.php?query=maverick>.

[CERTFP] The Open and Free Technology Community, "OFTC -
NickServ/CertFP",
<http://www.oftc.net/oftc/NickServ/CertFP>.

7. 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 Independent Submissions
Editor and Reviewer, respectively.

APPENDIX A:

Appendix A. Supporting data Data

As of October 2010, out of the top twenty IRC networks
[TOP100],[MAVERICK], [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:

EMail: richih.mailinglist@gmail.com
URI: 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