idnits 2.17.1 draft-elie-nntp-tls-recommendations-05.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 (February 7, 2017) is 2634 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) == Missing Reference: 'BCP195' is mentioned on line 665, but not defined == Missing Reference: 'RFC-to-be' is mentioned on line 337, but not defined == Missing Reference: 'NNTP' is mentioned on line 603, but not defined == Missing Reference: 'PKI-CERT' is mentioned on line 604, but not defined == Missing Reference: 'NNTP-COMPRESS' is mentioned on line 663, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 664, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission J. Elie 3 Internet-Draft February 7, 2017 4 Updates: 4642 (if approved) 5 Intended status: Standards Track 6 Expires: August 11, 2017 8 Use of Transport Layer Security (TLS) 9 in the Network News Transfer Protocol (NNTP) 10 draft-elie-nntp-tls-recommendations-05 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 August 11, 2017. 37 Copyright Notice 39 Copyright (c) 2017 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. Updates/Changes to RFC 4642 . . . . . . . . . . . . . . . . . 3 58 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Protocol Versions and Security Preferences . . . . . . . 5 61 3.3. Server Name Indication . . . . . . . . . . . . . . . . . 5 62 3.4. Prevention of SSL Stripping . . . . . . . . . . . . . . . 5 63 3.5. Authenticated Connections . . . . . . . . . . . . . . . . 6 64 3.6. Human Factors . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 6.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Appendix A. Detailed Changes to RFC 4642 . . . . . . . . . . . . 11 71 A.1. Related to TLS-level Compression . . . . . . . . . . . . 11 72 A.2. Related to Implicit TLS . . . . . . . . . . . . . . . . . 11 73 A.3. Related to RC4 Cipher Suites . . . . . . . . . . . . . . 12 74 A.4. Related to Server Name Indication . . . . . . . . . . . . 12 75 A.5. Related to Certificate Verification . . . . . . . . . . . 12 76 A.6. Related to Other Obsolete Wording . . . . . . . . . . . . 13 77 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 13 78 Appendix C. Document History (to be removed by RFC Editor before 79 publication) . . . . . . . . . . . . . . . . . . . . 13 80 C.1. Changes since -04 . . . . . . . . . . . . . . . . . . . . 13 81 C.2. Changes since -03 . . . . . . . . . . . . . . . . . . . . 14 82 C.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 14 83 C.4. Changes since -01 . . . . . . . . . . . . . . . . . . . . 14 84 C.5. Changes since -00 . . . . . . . . . . . . . . . . . . . . 15 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 The Network News Transfer Protocol (NNTP) [RFC3977] has been using 90 Transport Layer Security (TLS) [RFC5246] (along with its precursor, 91 Secure Sockets Layer or SSL) since at least year 2000. The use of 92 TLS in NNTP was formalized in [RFC4642], providing at the same time 93 implementation recommendations. In order to address the evolving 94 threat model on the Internet today, this document provides stronger 95 recommendations regarding that use. 97 In particular, this document updates [RFC4642] by specifying that 98 NNTP implementations and deployments MUST follow the best current 99 practices documented in the "Recommendations for Secure Use of TLS 100 and DTLS" [RFC7525]. This includes stronger recommendations 101 regarding SSL/TLS protocol versions, fallback to lower versions, TLS 102 negotiation, TLS-level compression, TLS session resumption, cipher 103 suites, public key lengths, forward secrecy, hostname validation, 104 certificate verification, and other aspects of using TLS with NNTP. 106 [[Q1: For RFC Editor: Throughout the document, should [RFC7525] be 107 referenced as [BCP195] or [RFC7525]? Same question for other BCP 108 documents.]] 110 1.1. Conventions Used in This Document 112 Any term not defined in this document has the same meaning as it does 113 in [RFC4642] or the NNTP core specification [RFC3977]. 115 When this document uses the terms "implicit TLS", it refers to TLS 116 negotiation immediately upon connection on a separate port. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 [RFC2119]. 123 1.2. Author's Note 125 Please write the first letter of "Elie" with an acute accent wherever 126 possible -- it is U+00C9 ("É" in XML). The third letter of 127 "Stephane" and the penultimate letter of "allee" similarly have an 128 acute accent (U+00E9, "é" in XML). Also, the letters "ae" in 129 "Baeuerle" should be written as an a-umlaut (U+00E4, "ä" in 130 XML). 132 2. Updates/Changes to RFC 4642 134 This document updates [RFC4642] in the following aspects: 136 o NNTP implementations and deployments SHOULD disable TLS-level 137 compression (Section 3.3 of [RFC7525]), thus no longer using TLS 138 as a means to provide data compression (contrary to Abstract and 139 Section 2.2.2 of [RFC4642]). 141 o NNTP implementations and deployments SHOULD prefer implicit TLS 142 and therefore use strict TLS configuration (Section 3.2 of 143 [RFC7525]), that is to say they SHOULD use a port dedicated to 144 NNTP over TLS, and begin the TLS negotiation immediately upon 145 connection (contrary to a dynamic upgrade from unencrypted to TLS- 146 protected traffic via the use of the STARTTLS command, as 147 Section 1 of [RFC4642] was encouraging). Implicit TLS is the 148 preferred way of using TLS with NNTP for the same reasons, 149 transposed to NNTP, as those given in Appendix A of [MUA-STS]. 150 (Note that [MUA-STS] and [RFC4642] have one author in common.) 152 o NNTP implementations and deployments MUST NOT negotiate RC4 cipher 153 suites ([RFC7465]) contrary to Section 5 of [RFC4642] that 154 required them to implement the TLS_RSA_WITH_RC4_128_MD5 cipher 155 suite so as to ensure that any two NNTP compliant implementations 156 can be configured to interoperate. This document removes that 157 requirement, so that NNTP client and server implementations follow 158 the recommendations given in Sections 4.2 and 4.2.1 of [RFC7525] 159 instead. The mandatory-to-implement cipher(s) suite(s) depend on 160 the TLS protocol version. For instance, when TLS 1.2 is used, the 161 TLS_RSA_WITH_AES_128_CBC_SHA cipher suite MUST be implemented 162 (Section 9 of [RFC5246]). 164 o All NNTP clients and any NNTP server that is known by multiple 165 names MUST support the Server Name Indication (SNI) extension 166 defined in Section 3 of [RFC6066], in conformance with Section 3.6 167 of [RFC7525]. It was only a "SHOULD" in Section 2.2.2 of 168 [RFC4642]. 170 o NNTP implementations and deployments MUST follow the rules and 171 guidelines defined in [RFC6125] and [RFC5280] for hostname 172 validation and certificate verification. Part of Section 5 of 173 [RFC4642] is therefore rationalized in favour of following those 174 two documents. 176 Appendix A of this document gives detailed changes with regards to 177 the wording of [RFC4642]. 179 3. Recommendations 181 The best current practices documented in the "Recommendations for 182 Secure Use of TLS and DTLS" [RFC7525] are included here by reference. 183 Therefore, NNTP implementations and deployments compliant with this 184 document are REQUIRED to also comply with [RFC7525]. 186 Instead of repeating those recommendations here, this document mostly 187 provides supplementary information regarding secure implementation 188 and deployment of NNTP technologies. 190 3.1. Compression 192 NNTP supports the use of the COMPRESS command, defined in Section 2.2 193 of [RFC8054], to compress data between an NNTP client and server. 194 Although this NNTP extension might have slightly stronger security 195 properties than TLS-level compression [RFC3749] (since NNTP 196 compression can be activated after authentication has completed, thus 197 reducing the chances that authentication credentials can be leaked 198 via for instance a Compression Ratio Info-leak Made Easy (CRIME) 199 attack, as described in Section 2.6 of [CRIME]), this document 200 neither encourages nor discourages the use of the NNTP COMPRESS 201 extension. 203 3.2. Protocol Versions and Security Preferences 205 NNTP implementations of news servers are encouraged to support 206 options to configure the minimal TLS protocol version to accept, and 207 which cipher suites, signature algorithms or groups (like elliptic 208 curves) to use for incoming connections. Additional options can 209 naturally also be supported. The goal is to enable administrators of 210 news servers to easily and quickly strengthen security, if need be 211 (for instance by rejecting cipher suites considered unsafe with 212 regards to local policy). 214 News clients may also support similar options, either configurable by 215 the user or enforced by the news reader. 217 3.3. Server Name Indication 219 The TLS extension for Server Name Indication (SNI) defined in 220 Section 3 of [RFC6066] MUST be implemented by all news clients. It 221 also MUST be implemented by any news server that is known by multiple 222 names. (Otherwise, it is not possible for a server with several 223 hostnames to present the correct certificate to the client.) 225 3.4. Prevention of SSL Stripping 227 In order to help prevent SSL Stripping attacks (Section 2.1 of 228 [RFC7457]), NNTP implementations and deployments MUST follow the 229 recommendations provided in Section 3.2 of [RFC7525]. Notably, in 230 case implicit TLS is not used, news clients SHOULD attempt to 231 negotiate TLS even if the server does not advertise the STARTTLS 232 capability label in response to the CAPABILITIES command (Section 2.1 233 of [RFC4642]). 235 3.5. Authenticated Connections 237 [RFC4642] already provides recommendations and requirements for 238 certificate validation in the context of checking the client or the 239 server's identity. Those requirements are strengthened by 240 Appendix A.5 of this document. 242 Wherever possible, it is best to prefer certificate-based 243 authentication (along with SASL [RFC4422]), and ensure that: 245 o Clients authenticate servers. 247 o Servers authenticate clients. 249 o Servers authenticate other peer servers. 251 This document does not mandate certificate-based authentication, 252 although such authentication is strongly preferred. As mentioned in 253 Section 2.2.2 of [RFC4642], the AUTHINFO SASL command (Section 2.4 of 254 [RFC4643]) with the EXTERNAL mechanism (Appendix A of [RFC4422]) MAY 255 be used to authenticate a client once its TLS credentials have been 256 successfully exchanged. 258 Given the pervasiveness of eavesdropping [RFC7258], even an encrypted 259 but unauthenticated connection might be better than an unencrypted 260 connection (this is similar to the "better-than-nothing security" 261 approach for IPsec [RFC5386], and in accordance with opportunistic 262 security principles [RFC7435]). Encrypted but unauthenticated 263 connections include connections negotiated using anonymous 264 Diffie-Hellman mechanisms or using self-signed certificates, among 265 others. 267 Note: when an NNTP server receives a Netnews article, it MAY add a 268 (Section 3.1.5 of [RFC5536]), which appears as "!!" in 269 the Path header field of that article, to indicate that it verified 270 the identity of the client or peer server. This document encourages 271 the construction of such Path header fields, as described in 272 Section 3.2.1 of [RFC5537]. 274 3.6. Human Factors 276 NNTP clients SHOULD provide ways for end users (and NNTP servers 277 SHOULD provide ways for administrators) to complete at least the 278 following tasks: 280 o Determine if a given incoming or outgoing connection is encrypted 281 using a security layer (either using TLS or an SASL mechanism that 282 negotiates a security layer). 284 o Be warned if the version of TLS used for encryption of a given 285 stream is not secure enough. 287 o If authenticated encryption is used, determine how the connection 288 was authenticated or verified. 290 o Be warned if the certificate offered by an NNTP server cannot be 291 verified. 293 o Be warned if the cipher suite used to encrypt a connection is not 294 secure enough. 296 o Be warned if the certificate changes for a given server. 298 o When a security layer is not already in place, be warned if a 299 given server stops advertising the STARTTLS capability label in 300 response to the CAPABILITIES command (Section 2.1 of [RFC4642]) 301 whereas it advertised the STARTTLS capability label during any 302 previous connection within a (possibly configurable) time frame. 303 (Otherwise, a human might not see the warning the first time, and 304 the warning would disappear immediately after that.) 306 o Be warned if a failure response to the STARTTLS command is 307 received from the server whereas the STARTTLS capability label was 308 advertised. 310 Note that the last two tasks cannot occur when implicit TLS is used, 311 and that the penultimate task helps prevent an attack known as SSL 312 Stripping (Section 2.1 of [RFC7457]). 314 4. Security Considerations 316 Beyond the security considerations already described in [RFC4642], 317 [RFC6125] and [RFC7525], the following caveat is worth mentioning 318 when not using implicit TLS: NNTP servers need to ensure that they 319 are not vulnerable to the STARTTLS command injection vulnerability 320 (Section 2.2 of [RFC7457]). Though this command MUST NOT be 321 pipelined, an attacker could pipeline it. Therefore, NNTP servers 322 MUST discard any NNTP command received between the use of STARTTLS 323 and the end of TLS negotiation. 325 5. IANA Considerations 327 This document does not change the formal definition of the STARTTLS 328 extension (Section 6 of [RFC4642]). Nonetheless, as implementations 329 of the STARTTLS extension should follow this document, IANA will add 330 its reference to the existing STARTTLS label in the NNTP capability 331 labels registry contained in the Network News Transfer Protocol 332 (NNTP) Parameters registry: 334 +----------+--------------------------+----------------------+ 335 | Label | Meaning | Reference | 336 +----------+--------------------------+----------------------+ 337 | STARTTLS | Transport layer security | [RFC4642][RFC-to-be] | 338 +----------+--------------------------+----------------------+ 340 6. References 342 6.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, 346 DOI 10.17487/RFC2119, March 1997, 347 . 349 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", 350 RFC 3977, DOI 10.17487/RFC3977, October 2006, 351 . 353 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 354 Authentication and Security Layer (SASL)", RFC 4422, 355 DOI 10.17487/RFC4422, June 2006, 356 . 358 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 359 Transport Layer Security (TLS) with Network News Transfer 360 Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 361 2006, . 363 [RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer 364 Protocol (NNTP) Extension for Authentication", RFC 4643, 365 DOI 10.17487/RFC4643, October 2006, 366 . 368 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 369 (TLS) Protocol Version 1.2", RFC 5246, 370 DOI 10.17487/RFC5246, August 2008, 371 . 373 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 374 Housley, R., and W. Polk, "Internet X.509 Public Key 375 Infrastructure Certificate and Certificate Revocation List 376 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 377 . 379 [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 380 Article Format", RFC 5536, DOI 10.17487/RFC5536, November 381 2009, . 383 [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and 384 Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, 385 . 387 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 388 Extensions: Extension Definitions", RFC 6066, 389 DOI 10.17487/RFC6066, January 2011, 390 . 392 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 393 Verification of Domain-Based Application Service Identity 394 within Internet Public Key Infrastructure Using X.509 395 (PKIX) Certificates in the Context of Transport Layer 396 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 397 2011, . 399 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 400 "Recommendations for Secure Use of Transport Layer 401 Security (TLS) and Datagram Transport Layer Security 402 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 403 2015, . 405 6.2. Informative References 407 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty 408 Security Conference, 2012. 410 [MUA-STS] Moore, K. and C. Newman, "Mail User Agent Strict Transport 411 Security (MUA-STS)", Work in Progress, July 2016. 413 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 414 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 415 2004, . 417 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 418 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 419 December 2005, . 421 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 422 Security: An Unauthenticated Mode of IPsec", RFC 5386, 423 DOI 10.17487/RFC5386, November 2008, 424 . 426 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 427 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 428 2014, . 430 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 431 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 432 December 2014, . 434 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 435 Known Attacks on Transport Layer Security (TLS) and 436 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 437 February 2015, . 439 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 440 DOI 10.17487/RFC7465, February 2015, 441 . 443 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 444 Security (TLS) in the Extensible Messaging and Presence 445 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 446 2015, . 448 [RFC8054] Murchison, K. and J. Elie, "Network News Transfer Protocol 449 (NNTP) Extension for Compression", RFC 8054, 450 DOI 10.17487/RFC8054, January 2017, 451 . 453 Appendix A. Detailed Changes to RFC 4642 455 This section lists detailed changes this document applies to 456 [RFC4642]. 458 A.1. Related to TLS-level Compression 460 The second sentence in the Abstract of [RFC4642] is replaced with the 461 following text: 463 The primary goal is to provide encryption for single-link 464 confidentiality purposes, but data integrity, and (optional) 465 certificate-based peer entity authentication are also possible. 467 The second sentence of the first paragraph in Section 2.2.2 of 468 [RFC4642] is replaced with the following text: 470 The STARTTLS command is usually used to initiate session security, 471 although it can also be used for client and/or server certificate 472 authentication. 474 A.2. Related to Implicit TLS 476 The third and fourth paragraphs in Section 1 of [RFC4642] are 477 replaced with the following text: 479 TCP port 563 is dedicated to NNTP over TLS, and registered in the 480 IANA Service Name and Transport Protocol Port Number Registry for 481 that usage. NNTP implementations using TCP port 563 begin the TLS 482 negotiation immediately upon connection and then continue with the 483 initial steps of an NNTP session. This immediate TLS negotiation 484 on a separate port (referred to in this document as "implicit 485 TLS") is the preferred way of using TLS with NNTP. 487 If a host wishes to offer separate servers for transit and reading 488 clients (Section 3.4.1 of [NNTP]), TCP port 563 SHOULD be used for 489 implicit TLS with the reading server, and an unused port of its 490 choice different than TCP port 433 SHOULD be used for implicit TLS 491 with the transit server. The ports used for implicit TLS should 492 be clearly communicated to the clients, and specifically that no 493 plain-text communication occurs before the TLS session is 494 negotiated. 496 As some existing implementations negotiate TLS via a dynamic 497 upgrade from unencrypted to TLS-protected traffic during an NNTP 498 session on well-known TCP ports 119 or 433, this specification 499 formalizes the STARTTLS command in use for that purpose. However, 500 as already mentioned above, implementations SHOULD use implicit 501 TLS on a separate port. 503 Note: a common alternative to protect NNTP exchanges with transit 504 servers that do not implement TLS is the use of IPsec with 505 encryption [RFC4301]. 507 An additional informative reference to [RFC4301] is therefore added 508 to Section 7.2 of [RFC4642]. 510 A.3. Related to RC4 Cipher Suites 512 The third paragraph in Section 5 of [RFC4642] is removed. 513 Consequently, NNTP no longer requires to implement any cipher suites, 514 other than those prescribed by TLS (Section 9 of [RFC5246]) and 515 Sections 4.2 and 4.2.1 of [RFC7525]. 517 A.4. Related to Server Name Indication 519 The last two sentences of the seventh paragraph in Section 2.2.2 of 520 [RFC4642] are removed. Section 3.6 of [RFC7525] apply. 522 A.5. Related to Certificate Verification 524 The text between "During the TLS negotiation" and "identity 525 bindings)." in Section 5 of [RFC4642] is replaced with the following 526 text: 528 During TLS negotiation, the client MUST verify the server's 529 identity in order to prevent man-in-the-middle attacks. The 530 client MUST follow the rules and guidelines defined in [RFC6125], 531 where the reference identifier MUST be the server hostname that 532 the client used to open the connection, and that is also specified 533 in the TLS "server_name" extension [RFC6066]. The following NNTP- 534 specific consideration applies: DNS domain names in server 535 certificates MAY contain the wildcard character "*" as the 536 complete left-most label within the identifier. 538 If the match fails, the client MUST follow the recommendations in 539 Section 6.6 of [RFC6125] regarding certificate pinning and 540 fallback. 542 Beyond server identity checking, clients also MUST apply the 543 procedures specified in [RFC5280] for general certificate 544 validation (e.g., certificate integrity, signing, and path 545 validation). 547 Additional normative references to [RFC5280] (replacing [PKI-CERT] it 548 obsoletes), [RFC6066], and [RFC6125] are therefore added to 549 Section 7.1 of [RFC4642]. 551 A.6. Related to Other Obsolete Wording 553 The first two sentences of the seventh paragraph in Section 2.2.2 of 554 [RFC4642] are removed. There is no special requirement for NNTP with 555 regards to TLS Client Hello messages. Section 7.4.1.2 and Appendix E 556 of [RFC5246] apply. 558 Appendix B. Acknowledgments 560 This document draws heavily on ideas in [RFC7590] by Peter 561 Saint-Andre and Thijs Alkemade; a large portion of this text was 562 borrowed from that specification. 564 The author would like to thank the following individuals for 565 contributing their ideas and support for writing this specification: 566 Stephane Bortzmeyer, Ben Campbell, Viktor Dukhovni, Stephen Farrell, 567 Sabahattin Gucukoglu, Richard Kettlewell, Jouni Korhonen, Mirja 568 Kuehlewind, David Eric Mandelberg, Matija Nalis, Chris Newman, and 569 Peter Saint-Andre. 571 Special thanks to Michael Baeuerle, for shepherding this document, 572 and to the Responsible Area Director, Alexey Melnikov, for sponsoring 573 it. They both significantly helped to increase its quality. 575 Appendix C. Document History (to be removed by RFC Editor before 576 publication) 578 C.1. Changes since -04 580 o Take into account the remarks received during IESG telechat. 582 o Mention the Document Shepherd, Michael Baeuerle. 584 o Update the reference [NNTP-COMPRESS] to [RFC8054], now it has been 585 released. 587 o Add a reference to [RFC7435]. 589 o Move [RFC4422], [RFC4643], [RFC5536], and [RFC5537] from 590 informative to normative references. 592 o A few wording improvements. 594 C.2. Changes since -03 596 o Improve wording to make clear that the server hostname that the 597 client used to open the connection is the same as the one 598 specified in the TLS "server_name" extension. 600 o Move [RFC5280], [RFC6125] and [RFC7525] to normative references. 602 o In detailed changes of [RFC4642], use [NNTP] instead of [RFC3977] 603 as this RFC is referenced as [NNTP] in [RFC4642]. Also mention 604 obsolete [PKI-CERT]. 606 C.3. Changes since -02 608 o Use (and define) the "implicit TLS" terminology instead of "strict 609 TLS". The language in [RFC7525] is unfortunate since "strict TLS" 610 is not clearly defined in that document, and the name suggests 611 that it is an alternative to "opportunistic TLS", rather than an 612 alternative to STARTTLS. While STARTTLS is often used 613 opportunistically, that is not always the case. 615 o Mention SSL Stripping in Section 3.6 with a reference to 616 Section 2.1 of [RFC7457] because the intent of the related task 617 may not have been clear enough. Reported by Matija Nalis. 619 o Add Section 3.4 about how to prevent SSL stripping, notably by an 620 attempt to negotiate TLS even if STARTTLS is not advertised, when 621 implicit TLS is not used. 623 o Strengthen the requirements on hostname validation and certificate 624 verification, by referencing [RFC6125] and [RFC5280]. 626 o Ask IANA to add this document to the NNTP capabilily labels 627 registry. 629 o Reference the security considerations of [RFC6125]. 631 o Mention informative and normative references to add to [RFC4642]. 633 C.4. Changes since -01 635 o Take into account all the remarks sent during IETF Last Call. 637 o Move the part about [RFC4642] from Introduction to a new dedicated 638 Section named "Updates/Changes to RFC 4642" so as to make the 639 document a bit more structured. 641 o The warning about lack of STARTTLS is expanded in scope to say 642 "during any previous connection within a (possibly configurable) 643 time frame" instead of "during the previous connection". 645 o Remove Appendix about export restrictions on crypto. It is 646 useless since RFC 2804. 648 o Add wording about the use of strict TLS for transit. Mention the 649 use of a port other than 433 for strict TLS between two peers, and 650 add a note about a possible use of IPsec [RFC4301] for transit. 651 Do not only speak about port 563. 653 o Explicitly mention the mandatory-to-implement cipher suite for TLS 654 1.2. 656 o Do not keep the paragraph about TLS Client Hello messages and 657 Server Name Indication (SNI) in [RFC4642]. Support for SNI 658 [RFC6066] is now a MUST, and not a SHOULD. 660 o Reference [RFC7457] for the STARTTLS command injection 661 vulnerability. 663 o Add notes to RFC Editor to ask that [MUA-STS] and [NNTP-COMPRESS] 664 references be changed to their [RFCxxxx] form, once published, and 665 whether [BCP195] should be used instead of [RFC7525]. 667 o Move [RFC5246] (TLS) to a normative reference. 669 o Minor other wording improvements. 671 C.5. Changes since -00 673 o Clarify in the introduction of Section 3 that NNTP implementations 674 compliant with this document are REQUIRED to also comply with 675 [RFC7525]. 677 o Improve the wording of Section 3.2 to mention that configuration 678 is primarily intended for news servers. Also, be more consistent 679 in the options to accept, and include signature algorithms and 680 named groups. 682 Author's Address 683 Julien Elie 684 10 allee Clovis 685 Noisy-le-Grand 93160 686 France 688 EMail: julien@trigofacile.com 689 URI: http://www.trigofacile.com/