idnits 2.17.1 draft-hartmann-default-port-for-irc-via-tls-ssl-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-hartmann-default-port-for-irc-via-tls-ssl-10', but the file name used is 'draft-hartmann-default-port-for-irc-via-tls-ssl-09' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2014) is 3747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1700' is mentioned on line 215, but not defined ** Obsolete undefined reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Richard Hartmann 2 Independent Submission 3 Intended status: Informational 4 Expires: July 22, 2014 5 Updates: 1459 6 January 22, 2014 8 Default Port for IRC via TLS/SSL 9 draft-hartmann-default-port-for-irc-via-tls-ssl-10 11 Abstract 13 This document describes the commonly accepted practice of listening 14 on TCP port 6697 for incoming IRC connections encrypted via TLS/SSL. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute working 23 documents as Internet-Drafts. The list of current Internet-Drafts is 24 at http://datatracker.ietf.org/drafts/current. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 Copyright Notice 33 Copyright (c) 2010 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Rationale ..................................................... 3 49 2. Technical Details ............................................. 3 50 2.1. Connection Establishment ................................. 3 51 2.2. Certiticate Details ...................................... 3 52 2.2.1. Server Certificate .................................. 3 53 2.2.2. Client Certificate .................................. 3 54 3. Security Considerations ....................................... 4 55 4. IANA Considerations ........................................... 4 56 5. Informative References ........................................ 4 57 5. Normative References .......................................... 5 58 6. Acknowledgements .............................................. 5 60 1. Rationale 62 Although system port assignments for both plain text (TCP/UDP port 63 194) and TLS/SSL [RFC5246] encrypted (TCP/UDP port 994) IRC traffic 64 exist [IANALIST], it is common practice amongst IRC networks not to 65 use them for reasons of convenience and general availability on sys- 66 tems where no root access is granted or desired. 68 IRC networks have defaulted to listening on TCP port 6667 for plain 69 text connections for considerable time, now. This is covered by the 70 IRCU assignment of TCP/UDP ports 6665-6669. 72 Similar consensus has been reached within the IRC community about 73 listening on TCP port 6697 for incoming IRC connections encrypted via 74 TLS/SSL. 76 2. Technical Details 78 2.1. Connection Establishment 80 An IRC client connects to an IRC server. Immediately after that, a 81 normal TLS/SSL handshake takes place. Once the TLS/SSL connection 82 has been established, a normal IRC connection is established via the 83 tunnel. Optionally, the IRC server may set a specific umode for the 84 client, marking it as using TLS/SSL. Again optionally, an IRC server 85 might offer the option to create channels in such a way that only 86 clients connected via TLS/SSL may join. 88 For details on how IRC works, see [RFC1459], [RFC2810], [RFC2811], 89 [RFC2812], [RFC2813]. Please note that IRC is extremely fragmented 90 and implementation details can vary wildly. Most implementations 91 regard the latter RFCs as suggestions, not as binding. 93 2.2. Certiticate Details 95 2.2.1. Server Certificate 97 The IRC server's certificate should be issued by a commonly trusted 98 CA. 100 The Common Name should match the FQDN of the IRC server or have 101 appropriate wildcards, if applicable. 103 The IRC client should verify the certificate. 105 2.2.2. Client Certificate 107 If the client is using a certificate as well, it should be issued by 108 a commonly trusted CA or a CA designated by the IRC network. 110 The certificate's Common Name should match the main IRC nickname. 112 If the network offers nick registration, this nick should be used. 114 If the network offers grouped nicks, the main nick or account name 115 should be used. 117 If the network offers nick registration, the client certificate 118 should be used to identify the user against the nick database. See 119 [CERTFP] for a possible implementation. 121 3. Security Considerations 123 The lack of a common, well established listening port for IRC via 124 TLS/SSL could lead to end users being unaware of their IRC network of 125 choice supporting TLS/SSL. Thus, they might not use encryption even 126 if they wanted to. 128 It should be noted that this document merely describes client-to- 129 server encryption. There are still other attack vectors like mali- 130 cious administrators, compromised servers, insecure server-to-server 131 communication, channels that do not enforce encryption for all chan- 132 nel members, malicious clients or comprised client machines on which 133 logs are stored. 135 Those attacks can by their very nature not be addressed by client-to- 136 server encryption. Additional safe-guards are needed if a user fears 137 any of the threats above. 139 This document does not address server links as there are no commonly 140 accepted ports or even back-end protocols. Ports and back-end proto- 141 cols are normally established in a bilateral agreement. All opera- 142 tors are encouraged to use strong encryption for back-end traffic, no 143 matter if they offer IRC via TLS/SSL to end users. 145 4. IANA Considerations 147 An assignment of TCP port 6697 for IRC via TLS/SSL will be requested. 148 The proposed keyword is "ircs-u" and the description "Internet Relay 149 Chat via TLS/SSL": 151 ircs-u 6697/tcp Internet Relay Chat via TLS/SSL 153 5. Informative References 155 [IANALIST] http://www.iana.org/assignments/port-numbers , Sep 15, 156 2010 158 [TOP100] http://irc.netsplit.de/networks/top100.php , Sep 15, 2010 160 [MAVERICK] http://irc.netsplit.de/networks/lists.php?query=maverick , 161 Sep 27, 2010 163 [CERTFP] http://www.oftc.net/oftc/NickServ/CertFP , Mar 17 2011 165 5. Normative References 167 [RFC1459] J. Oikarinen, Internet Relay Chat Protocol 169 [RFC2810] C. Kalt, Internet Relay Chat: Architecture 171 [RFC2811] C. Kalt, Internet Relay Chat: Channel Management 173 [RFC2812] C. Kalt, Internet Relay Chat: Client Protocol 175 [RFC2813] C. Kalt, Internet Relay Chat: Server Protocol 177 [RFC5246] T. Dierks, E. Rescorla, The Transport Layer Security (TLS) 178 Protocol Version 1 180 6. Acknowledgements 182 Thanks go to the IRC community at large for reaching a consensus. 184 Special thanks go to the IRC operators who were eager to support port 185 6697 on their respective networks. 187 Special thanks also go to Nevil Brownlee and James Schaad for working 188 on this document in their capacities as RFC Editor and Reviewer, 189 respectively. 191 APPENDIX A: Supporting data 193 As of October 2010, out of the top twenty IRC networks 194 [TOP100],[MAVERICK], ten support TLS/SSL. Only one of those networks 195 does not support TLS/SSL via port 6697 and has no plans to support 196 it. All others supported it already or are supporting it since being 197 contacted by the author. A more detailed analysis is available but 198 does not fit within the scope of this document. 200 Authors' Address 202 Richard Hartmann 203 Munich 204 Germany 205 Email: richih.mailinglist@gmail.com 206 http://richardhartmann.de 208 Version History 210 00 - initial version 212 01 - fixed [MAVERICK] 214 02 - removed self-reference as RFC 215 added reference to [RFC1700] 217 03 - removed reference to RFC 1700 as per RFC 3232 219 04 - added section "Technical Details" 220 expanded section "Security Considerations" 221 Changed "Intended status" to "Experimental" at RFC authors' 222 suggestion 224 05 - Moved "Abstract" to the top of the document 225 Changed "Intended status" back to "Informational" 226 Added renaming suggestions for old assignments 227 Removed section "Comments" 228 Removed ".txt" from document name 229 Removed "Full Copyright Statement" 230 Other minor clean-ups 232 06 - Introduced unique port keys 234 07 - Extended document based on feedback by James Schaad and 235 Mykyta Yevstifeyev 237 08 - Removed naming updates to 6665-6669/TCP and 994/TCP (i.e. unique port keys) 238 at the request of Pearl Liang (IANA staff) and Nevil Brownlee (RFC Editor) 240 09 - New version as -08 is stuck in the submission queue 242 10 - Removed updates to RFCs 2812 and 2813, and to STARTTLS