Internet Draft                                          Richard Hartmann
Independent Submission
Intended status: Informational
Expires: January 30, 2012
Updates: 1459, 2812, 2813
                                                           July 30, 2012

                    Default Port for IRC via TLS/SSL
           draft-hartmann-default-port-for-irc-via-tls-ssl-08

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       July 30, 2012


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 ..............................................  5





































Hartmann                                                        [Page 2]


Internet Draft      Default Port for IRC via TLS/SSL       July 30, 2012


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
   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       July 30, 2012


2.3. Certiticate Details

2.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       July 30, 2012


   protocols are normally established in a bilateral agreement.  All
   operators are encouraged to use strong encryption for back-end traf-
   fic, 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,
              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,



Hartmann                                                        [Page 5]


Internet Draft      Default Port for IRC via TLS/SSL       July 30, 2012


   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 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



Hartmann                                                        [Page 6]


Internet Draft      Default Port for IRC via TLS/SSL       July 30, 2012


   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)

















































Hartmann                                                        [Page 7]