diff options
Diffstat (limited to 'doc/rfc/rfc8996.txt')
| -rw-r--r-- | doc/rfc/rfc8996.txt | 1007 |
1 files changed, 1007 insertions, 0 deletions
diff --git a/doc/rfc/rfc8996.txt b/doc/rfc/rfc8996.txt new file mode 100644 index 0000000..20f7ac4 --- /dev/null +++ b/doc/rfc/rfc8996.txt @@ -0,0 +1,1007 @@ + + + + +Internet Engineering Task Force (IETF) K. Moriarty +Request for Comments: 8996 CIS +BCP: 195 S. Farrell +Obsoletes: 5469, 7507 Trinity College Dublin +Updates: 3261, 3329, 3436, 3470, 3501, 3552, March 2021 + 3568, 3656, 3749, 3767, 3856, 3871, + 3887, 3903, 3943, 3983, 4097, 4111, + 4162, 4168, 4217, 4235, 4261, 4279, + 4497, 4513, 4531, 4540, 4582, 4616, + 4642, 4680, 4681, 4712, 4732, 4743, + 4744, 4785, 4791, 4823, 4851, 4964, + 4975, 4976, 4992, 5018, 5019, 5023, + 5024, 5049, 5054, 5091, 5158, 5216, + 5238, 5263, 5281, 5364, 5415, 5422, + 5456, 5734, 5878, 5953, 6012, 6042, + 6083, 6084, 6176, 6347, 6353, 6367, + 6460, 6614, 6739, 6749, 6750, 7030, + 7465, 7525, 7562, 7568, 8261, 8422 +Category: Best Current Practice +ISSN: 2070-1721 + + + Deprecating TLS 1.0 and TLS 1.1 + +Abstract + + This document formally deprecates Transport Layer Security (TLS) + versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those + documents have been moved to Historic status. These versions lack + support for current and recommended cryptographic algorithms and + mechanisms, and various government and industry profiles of + applications using TLS now mandate avoiding these old TLS versions. + TLS version 1.2 became the recommended version for IETF protocols in + 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), + providing sufficient time to transition away from older versions. + Removing support for older versions from implementations reduces the + attack surface, reduces opportunity for misconfiguration, and + streamlines library and product maintenance. + + This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC + 4347) but not DTLS version 1.2, and there is no DTLS version 1.1. + + This document updates many RFCs that normatively refer to TLS version + 1.0 or TLS version 1.1, as described herein. This document also + updates the best practices for TLS usage in RFC 7525; hence, it is + part of BCP 195. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8996. + +Copyright Notice + + Copyright (c) 2021 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 + (https://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. + +Table of Contents + + 1. Introduction + 1.1. RFCs Updated + 1.2. Terminology + 2. Support for Deprecation + 3. SHA-1 Usage Problematic in TLS 1.0 and TLS 1.1 + 4. Do Not Use TLS 1.0 + 5. Do Not Use TLS 1.1 + 6. Updates to RFC 7525 + 7. Operational Considerations + 8. Security Considerations + 9. IANA Considerations + 10. References + 10.1. Normative References + 10.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 + [RFC4346] were superseded by TLS 1.2 [RFC5246] in 2008, which has now + itself been superseded by TLS 1.3 [RFC8446]. Datagram Transport + Layer Security (DTLS) version 1.0 [RFC4347] was superseded by DTLS + 1.2 [RFC6347] in 2012. Therefore, it is timely to further deprecate + TLS 1.0, TLS 1.1, and DTLS 1.0. Accordingly, the aforementioned + documents have been moved to Historic status. + + Technical reasons for deprecating these versions include: + + * They require the implementation of older cipher suites that are no + longer desirable for cryptographic reasons, e.g., TLS 1.0 makes + TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement. + * There is a lack of support for current recommended cipher suites, + especially authenticated encryption with associated data (AEAD) + ciphers, which were not supported prior to TLS 1.2. Note that + registry entries for no-longer-desirable ciphersuites remain in + the registries, but many TLS registries were updated by [RFC8447], + which indicates that such entries are not recommended by the IETF. + * The integrity of the handshake depends on SHA-1 hash. + * The authentication of the peers depends on SHA-1 signatures. + * Support for four TLS protocol versions increases the likelihood of + misconfiguration. + * At least one widely used library has plans to drop TLS 1.1 and TLS + 1.0 support in upcoming releases; products using such libraries + would need to use older versions of the libraries to support TLS + 1.0 and TLS 1.1, which is clearly undesirable. + + Deprecation of these versions is intended to assist developers as + additional justification to no longer support older (D)TLS versions + and to migrate to a minimum of (D)TLS 1.2. Deprecation also assists + product teams with phasing out support for the older versions, to + reduce the attack surface and the scope of maintenance for protocols + in their offerings. + +1.1. RFCs Updated + + This document updates the following RFCs that normatively reference + TLS 1.0, TLS 1.1, or DTLS 1.0. The update is to obsolete usage of + these older versions. Fallback to these versions is prohibited + through this update. Specific references to mandatory minimum + protocol versions of TLS 1.0 or TLS 1.1 are replaced by TLS 1.2, and + references to minimum protocol version DTLS 1.0 are replaced by DTLS + 1.2. Statements that "TLS 1.0 is the most widely deployed version + and will provide the broadest interoperability" are removed without + replacement. + + [RFC3261] [RFC3329] [RFC3436] [RFC3470] [RFC3501] [RFC3552] [RFC3568] + [RFC3656] [RFC3749] [RFC3767] [RFC3856] [RFC3871] [RFC3887] [RFC3903] + [RFC3943] [RFC3983] [RFC4097] [RFC4111] [RFC4162] [RFC4168] [RFC4217] + [RFC4235] [RFC4261] [RFC4279] [RFC4497] [RFC4513] [RFC4531] [RFC4540] + [RFC4582] [RFC4616] [RFC4642] [RFC4680] [RFC4681] [RFC4712] [RFC4732] + [RFC4785] [RFC4791] [RFC4823] [RFC4851] [RFC4964] [RFC4975] [RFC4976] + [RFC4992] [RFC5018] [RFC5019] [RFC5023] [RFC5024] [RFC5049] [RFC5054] + [RFC5091] [RFC5158] [RFC5216] [RFC5238] [RFC5263] [RFC5281] [RFC5364] + [RFC5415] [RFC5422] [RFC5456] [RFC5734] [RFC5878] [RFC6012] [RFC6042] + [RFC6083] [RFC6084] [RFC6176] [RFC6353] [RFC6367] [RFC6739] [RFC6749] + [RFC6750] [RFC7030] [RFC7465] [RFC7525] [RFC7562] [RFC7568] [RFC8261] + [RFC8422] + + The status of [RFC7562], [RFC6042], [RFC5456], [RFC5024], [RFC4540], + and [RFC3656] will be updated with permission of the Independent + Submissions Editor. + + In addition, these RFCs normatively refer to TLS 1.0 or TLS 1.1 and + have already been obsoleted; they are still listed here and marked as + updated by this document in order to reiterate that any usage of the + obsolete protocol should use modern TLS: [RFC3316], [RFC3489], + [RFC3546], [RFC3588], [RFC3734], [RFC3920], [RFC4132], [RFC4244], + [RFC4347], [RFC4366], [RFC4492], [RFC4507], [RFC4572], [RFC4582], + [RFC4934], [RFC5077], [RFC5081], [RFC5101], and [RFC5953]. + + Note that [RFC4642] has already been updated by [RFC8143], which + makes an overlapping, but not quite identical, update as this + document. + + [RFC6614] has a requirement for TLS 1.1 or later, although it only + makes an informative reference to [RFC4346]. This requirement is + updated to be for TLS 1.2 or later. + + [RFC6460], [RFC4744], and [RFC4743] are already Historic; they are + still listed here and marked as updated by this document in order to + reiterate that any usage of the obsolete protocol should use modern + TLS. + + This document updates DTLS [RFC6347]. [RFC6347] had allowed for + negotiating the use of DTLS 1.0, which is now forbidden. + + The DES and International Data Encryption Algorithm (IDEA) cipher + suites specified in [RFC5469] were specifically removed from TLS 1.2 + by [RFC5246]; since the only versions of TLS for which their usage is + defined are now Historic, [RFC5469] has been moved to Historic as + well. + + The version-fallback Signaling Cipher Suite Value specified in + [RFC7507] was defined to detect when a given client and server + negotiate a lower version of (D)TLS than their highest shared + version. TLS 1.3 ([RFC8446]) incorporates a different mechanism that + achieves this purpose, via sentinel values in the ServerHello.Random + field. With (D)TLS versions prior to 1.2 fully deprecated, the only + way for (D)TLS implementations to negotiate a lower version than + their highest shared version would be to negotiate (D)TLS 1.2 while + supporting (D)TLS 1.3; supporting (D)TLS 1.3 implies support for the + ServerHello.Random mechanism. Accordingly, the functionality from + [RFC7507] has been superseded, and this document marks it as + Obsolete. + +1.2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Support for Deprecation + + Specific details on attacks against TLS 1.0 and TLS 1.1, as well as + their mitigations, are provided in [NIST800-52r2], [RFC7457], and + other RFCs referenced therein. Although mitigations for the current + known vulnerabilities have been developed, any future issues + discovered in old protocol versions might not be mitigated in older + library versions when newer library versions do not support those old + protocols. + + For example, NIST has provided the following rationale, copied with + permission from Section 1.1, "History of TLS", of [NIST800-52r2]: + + | TLS 1.1, specified in RFC 4346 [24], was developed to address + | weaknesses discovered in TLS 1.0, primarily in the areas of + | initialization vector selection and padding error processing. + | Initialization vectors were made explicit to prevent a certain + | class of attacks on the Cipher Block Chaining (CBC) mode of + | operation used by TLS. The handling of padding errors was altered + | to treat a padding error as a bad message authentication code + | rather than a decryption failure. In addition, the TLS 1.1 RFC + | acknowledges attacks on CBC mode that rely on the time to compute + | the message authentication code (MAC). The TLS 1.1 specification + | states that to defend against such attacks, an implementation must + | process records in the same manner regardless of whether padding + | errors exist. Further implementation considerations for CBC modes + | (which were not included in RFC 4346 [24]) are discussed in + | Section 3.3.2. + | + | TLS 1.2, specified in RFC 5246 [25], made several cryptographic + | enhancements, particularly in the area of hash functions, with the + | ability to use or specify the SHA-2 family of algorithms for hash, + | MAC, and Pseudorandom Function (PRF) computations. TLS 1.2 also + | adds authenticated encryption with associated data (AEAD) cipher + | suites. + | + | TLS 1.3, specified in RFC 8446 [57], represents a significant + | change to TLS that aims to address threats that have arisen over + | the years. Among the changes are a new handshake protocol, a new + | key derivation process that uses the HMAC-based Extract-and-Expand + | Key Derivation Function (HKDF) [37], and the removal of cipher + | suites that use RSA key transport or static Diffie-Hellman ( DH) + | [sic] key exchanges, the CBC mode of operation, or SHA-1. Many + | extensions defined for use with TLS 1.2 and previous versions + | cannot be used with TLS 1.3. + +3. SHA-1 Usage Problematic in TLS 1.0 and TLS 1.1 + + The integrity of both TLS 1.0 and TLS 1.1 depends on a running SHA-1 + hash of the exchanged messages. This makes it possible to perform a + downgrade attack on the handshake by an attacker able to perform 2^77 + operations, well below the acceptable modern security margin. + + Similarly, the authentication of the handshake depends on signatures + made using a SHA-1 hash or a concatenation of MD5 and SHA-1 hashes + that is not appreciably stronger than a SHA-1 hash, allowing the + attacker to impersonate a server when it is able to break the + severely weakened SHA-1 hash. + + Neither TLS 1.0 nor TLS 1.1 allows the peers to select a stronger + hash for signatures in the ServerKeyExchange or CertificateVerify + messages, making the only upgrade path the use of a newer protocol + version. + + See [Bhargavan2016] for additional details. + +4. Do Not Use TLS 1.0 + + TLS 1.0 MUST NOT be used. Negotiation of TLS 1.0 from any version of + TLS MUST NOT be permitted. + + Any other version of TLS is more secure than TLS 1.0. While TLS 1.0 + can be configured to prevent some types of interception, using the + highest version available is preferred. + + Pragmatically, clients MUST NOT send a ClientHello with + ClientHello.client_version set to {03,01}. Similarly, servers MUST + NOT send a ServerHello with ServerHello.server_version set to + {03,01}. Any party receiving a Hello message with the protocol + version set to {03,01} MUST respond with a "protocol_version" alert + message and close the connection. + + Historically, TLS specifications were not clear on what the record + layer version number (TLSPlaintext.version) could contain when + sending a ClientHello message. Appendix E of [RFC5246] notes that + TLSPlaintext.version could be selected to maximize interoperability, + though no definitive value is identified as ideal. That guidance is + still applicable; therefore, TLS servers MUST accept any value + {03,XX} (including {03,00}) as the record layer version number for + ClientHello, but they MUST NOT negotiate TLS 1.0. + +5. Do Not Use TLS 1.1 + + TLS 1.1 MUST NOT be used. Negotiation of TLS 1.1 from any version of + TLS MUST NOT be permitted. + + Pragmatically, clients MUST NOT send a ClientHello with + ClientHello.client_version set to {03,02}. Similarly, servers MUST + NOT send a ServerHello with ServerHello.server_version set to + {03,02}. Any party receiving a Hello message with the protocol + version set to {03,02} MUST respond with a "protocol_version" alert + message and close the connection. + + Any newer version of TLS is more secure than TLS 1.1. While TLS 1.1 + can be configured to prevent some types of interception, using the + highest version available is preferred. Support for TLS 1.1 is + dwindling in libraries and will impact security going forward if + mitigations for attacks cannot be easily addressed and supported in + older libraries. + + Historically, TLS specifications were not clear on what the record + layer version number (TLSPlaintext.version) could contain when + sending a ClientHello message. Appendix E of [RFC5246] notes that + TLSPlaintext.version could be selected to maximize interoperability, + though no definitive value is identified as ideal. That guidance is + still applicable; therefore, TLS servers MUST accept any value + {03,XX} (including {03,00}) as the record layer version number for + ClientHello, but they MUST NOT negotiate TLS 1.1. + +6. Updates to RFC 7525 + + "Recommendations for Secure Use of Transport Layer Security (TLS) and + Datagram Transport Layer Security (DTLS)" [RFC7525] is BCP 195, which + is the most recent Best Current Practice for implementing TLS and was + based on TLS 1.2. At the time of publication, TLS 1.0 and TLS 1.1 + had not yet been deprecated. As such, BCP 195 is called out + specifically to update text implementing the deprecation + recommendations of this document. + + This document updates Section 3.1.1 of [RFC7525] by changing SHOULD + NOT to MUST NOT as follows: + + * Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. + + Rationale: TLS 1.0 (published in 1999) does not support many + modern, strong cipher suites. In addition, TLS 1.0 lacks a per- + record Initialization Vector (IV) for CBC-based cipher suites and + does not warn against common padding errors. + + * Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. + + Rationale: TLS 1.1 (published in 2006) is a security improvement + over TLS 1.0 but still does not support certain stronger cipher + suites. + + This document updates Section 3.1.2 of [RFC7525] by changing SHOULD + NOT to MUST NOT and adding a reference to RFC 6347 as follows: + + * Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347] + [RFC6347]. + + Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). + +7. Operational Considerations + + This document is part of BCP 195 and, as such, reflects the + understanding of the IETF (at the time of this document's + publication) as to the best practices for TLS and DTLS usage. + + Though TLS 1.1 has been obsolete since the publication of [RFC5246] + in 2008, and DTLS 1.0 has been obsolete since the publication of + [RFC6347] in 2012, there may remain some systems in operation that do + not support (D)TLS 1.2 or higher. Adopting the practices recommended + by this document for any systems that need to communicate with the + aforementioned class of systems will cause failure to interoperate. + However, disregarding the recommendations of this document in order + to continue to interoperate with the aforementioned class of systems + incurs some amount of risk. The nature of the risks incurred by + operating in contravention to the recommendations of this document + are discussed in Sections 2 and 3, and knowledge of those risks + should be used along with any potential mitigating factors and the + risks inherent to updating the systems in question when deciding how + quickly to adopt the recommendations specified in this document. + +8. Security Considerations + + This document deprecates two older TLS protocol versions and one + older DTLS protocol version for security reasons already described. + The attack surface is reduced when there are a smaller number of + supported protocols and fallback options are removed. + +9. IANA Considerations + + This document has no IANA actions. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, DOI 10.17487/RFC2246, January 1999, + <https://www.rfc-editor.org/info/rfc2246>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. + Haukka, "Security Mechanism Agreement for the Session + Initiation Protocol (SIP)", RFC 3329, + DOI 10.17487/RFC3329, January 2003, + <https://www.rfc-editor.org/info/rfc3329>. + + [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport + Layer Security over Stream Control Transmission Protocol", + RFC 3436, DOI 10.17487/RFC3436, December 2002, + <https://www.rfc-editor.org/info/rfc3436>. + + [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for + the Use of Extensible Markup Language (XML) within IETF + Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470, + January 2003, <https://www.rfc-editor.org/info/rfc3470>. + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, + <https://www.rfc-editor.org/info/rfc3501>. + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, + DOI 10.17487/RFC3552, July 2003, + <https://www.rfc-editor.org/info/rfc3552>. + + [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known + Content Network (CN) Request-Routing Mechanisms", + RFC 3568, DOI 10.17487/RFC3568, July 2003, + <https://www.rfc-editor.org/info/rfc3568>. + + [RFC3656] Siemborski, R., "The Mailbox Update (MUPDATE) Distributed + Mailbox Database Protocol", RFC 3656, + DOI 10.17487/RFC3656, December 2003, + <https://www.rfc-editor.org/info/rfc3656>. + + [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol + Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May + 2004, <https://www.rfc-editor.org/info/rfc3749>. + + [RFC3767] Farrell, S., Ed., "Securely Available Credentials + Protocol", RFC 3767, DOI 10.17487/RFC3767, June 2004, + <https://www.rfc-editor.org/info/rfc3767>. + + [RFC3856] Rosenberg, J., "A Presence Event Package for the Session + Initiation Protocol (SIP)", RFC 3856, + DOI 10.17487/RFC3856, August 2004, + <https://www.rfc-editor.org/info/rfc3856>. + + [RFC3871] Jones, G., Ed., "Operational Security Requirements for + Large Internet Service Provider (ISP) IP Network + Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September + 2004, <https://www.rfc-editor.org/info/rfc3871>. + + [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, + DOI 10.17487/RFC3887, September 2004, + <https://www.rfc-editor.org/info/rfc3887>. + + [RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) + Extension for Event State Publication", RFC 3903, + DOI 10.17487/RFC3903, October 2004, + <https://www.rfc-editor.org/info/rfc3903>. + + [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol + Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, + DOI 10.17487/RFC3943, November 2004, + <https://www.rfc-editor.org/info/rfc3943>. + + [RFC3983] Newton, A. and M. Sanz, "Using the Internet Registry + Information Service (IRIS) over the Blocks Extensible + Exchange Protocol (BEEP)", RFC 3983, DOI 10.17487/RFC3983, + January 2005, <https://www.rfc-editor.org/info/rfc3983>. + + [RFC4097] Barnes, M., Ed., "Middlebox Communications (MIDCOM) + Protocol Evaluation", RFC 4097, DOI 10.17487/RFC4097, June + 2005, <https://www.rfc-editor.org/info/rfc4097>. + + [RFC4111] Fang, L., Ed., "Security Framework for Provider- + Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, + DOI 10.17487/RFC4111, July 2005, + <https://www.rfc-editor.org/info/rfc4111>. + + [RFC4162] Lee, H.J., Yoon, J.H., and J.I. Lee, "Addition of SEED + Cipher Suites to Transport Layer Security (TLS)", + RFC 4162, DOI 10.17487/RFC4162, August 2005, + <https://www.rfc-editor.org/info/rfc4162>. + + [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The + Stream Control Transmission Protocol (SCTP) as a Transport + for the Session Initiation Protocol (SIP)", RFC 4168, + DOI 10.17487/RFC4168, October 2005, + <https://www.rfc-editor.org/info/rfc4168>. + + [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, + DOI 10.17487/RFC4217, October 2005, + <https://www.rfc-editor.org/info/rfc4217>. + + [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An + INVITE-Initiated Dialog Event Package for the Session + Initiation Protocol (SIP)", RFC 4235, + DOI 10.17487/RFC4235, November 2005, + <https://www.rfc-editor.org/info/rfc4235>. + + [RFC4261] Walker, J. and A. Kulkarni, Ed., "Common Open Policy + Service (COPS) Over Transport Layer Security (TLS)", + RFC 4261, DOI 10.17487/RFC4261, December 2005, + <https://www.rfc-editor.org/info/rfc4261>. + + [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key + Ciphersuites for Transport Layer Security (TLS)", + RFC 4279, DOI 10.17487/RFC4279, December 2005, + <https://www.rfc-editor.org/info/rfc4279>. + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, + DOI 10.17487/RFC4346, April 2006, + <https://www.rfc-editor.org/info/rfc4346>. + + [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, + "Interworking between the Session Initiation Protocol + (SIP) and QSIG", BCP 117, RFC 4497, DOI 10.17487/RFC4497, + May 2006, <https://www.rfc-editor.org/info/rfc4497>. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security Mechanisms", + RFC 4513, DOI 10.17487/RFC4513, June 2006, + <https://www.rfc-editor.org/info/rfc4513>. + + [RFC4531] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) Turn Operation", RFC 4531, DOI 10.17487/RFC4531, + June 2006, <https://www.rfc-editor.org/info/rfc4531>. + + [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple + Middlebox Configuration (SIMCO) Protocol Version 3.0", + RFC 4540, DOI 10.17487/RFC4540, May 2006, + <https://www.rfc-editor.org/info/rfc4540>. + + [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor + Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, + November 2006, <https://www.rfc-editor.org/info/rfc4582>. + + [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and + Security Layer (SASL) Mechanism", RFC 4616, + DOI 10.17487/RFC4616, August 2006, + <https://www.rfc-editor.org/info/rfc4616>. + + [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using + Transport Layer Security (TLS) with Network News Transfer + Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October + 2006, <https://www.rfc-editor.org/info/rfc4642>. + + [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental + Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, + <https://www.rfc-editor.org/info/rfc4680>. + + [RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User + Mapping Extension", RFC 4681, DOI 10.17487/RFC4681, + October 2006, <https://www.rfc-editor.org/info/rfc4681>. + + [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., + and Y. Kim, "Transport Mappings for Real-time Application + Quality-of-Service Monitoring (RAQMON) Protocol Data Unit + (PDU)", RFC 4712, DOI 10.17487/RFC4712, October 2006, + <https://www.rfc-editor.org/info/rfc4712>. + + [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet + Denial-of-Service Considerations", RFC 4732, + DOI 10.17487/RFC4732, December 2006, + <https://www.rfc-editor.org/info/rfc4732>. + + [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access + Protocol (SOAP)", RFC 4743, DOI 10.17487/RFC4743, December + 2006, <https://www.rfc-editor.org/info/rfc4743>. + + [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over + the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, + DOI 10.17487/RFC4744, December 2006, + <https://www.rfc-editor.org/info/rfc4744>. + + [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) + Ciphersuites with NULL Encryption for Transport Layer + Security (TLS)", RFC 4785, DOI 10.17487/RFC4785, January + 2007, <https://www.rfc-editor.org/info/rfc4785>. + + [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, + "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, + DOI 10.17487/RFC4791, March 2007, + <https://www.rfc-editor.org/info/rfc4791>. + + [RFC4823] Harding, T. and R. Scott, "FTP Transport for Secure Peer- + to-Peer Business Data Interchange over the Internet", + RFC 4823, DOI 10.17487/RFC4823, April 2007, + <https://www.rfc-editor.org/info/rfc4823>. + + [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The + Flexible Authentication via Secure Tunneling Extensible + Authentication Protocol Method (EAP-FAST)", RFC 4851, + DOI 10.17487/RFC4851, May 2007, + <https://www.rfc-editor.org/info/rfc4851>. + + [RFC4964] Allen, A., Ed., Holm, J., and T. Hallin, "The P-Answer- + State Header Extension to the Session Initiation Protocol + for the Open Mobile Alliance Push to Talk over Cellular", + RFC 4964, DOI 10.17487/RFC4964, September 2007, + <https://www.rfc-editor.org/info/rfc4964>. + + [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., + "The Message Session Relay Protocol (MSRP)", RFC 4975, + DOI 10.17487/RFC4975, September 2007, + <https://www.rfc-editor.org/info/rfc4975>. + + [RFC4976] Jennings, C., Mahy, R., and A. B. Roach, "Relay Extensions + for the Message Sessions Relay Protocol (MSRP)", RFC 4976, + DOI 10.17487/RFC4976, September 2007, + <https://www.rfc-editor.org/info/rfc4976>. + + [RFC4992] Newton, A., "XML Pipelining with Chunks for the Internet + Registry Information Service", RFC 4992, + DOI 10.17487/RFC4992, August 2007, + <https://www.rfc-editor.org/info/rfc4992>. + + [RFC5018] Camarillo, G., "Connection Establishment in the Binary + Floor Control Protocol (BFCP)", RFC 5018, + DOI 10.17487/RFC5018, September 2007, + <https://www.rfc-editor.org/info/rfc5018>. + + [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online + Certificate Status Protocol (OCSP) Profile for High-Volume + Environments", RFC 5019, DOI 10.17487/RFC5019, September + 2007, <https://www.rfc-editor.org/info/rfc5019>. + + [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom + Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, + October 2007, <https://www.rfc-editor.org/info/rfc5023>. + + [RFC5024] Friend, I., "ODETTE File Transfer Protocol 2.0", RFC 5024, + DOI 10.17487/RFC5024, November 2007, + <https://www.rfc-editor.org/info/rfc5024>. + + [RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo, Ed., + "Applying Signaling Compression (SigComp) to the Session + Initiation Protocol (SIP)", RFC 5049, + DOI 10.17487/RFC5049, December 2007, + <https://www.rfc-editor.org/info/rfc5049>. + + [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, + "Using the Secure Remote Password (SRP) Protocol for TLS + Authentication", RFC 5054, DOI 10.17487/RFC5054, November + 2007, <https://www.rfc-editor.org/info/rfc5054>. + + [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography + Standard (IBCS) #1: Supersingular Curve Implementations of + the BF and BB1 Cryptosystems", RFC 5091, + DOI 10.17487/RFC5091, December 2007, + <https://www.rfc-editor.org/info/rfc5091>. + + [RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", + RFC 5158, DOI 10.17487/RFC5158, March 2008, + <https://www.rfc-editor.org/info/rfc5158>. + + [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS + Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, + March 2008, <https://www.rfc-editor.org/info/rfc5216>. + + [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over + the Datagram Congestion Control Protocol (DCCP)", + RFC 5238, DOI 10.17487/RFC5238, May 2008, + <https://www.rfc-editor.org/info/rfc5238>. + + [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. + Khartabil, "Session Initiation Protocol (SIP) Extension + for Partial Notification of Presence Information", + RFC 5263, DOI 10.17487/RFC5263, September 2008, + <https://www.rfc-editor.org/info/rfc5263>. + + [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication + Protocol Tunneled Transport Layer Security Authenticated + Protocol Version 0 (EAP-TTLSv0)", RFC 5281, + DOI 10.17487/RFC5281, August 2008, + <https://www.rfc-editor.org/info/rfc5281>. + + [RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup + Language (XML) Format Extension for Representing Copy + Control Attributes in Resource Lists", RFC 5364, + DOI 10.17487/RFC5364, October 2008, + <https://www.rfc-editor.org/info/rfc5364>. + + [RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, + "Dynamic Provisioning Using Flexible Authentication via + Secure Tunneling Extensible Authentication Protocol (EAP- + FAST)", RFC 5422, DOI 10.17487/RFC5422, March 2009, + <https://www.rfc-editor.org/info/rfc5422>. + + [RFC5469] Eronen, P., Ed., "DES and IDEA Cipher Suites for Transport + Layer Security (TLS)", RFC 5469, DOI 10.17487/RFC5469, + February 2009, <https://www.rfc-editor.org/info/rfc5469>. + + [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Transport over TCP", STD 69, RFC 5734, + DOI 10.17487/RFC5734, August 2009, + <https://www.rfc-editor.org/info/rfc5734>. + + [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) + Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, + May 2010, <https://www.rfc-editor.org/info/rfc5878>. + + [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + RFC 5953, DOI 10.17487/RFC5953, August 2010, + <https://www.rfc-editor.org/info/rfc5953>. + + [RFC6042] Keromytis, A., "Transport Layer Security (TLS) + Authorization Using KeyNote", RFC 6042, + DOI 10.17487/RFC6042, October 2010, + <https://www.rfc-editor.org/info/rfc6042>. + + [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer + (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March + 2011, <https://www.rfc-editor.org/info/rfc6176>. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol (SNMP)", + STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, + <https://www.rfc-editor.org/info/rfc6353>. + + [RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher + Suites to Transport Layer Security (TLS)", RFC 6367, + DOI 10.17487/RFC6367, September 2011, + <https://www.rfc-editor.org/info/rfc6367>. + + [RFC6739] Schulzrinne, H. and H. Tschofenig, "Synchronizing Service + Boundaries and <mapping> Elements Based on the Location- + to-Service Translation (LoST) Protocol", RFC 6739, + DOI 10.17487/RFC6739, October 2012, + <https://www.rfc-editor.org/info/rfc6739>. + + [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", + RFC 6749, DOI 10.17487/RFC6749, October 2012, + <https://www.rfc-editor.org/info/rfc6749>. + + [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization + Framework: Bearer Token Usage", RFC 6750, + DOI 10.17487/RFC6750, October 2012, + <https://www.rfc-editor.org/info/rfc6750>. + + [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., + "Enrollment over Secure Transport", RFC 7030, + DOI 10.17487/RFC7030, October 2013, + <https://www.rfc-editor.org/info/rfc7030>. + + [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, + DOI 10.17487/RFC7465, February 2015, + <https://www.rfc-editor.org/info/rfc7465>. + + [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher + Suite Value (SCSV) for Preventing Protocol Downgrade + Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, + <https://www.rfc-editor.org/info/rfc7507>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <https://www.rfc-editor.org/info/rfc7525>. + + [RFC7562] Thakore, D., "Transport Layer Security (TLS) Authorization + Using Digital Transmission Content Protection (DTCP) + Certificates", RFC 7562, DOI 10.17487/RFC7562, July 2015, + <https://www.rfc-editor.org/info/rfc7562>. + + [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, + "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, + DOI 10.17487/RFC7568, June 2015, + <https://www.rfc-editor.org/info/rfc7568>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic + Curve Cryptography (ECC) Cipher Suites for Transport Layer + Security (TLS) Versions 1.2 and Earlier", RFC 8422, + DOI 10.17487/RFC8422, August 2018, + <https://www.rfc-editor.org/info/rfc8422>. + +10.2. Informative References + + [Bhargavan2016] + Bhargavan, K. and G. Leuren, "Transcript Collision + Attacks: Breaking Authentication in TLS, IKE, and SSH", + DOI 10.14722/ndss.2016.23418, February 2016, + <https://www.mitls.org/downloads/transcript- + collisions.pdf>. + + [NIST800-52r2] + National Institute of Standards and Technology, + "Guidelines for the Selection, Configuration, and Use of + Transport Layer Security (TLS) Implementations NIST + SP800-52r2", DOI 10.6028/NIST.SP.800-52r2, August 2019, + <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ + NIST.SP.800-52r2.pdf>. + + [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. + Wiljakka, "Internet Protocol Version 6 (IPv6) for Some + Second and Third Generation Cellular Hosts", RFC 3316, + DOI 10.17487/RFC3316, April 2003, + <https://www.rfc-editor.org/info/rfc3316>. + + [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, + "STUN - Simple Traversal of User Datagram Protocol (UDP) + Through Network Address Translators (NATs)", RFC 3489, + DOI 10.17487/RFC3489, March 2003, + <https://www.rfc-editor.org/info/rfc3489>. + + [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, + <https://www.rfc-editor.org/info/rfc3546>. + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. + Arkko, "Diameter Base Protocol", RFC 3588, + DOI 10.17487/RFC3588, September 2003, + <https://www.rfc-editor.org/info/rfc3588>. + + [RFC3734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Transport Over TCP", RFC 3734, DOI 10.17487/RFC3734, March + 2004, <https://www.rfc-editor.org/info/rfc3734>. + + [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence + Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, + October 2004, <https://www.rfc-editor.org/info/rfc3920>. + + [RFC4132] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia + Cipher Suites to Transport Layer Security (TLS)", + RFC 4132, DOI 10.17487/RFC4132, July 2005, + <https://www.rfc-editor.org/info/rfc4132>. + + [RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation + Protocol (SIP) for Request History Information", RFC 4244, + DOI 10.17487/RFC4244, November 2005, + <https://www.rfc-editor.org/info/rfc4244>. + + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, + <https://www.rfc-editor.org/info/rfc4347>. + + [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, + <https://www.rfc-editor.org/info/rfc4366>. + + [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. + Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites + for Transport Layer Security (TLS)", RFC 4492, + DOI 10.17487/RFC4492, May 2006, + <https://www.rfc-editor.org/info/rfc4492>. + + [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, + "Transport Layer Security (TLS) Session Resumption without + Server-Side State", RFC 4507, DOI 10.17487/RFC4507, May + 2006, <https://www.rfc-editor.org/info/rfc4507>. + + [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the + Transport Layer Security (TLS) Protocol in the Session + Description Protocol (SDP)", RFC 4572, + DOI 10.17487/RFC4572, July 2006, + <https://www.rfc-editor.org/info/rfc4572>. + + [RFC4934] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Transport Over TCP", RFC 4934, DOI 10.17487/RFC4934, May + 2007, <https://www.rfc-editor.org/info/rfc4934>. + + [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, + "Transport Layer Security (TLS) Session Resumption without + Server-Side State", RFC 5077, DOI 10.17487/RFC5077, + January 2008, <https://www.rfc-editor.org/info/rfc5077>. + + [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport + Layer Security (TLS) Authentication", RFC 5081, + DOI 10.17487/RFC5081, November 2007, + <https://www.rfc-editor.org/info/rfc5081>. + + [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information + Export (IPFIX) Protocol for the Exchange of IP Traffic + Flow Information", RFC 5101, DOI 10.17487/RFC5101, January + 2008, <https://www.rfc-editor.org/info/rfc5101>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <https://www.rfc-editor.org/info/rfc5246>. + + [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, + Ed., "Control And Provisioning of Wireless Access Points + (CAPWAP) Protocol Specification", RFC 5415, + DOI 10.17487/RFC5415, March 2009, + <https://www.rfc-editor.org/info/rfc5415>. + + [RFC5456] Spencer, M., Capouch, B., Guy, E., Ed., Miller, F., and K. + Shumard, "IAX: Inter-Asterisk eXchange Version 2", + RFC 5456, DOI 10.17487/RFC5456, February 2010, + <https://www.rfc-editor.org/info/rfc5456>. + + [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, + "Datagram Transport Layer Security (DTLS) Transport + Mapping for Syslog", RFC 6012, DOI 10.17487/RFC6012, + October 2010, <https://www.rfc-editor.org/info/rfc6012>. + + [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram + Transport Layer Security (DTLS) for Stream Control + Transmission Protocol (SCTP)", RFC 6083, + DOI 10.17487/RFC6083, January 2011, + <https://www.rfc-editor.org/info/rfc6083>. + + [RFC6084] Fu, X., Dickmann, C., and J. Crowcroft, "General Internet + Signaling Transport (GIST) over Stream Control + Transmission Protocol (SCTP) and Datagram Transport Layer + Security (DTLS)", RFC 6084, DOI 10.17487/RFC6084, January + 2011, <https://www.rfc-editor.org/info/rfc6084>. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, <https://www.rfc-editor.org/info/rfc6347>. + + [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport + Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, + January 2012, <https://www.rfc-editor.org/info/rfc6460>. + + [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, + "Transport Layer Security (TLS) Encryption for RADIUS", + RFC 6614, DOI 10.17487/RFC6614, May 2012, + <https://www.rfc-editor.org/info/rfc6614>. + + [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing + Known Attacks on Transport Layer Security (TLS) and + Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, + February 2015, <https://www.rfc-editor.org/info/rfc7457>. + + [RFC8143] Elie, J., "Using Transport Layer Security (TLS) with + Network News Transfer Protocol (NNTP)", RFC 8143, + DOI 10.17487/RFC8143, April 2017, + <https://www.rfc-editor.org/info/rfc8143>. + + [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, + "Datagram Transport Layer Security (DTLS) Encapsulation of + SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November + 2017, <https://www.rfc-editor.org/info/rfc8261>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS + and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, + <https://www.rfc-editor.org/info/rfc8447>. + +Acknowledgements + + Thanks to those that provided usage data and reviewed and/or improved + this document, including: Michael Ackermann, David Benjamin, David + Black, Deborah Brungard, Alan DeKok, Viktor Dukhovni, Julien Élie, + Adrian Farrelll, Gary Gapinski, Alessandro Ghedini, Peter Gutmann, + Jeremy Harris, Nick Hilliard, James Hodgkinson, Russ Housley, Hubert + Kario, Benjamin Kaduk, John Klensin, Watson Ladd, Eliot Lear, Ted + Lemon, John Mattsson, Keith Moore, Tom Petch, Eric Mill, Yoav Nir, + Andrei Popov, Michael Richardson, Eric Rescorla, Rich Salz, Mohit + Sethi, Yaron Sheffer, Rob Sayre, Robert Sparks, Barbara Stark, Martin + Thomson, Sean Turner, Loganaden Velvindron, Jakub Wilk, and + Christopher Wood. + +Authors' Addresses + + Kathleen Moriarty + Center for Internet Security (CIS) + East Greenbush, NY + United States of America + + Email: Kathleen.Moriarty.ietf@gmail.com + + + Stephen Farrell + Trinity College Dublin + Dublin + 2 + Ireland + + Phone: +353-1-896-2354 + Email: stephen.farrell@cs.tcd.ie |