idnits 2.17.1 draft-elie-nntp-tls-recommendations-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4642, updated by this document, for RFC5378 checks: 2003-02-28) -- 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 (August 5, 2016) is 2819 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission J. Elie 3 Internet-Draft August 5, 2016 4 Updates: 4642 (if approved) 5 Intended status: Standards Track 6 Expires: February 6, 2017 8 Use of Transport Layer Security (TLS) 9 in the Network News Transfer Protocol (NNTP) 10 draft-elie-nntp-tls-recommendations-01 12 Abstract 14 This document provides recommendations for improving the security of 15 the Network News Transfer Protocol (NNTP) when using Transport Layer 16 Security (TLS). It modernizes the NNTP usage of TLS to be consistent 17 with TLS best current practices. If approved, this document updates 18 RFC 4642. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 6, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 56 1.2. Author's Note . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Protocol Versions and Cipher Suites . . . . . . . . . . . 4 60 2.3. Authenticated Connections . . . . . . . . . . . . . . . . 4 61 2.4. Human Factors . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 5.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Appendix A. Changes to RFC 4642 . . . . . . . . . . . . . . . . 9 68 Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 9 69 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 10 70 Appendix D. Document History (to be removed by RFC Editor before 71 publication) . . . . . . . . . . . . . . . . . . . . 10 72 D.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 10 73 Appendix E. Issues to Address . . . . . . . . . . . . . . . . . 10 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 The Network News Transfer Protocol (NNTP) [RFC3977] has been using 79 Transport Layer Security (TLS) [RFC5246] (along with its precursor, 80 Secure Sockets Layer or SSL) since at least year 2000. The use of 81 TLS in NNTP was formalized in [RFC4642], providing at the same time 82 implementation recommendations. In order to address the evolving 83 threat model on the Internet today, this document provides stronger 84 recommendations regarding that use. 86 In particular, this document updates [RFC4642] by specifying that 87 NNTP implementations and deployments MUST follow the best current 88 practices documented in the "Recommendations for Secure Use of TLS 89 and DTLS" [RFC7525]. This includes stronger recommendations 90 regarding SSL/TLS protocol versions, fallback to lower versions, 91 strict TLS, TLS-level compression, TLS session resumption, cipher 92 suites, public key lengths, forward secrecy, and other aspects of 93 using TLS with NNTP. 95 Notably, this document updates [RFC4642] in the following aspects: 97 o NNTP implementations and deployments SHOULD disable TLS-level 98 compression (Section 3.3 of [RFC7525]), thus no longer using TLS 99 as a means to provide data compression (contrary to Abstract and 100 Section 2.2.2 of [RFC4642]). 102 o NNTP implementations and deployments SHOULD prefer strict TLS 103 configuration (Section 3.2 of [RFC7525]), that is to say they 104 SHOULD use TCP port 563 dedicated to NNTP over TLS, and begin the 105 TLS negotiation immediately upon connection (contrary to a dynamic 106 upgrade from unencrypted to TLS-protected traffic via the use of 107 the STARTTLS command, as Section 1 of [RFC4642] was encouraging). 108 For the same reasons as those given in Appendix A of [MUA-STS] 109 transposed to NNTP, strict TLS is the preferred way of using TLS 110 with NNTP. 112 o NNTP implementations and deployments MUST NOT negotiate RC4 cipher 113 suites ([RFC7465]) contrary to Section 5 of [RFC4642] that 114 REQUIRED them to implement the TLS_RSA_WITH_RC4_128_MD5 cipher 115 suite so as to ensure that any two NNTP compliant implementations 116 can be configured to interoperate. This document removes that 117 requirement, so that NNTP client and server implementations follow 118 the recommendations of Section 4.2.1 of [RFC7525] instead. 120 1.1. Conventions Used in This Document 122 Any term not defined in this document has the same meaning as it does 123 in [RFC4642] or the NNTP core specification [RFC3977]. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in 128 [RFC2119]. 130 1.2. Author's Note 132 Please write the first letter of "Elie" and the penultimate letter of 133 "allee" with an acute accent wherever possible -- they are 134 respectively U+00C9 ("É" in XML) and U+00E9 ("é" in XML). 135 Also, the letters "ae" in "Baeuerle" should be written as an a-umlaut 136 (U+00E4, "ä" in XML). 138 2. Recommendations 140 The best current practices documented in the "Recommendations for 141 Secure Use of TLS and DTLS" [RFC7525] are included here by reference. 142 Therefore, NNTP implementations and deployments compliant with this 143 document is REQUIRED to also comply with [RFC7525]. 145 Instead of repeating those recommendations here, this document mostly 146 provides supplementary information regarding secure implementation 147 and deployment of NNTP technologies. 149 2.1. Compression 151 NNTP supports the use of the COMPRESS command, defined in Section 2.2 152 of [NNTP-COMPRESS], to compress data between an NNTP client and 153 server. Although this NNTP extension might have slightly stronger 154 security properties than TLS-level compression [RFC3749] (since NNTP 155 compression can be activated after authentication has completed, thus 156 reducing the chances that authentication credentials can be leaked 157 via for instance a CRIME attack, as described in Section 2.6 of 158 [CRIME]), this document neither encourages nor discourages use of 159 NNTP COMPRESS extension. 161 2.2. Protocol Versions and Cipher Suites 163 NNTP implementations of news servers are encouraged to support 164 options to configure the minimal TLS protocol version to accept, and 165 which cipher suites, signature algorithms or named groups (like 166 elliptic curves) to use for incoming connections. Additional options 167 can naturally also be supported. The goal is to enable 168 administrators of news servers to easily and quickly strengthen 169 security, if need be (for instance by rejecting cipher suites 170 considered unsafe with regards to local policy). News clients may 171 also support similar options, either configurable by the user or 172 enforced by the news reader. 174 2.3. Authenticated Connections 176 [RFC4642] already provides recommendations and requirements for 177 certificate validation in the context of checking the client or the 178 server's identity. 180 Wherever possible, it is best to prefer certificate-based 181 authentication (along with SASL [RFC4422]), and ensure that: 183 o Clients authenticate servers. 185 o Servers authenticate clients. 187 o Servers authenticate other peer servers. 189 This document does not mandate certificate-based authentication, 190 although such authentication is strongly preferred. As mentioned in 191 Section 2.2.2 of [RFC4642], the AUTHINFO SASL command (Section 2.4 of 192 [RFC4643]) with the EXTERNAL mechanism (Appendix A of [RFC4422]) MAY 193 be used to authenticate a client once its TLS credentials have been 194 successfully exchanged. 196 Given the pervasiveness of eavesdropping [RFC7258], even an encrypted 197 but unauthenticated connection might be better than an unencrypted 198 connection (this is similar to the "better-than-nothing security" 199 approach for IPsec [RFC5386]). Encrypted but unauthenticated 200 connections include connections negotiated using anonymous 201 Diffie-Hellman mechanisms or using self-signed certificates, among 202 others. 204 When an NNTP server receives a Netnews article, it MAY add a 205 (Section 3.1.5 of [RFC5536]), which appears as "!!" in 206 the Path header field of that article, to indicate that it verified 207 the identity of the client or peer server. This document encourages 208 the construction of such Path header fields, as described in 209 Section 3.2.1 of [RFC5537]. 211 2.4. Human Factors 213 It is strongly encouraged that NNTP clients provide ways for end 214 users (and that NNTP servers provide ways for administrators) to 215 complete the following tasks: 217 o Determine if a given incoming or outgoing connection is encrypted 218 using a security layer (either using TLS or an SASL mechanism that 219 negotiates a security layer). 221 o Determine the version of TLS used for encryption of a given 222 stream. 224 o If authenticated encryption is used, determine how the connection 225 was authenticated or verified. 227 o Inspect the certificate offered by an NNTP server. 229 o Determine the cipher suite used to encrypt a connection. 231 o Be warned if the certificate changes for a given server. 233 o Be warned if a given server stops advertising the STARTTLS 234 capability label in response to the CAPABILITIES command (of 235 course when a security layer is not already in place) whereas it 236 advertised the STARTTLS capability label during the previous 237 connection. 239 o Be warned if a failure response to the STARTTLS command is 240 received from the server whereas the STARTTLS capability label was 241 advertised. 243 Note that the last two tasks cannot occur when strict TLS is used. 245 3. Security Considerations 247 Beyond the security considerations already described in [RFC4642] and 248 [RFC7525], the author wishes to add the following caveat when not 249 using strict TLS. 251 NNTP servers need ensure that they are not vulnerable to the STARTTLS 252 command injection vulnerability (CERT vulnerability ID #555316). 253 Though this command MUST NOT be pipelined, an attacker could pipeline 254 it. Therefore, NNTP servers MUST discard any NNTP command received 255 between the use of STARTTLS and the end of TLS negotiation. 257 4. IANA Considerations 259 This document has no actions for IANA. 261 5. References 263 5.1. Normative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, 267 DOI 10.17487/RFC2119, March 1997, 268 . 270 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", 271 RFC 3977, DOI 10.17487/RFC3977, October 2006, 272 . 274 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 275 Transport Layer Security (TLS) with Network News Transfer 276 Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 277 2006, . 279 5.2. Informative References 281 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty 282 Security Conference, 2012. 284 [MUA-STS] Moore, K. and C. Newman, "Mail User Agent Strict Transport 285 Security (MUA-STS)", July 2016. 287 [NNTP-COMPRESS] 288 Murchison, K. and J. Elie, "Network News Transfer Protocol 289 (NNTP) Extension for Compression", June 2016. 291 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 292 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 293 2004, . 295 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 296 Authentication and Security Layer (SASL)", RFC 4422, 297 DOI 10.17487/RFC4422, June 2006, 298 . 300 [RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer 301 Protocol (NNTP) Extension for Authentication", RFC 4643, 302 DOI 10.17487/RFC4643, October 2006, 303 . 305 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 306 (TLS) Protocol Version 1.2", RFC 5246, 307 DOI 10.17487/RFC5246, August 2008, 308 . 310 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 311 Security: An Unauthenticated Mode of IPsec", RFC 5386, 312 DOI 10.17487/RFC5386, November 2008, 313 . 315 [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 316 Article Format", RFC 5536, DOI 10.17487/RFC5536, November 317 2009, . 319 [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and 320 Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, 321 . 323 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 324 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 325 2014, . 327 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 328 DOI 10.17487/RFC7465, February 2015, 329 . 331 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 332 "Recommendations for Secure Use of Transport Layer 333 Security (TLS) and Datagram Transport Layer Security 334 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 335 2015, . 337 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 338 Security (TLS) in the Extensible Messaging and Presence 339 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 340 2015, . 342 Appendix A. Changes to RFC 4642 344 This section lists detailed changes this document applies to 345 [RFC4642]. 347 The second sentence in the Abstract of [RFC4642] is replaced with the 348 following text: 350 The primary goal is to provide encryption for single-link 351 confidentiality purposes, but data integrity, and (optional) 352 certificate-based peer entity authentication are also possible. 354 The third and fourth paragraphs in Section 1 of [RFC4642] are 355 replaced with the following text: 357 TCP port 563 is dedicated to NNTP over TLS, and registered in the 358 IANA Service Name and Transport Protocol Port Number Registry for 359 that usage. NNTP implementations using TCP port 563 begin the TLS 360 negotiation immediately upon connection and then continue with the 361 initial steps of an NNTP session. This use of strict TLS on a 362 separate port is the preferred way of using TLS with NNTP. 364 As some existing implementations negotiate TLS via a dynamic 365 upgrade from unencrypted to TLS-protected traffic during an NNTP 366 session, this specification formalizes the STARTTLS command in use 367 for that purpose. However, as already mentioned above, 368 implementations SHOULD use strict TLS on a separate port. 370 The second sentence of the first paragraph in Section 2.2.2 of 371 [RFC4642] is replaced with the following text: 373 The STARTTLS command is usually used to initiate session security, 374 although it can also be used for client and/or server certificate 375 authentication. 377 The third paragraph in Section 5 of [RFC4642] is removed. 378 Consequently, NNTP no longer requires to implement any cipher suites, 379 other than those prescribed by TLS [RFC5246] and Section 4.2.1 of 380 [RFC7525]. 382 Appendix B. Implementation Notes 384 Some governments enforce legislation prohibiting the export of strong 385 cryptographic technologies. Nothing in this document ought to be 386 taken as advice to violate such prohibitions. 388 Appendix C. Acknowledgements 390 This document draws heavily on ideas in [RFC7590] by Peter 391 Saint-Andre and Thijs Alkemade, and a large portion of this text was 392 borrowed from that specification. 394 The author would like to thank the following individuals for 395 contributing their ideas and support for writing this specification: 396 Michael Baeuerle, Richard Kettlewell, and Chris Newman. 398 Appendix D. Document History (to be removed by RFC Editor before 399 publication) 401 D.1. Changes since -00 403 o Clarify in the introduction of Section 2 that NNTP implementations 404 compliant with this document are REQUIRED to also comply with 405 [RFC7525]. 407 o Improve the wording of Section 2.2 to mention that configuration 408 is primarily intended for news servers. Also, be more consistent 409 in the options to accept, and include signature algorithms and 410 named groups. 412 Appendix E. Issues to Address 414 o Should the paragraph starting with "Servers MUST be able to 415 understand backwards-compatible TLS Client Hello messages" in 416 Section 2.2.2 of [RFC4642] remain as-is or should it be modernized 417 with another wording? (And which one? or is it already done by 418 the reference to [RFC7525]?) 420 o Should the paragraphs in Section 5 of [RFC4642] dealing with how 421 the client checks the server hostname and the binding between the 422 identity of servers and the public keys presented be modernized? 423 (Obsolete them in favour of RFC 6125 for instance? or maybe 424 [RFC7525] is enough as it also points to RFC 6125) 426 o Regarding peering between mode-switching news servers, should 427 something specific be added? NNTP has port 119, and NNTP over TLS 428 has port 563. NNSP has port 433 but no dedicated port for TLS. 429 Shouldn't a port for NNSP over TLS be registered? Otherwise, both 430 reading and peering are supposed to use port 563, which may be 431 inconvenient. We could then recommend the use of stunnel with TCP 432 wrappers, or an equivalent mechanism, listening to that new 433 separate port for mode-switching news servers that do not natively 434 support TLS for peering. 436 Author's Address 438 Julien Elie 439 10 allee Clovis 440 Noisy-le-Grand 93160 441 France 443 EMail: julien@trigofacile.com 444 URI: http://www.trigofacile.com/