idnits 2.17.1 draft-hartmann-default-port-for-irc-via-tls-ssl-08.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: ---------------------------------------------------------------------------- No issues found here. 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. -- The draft header indicates that this document updates RFC2812, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1459, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1459, updated by this document, for RFC5378 checks: 1993-05-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2012) is 4287 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1700' is mentioned on line 231, 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 (~~), 2 warnings (==), 4 comments (--). 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: January 30, 2012 5 Updates: 1459, 2812, 2813 6 July 30, 2012 8 Default Port for IRC via TLS/SSL 9 draft-hartmann-default-port-for-irc-via-tls-ssl-08 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. Why Not STARTTLS ......................................... 3 52 2.3. Certiticate Details ...................................... 4 53 2.3.1. Server Certificate .................................. 4 54 2.3.2. Client Certificate .................................. 4 55 3. Security Considerations ....................................... 4 56 4. IANA Considerations ........................................... 5 57 5. Informative References ........................................ 5 58 5. Normative References .......................................... 5 59 6. Acknowledgements .............................................. 5 61 1. Rationale 63 Although system port assignments for both plain text (TCP/UDP port 64 194) and TLS/SSL [RFC5246] encrypted (TCP/UDP port 994) IRC traffic 65 exist [IANALIST], it is common practice amongst IRC networks not to 66 use them for reasons of convenience and general availability on sys- 67 tems where no root access is granted or desired. 69 IRC networks have defaulted to listening on TCP port 6667 for plain 70 text connections for considerable time, now. This is covered by the 71 IRCU assignment of TCP/UDP ports 6665-6669. 73 Similar consensus has been reached within the IRC community about 74 listening on TCP port 6697 for incoming IRC connections encrypted via 75 TLS/SSL. 77 2. Technical Details 79 2.1. Connection Establishment 81 An IRC client connects to an IRC server. Immediately after that, a 82 normal TLS/SSL handshake takes place. Once the TLS/SSL connection 83 has been established, a normal IRC connection is established via the 84 tunnel. Optionally, the IRC server may set a specific umode for the 85 client, marking it as using TLS/SSL. Again optionally, an IRC server 86 might offer the option to create channels in such a way that only 87 clients connected via TLS/SSL may join. 89 For details on how IRC works, see [RFC1459], [RFC2810], [RFC2811], 90 [RFC2812], [RFC2813]. Please note that IRC is extremely fragmented 91 and implementation details can vary wildly. Most implementations 92 regard the latter RFCs as suggestions, not as binding. 94 2.2. Why Not STARTTLS 96 Due to the highly asynchronous nature of IRC, everything other than 97 suspending the whole connection, running STARTTLS and resuming the 98 connection wouldn't work. As there is no concept of suspended con- 99 nections in IRC, this would require significant effort on the server 100 side and effort on the client side, as well. 102 The general consensus is that STARTTLS is not worth the effort and 103 that no one is willing to implement it. 105 While newer protocols can easily design for STARTTLS from the start, 106 IRC is a legacy protocol; implementing STARTTLS in IRC is not realis- 107 tic. 109 2.3. Certiticate Details 111 2.3.1. Server Certificate 113 The IRC server's certificate should be issued by a commonly trusted 114 CA. 116 The Common Name should match the FQDN of the IRC server or have 117 appropriate wildcards, if applicable. 119 The IRC client should verify the certificate. 121 2.3.2. Client Certificate 123 If the client is using a certificate as well, it should be issued by 124 a commonly trusted CA or a CA designated by the IRC network. 126 The certificate's Common Name should match the main IRC nickname. 128 If the network offers nick registration, this nick should be used. 130 If the network offers grouped nicks, the main nick or account name 131 should be used. 133 If the network offers nick registration, the client certificate 134 should be used to identify the user against the nick database. See 135 [CERTFP] for a possible implementation. 137 3. Security Considerations 139 The lack of a common, well established listening port for IRC via 140 TLS/SSL could lead to end users being unaware of their IRC network of 141 choice supporting TLS/SSL. Thus, they might not use encryption even 142 if they wanted to. 144 It should be noted that this document merely describes client-to- 145 server encryption. There are still other attack vectors like mali- 146 cious administrators, compromised servers, insecure server-to-server 147 communication, channels that do not enforce encryption for all chan- 148 nel members, malicious clients or comprised client machines on which 149 logs are stored. 151 Those attacks can by their very nature not be addressed by client-to- 152 server encryption. Additional safe-guards are needed if a user fears 153 any of the threats above. 155 This document does not address server links as there are no commonly 156 accepted ports or even back-end protocols. Ports and back-end 157 protocols are normally established in a bilateral agreement. All 158 operators are encouraged to use strong encryption for back-end traf- 159 fic, no matter if they offer IRC via TLS/SSL to end users. 161 4. IANA Considerations 163 An assignment of TCP port 6697 for IRC via TLS/SSL will be requested. 164 The proposed keyword is "ircs-u" and the description "Internet Relay 165 Chat via TLS/SSL": 167 ircs-u 6697/tcp Internet Relay Chat via TLS/SSL 169 5. Informative References 171 [IANALIST] http://www.iana.org/assignments/port-numbers , Sep 15, 172 2010 174 [TOP100] http://irc.netsplit.de/networks/top100.php , Sep 15, 2010 176 [MAVERICK] http://irc.netsplit.de/networks/lists.php?query=maverick , 177 Sep 27, 2010 179 [CERTFP] http://www.oftc.net/oftc/NickServ/CertFP , Mar 17 2011 181 5. Normative References 183 [RFC1459] J. Oikarinen, Internet Relay Chat Protocol 185 [RFC2810] C. Kalt, Internet Relay Chat: Architecture 187 [RFC2811] C. Kalt, Internet Relay Chat: Channel Management 189 [RFC2812] C. Kalt, Internet Relay Chat: Client Protocol 191 [RFC2813] C. Kalt, Internet Relay Chat: Server Protocol 193 [RFC5246] T. Dierks, E. Rescorla, The Transport Layer Security (TLS) 194 Protocol Version 1 196 6. Acknowledgements 198 Thanks go to the IRC community at large for reaching a consensus. 200 Special thanks go to the IRC operators who were eager to support port 201 6697 on their respective networks. 203 Special thanks also go to Nevil Brownlee and James Schaad for working 204 on this document in their capacities as RFC Editor and Reviewer, 205 respectively. 207 APPENDIX A: Supporting data 209 As of October 2010, out of the top twenty IRC networks 210 [TOP100],[MAVERICK], ten support TLS/SSL. Only one of those networks 211 does not support TLS/SSL via port 6697 and has no plans to support 212 it. All others supported it already or are supporting it since being 213 contacted by the author. A more detailed analysis is available but 214 does not fit within the scope of this document. 216 Authors' Address 218 Richard Hartmann 219 Munich 220 Germany 221 Email: richih.mailinglist@gmail.com 222 http://richardhartmann.de 224 Version History 226 00 - initial version 228 01 - fixed [MAVERICK] 230 02 - removed self-reference as RFC 231 added reference to [RFC1700] 233 03 - removed reference to RFC 1700 as per RFC 3232 235 04 - added section "Technical Details" 236 expanded section "Security Considerations" 237 Changed "Intended status" to "Experimental" at RFC authors' 238 suggestion 240 05 - Moved "Abstract" to the top of the document 241 Changed "Intended status" back to "Informational" 242 Added renaming suggestions for old assignments 243 Removed section "Comments" 244 Removed ".txt" from document name 245 Removed "Full Copyright Statement" 246 Other minor clean-ups 248 06 - Introduced unique port keys 250 07 - Extended document based on feedback by James Schaad and 251 Mykyta Yevstifeyev 253 08 - Removed naming updates to 6665-6669/TCP and 994/TCP (i.e. unique port keys) 254 at the request of Pearl Liang (IANA staff) and Nevil Brownlee (RFC Editor)