Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier

Nir, Yoav; Josefsson, Simon; Pégourié-Gonnard, Manuel

doi:10.17487/rfc8422

Cited by 33 publications

(22 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Servers that support EC cipher suites with TLS 1.2 and below shall be able to process the supported point format received in the ClientHello message by the client. The servers shall process this extension in accordance with Section 5.1 of RFC 8422 [52].…”

Section: Supported Point Formatsmentioning

confidence: 99%

“…Servers that support EC cipher suites shall also be able to send the supported EC point format in the ServerHello message as described in Section 5.2 of RFC 8422 [52].…”

Section: Supported Point Formatsmentioning

confidence: 99%

“…Client implementations shall send this extension in TLS 1.3 ClientHello messages and in ClientHello messages that include ephemeral ECDH cipher suites. When elliptic curve cipher suites are configured, at least one of the NIST-approved curves, P-256 (secp256r1) and P-384 (secp384r1), shall be supported as described in RFC 8422 [52]. Additional NIST-recommended elliptic curves are listed in SP 800-56A, Appendix D [6].…”

Section: Supported Groupsmentioning

confidence: 99%

“…Applies to TLS versions: 1.0, 1.1, 1.2 The clients that support EC cipher suites with TLS 1.2 and below shall be capable of specifying supported point formats in the ClientHello message in accordance with Section 5.1 of [52].…”

Section: Supported Point Formatsmentioning

confidence: 99%

See 3 more Smart Citations

Guidelines for the selection, configuration, and use of Transport Layer Security (TLS) implementations

McKay¹,

Cooper²

2019

View full text Add to dashboard Cite

AuthorityThis publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation's measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL's responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL's research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations. AbstractTransport Layer Security (TLS) provides mechanisms to protect data during electronic dissemination across the Internet. This Special Publication provides guidance to the selection and configuration of TLS protocol implementations while making effective use of Federal Information Processing Standards (FIPS) and NIST-recommended cryptographic algorithms. It requires that TLS 1.2 configured with FIPS-based cipher suites be supported by all government TLS servers and clients and requires support for TLS 1.3 by January 1, 2024. This Special Publication also provides guidance on certificates and TLS extensions that impact security.

show abstract

Section: Supported Point Formatsmentioning

confidence: 99%

“…Servers that support EC cipher suites shall also be able to send the supported EC point format in the ServerHello message as described in Section 5.2 of RFC 8422 [52].…”

Section: Supported Point Formatsmentioning

confidence: 99%

Section: Supported Groupsmentioning

confidence: 99%

Section: Supported Point Formatsmentioning

confidence: 99%

See 2 more Smart Citations

Guidelines for the selection, configuration, and use of Transport Layer Security (TLS) implementations

McKay¹,

Cooper²

2019

View full text Add to dashboard Cite

show abstract

“…(EC)DHE [28][11] guarantees FS. As depicted in Figure 3, to generate a session key using (EC)DHE, the server sends its (EC)DHE public-key parameters ecdhe pk S , signed with its long-term private-key sk S using the (sign) function in a ServerKeyExchange (SKE) message.…”

Section: Client (C) Server (S)mentioning

confidence: 99%

Towards Forward Secure Internet Traffic

Alashwali

Szałachowski

Martin

2019

Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering

View full text Add to dashboard Cite

Forward Secrecy (FS) is a security property in key-exchange algorithms which guarantees that a compromise in the secrecy of a long-term privatekey does not compromise the secrecy of past session keys. With a growing awareness of long-term mass surveillance programs by governments and others, FS has become widely regarded as a highly desirable property. This is particularly true in the TLS protocol, which is used to secure Internet communication. In this paper, we investigate FS in pre-TLS 1.3 protocols, which do not mandate FS, but still widely used today. We conduct an empirical analysis of over 10 million TLS servers from three different datasets using a novel heuristic approach. Using a modern TLS client handshake algorithms, our results show 5.37% of top domains, 7.51% of random domains, and 26.16% of random IPs do not select FS key-exchange algorithms. Surprisingly, 39.20% of the top domains, 24.40% of the random domains, and 14.46% of the random IPs that do not select FS, do support FS. In light of this analysis, we discuss possible paths toward forward secure Internet traffic. As an improvement of the current state, we propose a new client-side mechanism that we call "Best Effort Forward Secrecy" (BEFS), and an extension of it that we call "Best Effort Forward Secrecy and Authenticated Encryption" (BESAFE), which aims to guide (force) misconfigured servers to FS using a best effort approach. Finally, within our analysis, we introduce a novel adversarial model that we call "discriminatory" adversary, which is applicable to the TLS protocol.

show abstract

Public‐Key Cryptosystems

2024

Cryptography

View full text Add to dashboard Cite

Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier

Cited by 33 publications

References 6 publications

Guidelines for the selection, configuration, and use of Transport Layer Security (TLS) implementations

Guidelines for the selection, configuration, and use of Transport Layer Security (TLS) implementations

Towards Forward Secure Internet Traffic

Public‐Key Cryptosystems

Contact Info

Product

Resources

About