]> Ericsson AB

SE-164 80 Stockholm Sweden john.mattsson@ericsson.com

Security Transport Layer Security next generation unicorn sparkling distributed ledger The encodings used in the ECDHE groups secp256r1, secp384r1, and secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant overhead and the ECDSA encoding produces variable-length signatures. This document defines new optimal fixed-length encodings and registers new ECDHE groups and ECDSA signature algorithms using these new encodings. The new encodings reduce the size of the ECDHE groups with 33, 49, and 67 bytes and the ECDSA algorithms with an average of 7 bytes. These new encodings also work in DTLS 1.3 and are especially useful in cTLS. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The encodings used in the ECDHE groups secp256r1, secp384r1, and secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant overhead and the ECDSA encodings produces variable-length signatures. This document defines new optimal fixed-length encodings and registers new ECDHE groups and ECDSA signature algorithms using these new encodings. The new encodings reduce the size of the ECDHE groups with 33, 49, and 67 bytes and the ECDSA algorithms with an average of 7 bytes. These new encodings also work in DTLS 1.3 and are especially useful in cTLS . When secp256r1 and ecdsa_secp256r1_sha256 are used as a replacement for the the old encdoding in e.g., the cTLS template-based specialization mechanism they reduce the size of the TLS handshake with on average 80 bytes.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Compact ECDHE Encoding The encoding of the ECDHE groups secp256r1, secp384r1, and secp521r1 have significant overhead. This document specifies a new optimal fixed-length encoding for the groups. The new encoding is defined as a compression of the UncompressedPointRepresentation structure. Given a UncompressedPointRepresentation structure the legacy_form and Y field are omitted to create a CompactRepresentation structure. The resulting groups are called secp256r1_compact, secp384r1_compact, and secp521r1_compact. The new encodings have CompactRepresentation structures of length 32, 48, and 66 bytes, and reduce the size with 33, 49, and 67 bytes respectively. For secp256r1_compact, secp384r1_compact, and secp521r1_compact the opaque key_exchange field contains the serialized value of the CompactRepresentation struct: Compact ECDHE Groups

Value	Description	Recommended	Reference
TBD1	secp256r1_compact	Y	[This-Document]
TBD2	secp384r1_compact	Y	[This-Document]
TBD3	secp521r1_compact	Y	[This-Document]

Example Compact ECDHE Encoding The following shows an example compact ECDHE encoding. shows a 65 bytes ecdsa_secp256r1_sha256 UncompressedPointRepresentation structure.

secp256r1

shows the 32 bytes secp256r1_compact CompactRepresentation structure encoding of the same key share.

secp256r1_compact

Implementation Considerations for Compact Representation For compatibility with APIs a compressed y-coordinate might be required. For validation or for compatibility with APIs that do not support the full format an uncompressed y-coordinate might be required (using the notation in ):

• If a compressed y-coordinate is required, then the value ~yp set to zero can be used. The compact representation described above can in such a case be transformed into the SECG point compressed format by prepending X with the single byte 0x02 (i.e., M = 0x02 || X).
• If an uncompressed y-coordinate is required, then a y-coordinate has to be calculated following Section 2.3.4 of or Appendix C of . Any of the square roots (see or ) can be used. The uncompressed SECG format is M = 0x04 || X || Y.

For example: The curve P-256 has the parameters (using the notation in )

• p = 2²⁵⁶ - 2²²⁴ + 2¹⁹² + 2⁹⁶ - 1
• a = -3
• b = 410583637251521421293261297800472684091144410159937255 54835256314039467401291

Given an example x:

• x = 115792089183396302095546807154740558443406795108653336 398970697772788799766525

we can calculate y as the square root w = (x³ + a x + b)^{((p + 1)/4)} (mod p)

• y = 834387180070192806820075864918626005281451259964015754 16632522940595860276856

Note that this does not guarantee that (x, y) is on the correct elliptic curve. A full validation according to Section 5.6.2.3.3 of can be achieved by also checking that 0 x < p and that y² x³ + a x + b (mod p).

Compact ECDSA Encoding The variable-length encoding of the ECDSA signature algorithms ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 specified in have significant overhead. This document specifies a new optimal fixed-length encoding for the algorithms. The new encoding is defined as a compression of the DER-encoded ECDSA-Sig-Value structure. Given a DER-encoded ECDSA-Sig-Value structure the SEQUENCE type, INTEGER type, and length fields are omitted and if necessary the two INTEGER value fields are truncated (at most a single zero byte) or left padded with zeroes to the fixed length L. For secp256r1, secp384r1, and secp521r1, L is 32, 48, and 66 bytes respectively. The resulting signatures are called ecdsa_secp256r1_sha256_compact, ecdsa_secp384r1_sha384_compact, and ecdsa_secp521r1_sha512_compact and has length 64, 96, and 132 bytes respectively. The new encodings reduce the size of the signatures with an average of 7 bytes. For secp256r1_compact, secp384r1_compact, and secp521r1_compact the opaque signature field contains the compressed Ecdsa-Sig-Value. Compact ECDSA Signature Algorithms

Value	Description	Recommended	Reference
TBD4	ecdsa_secp256r1_sha256_compact	Y	[This-Document]
TBD5	ecdsa_secp384r1_sha384_compact	Y	[This-Document]
TBD6	ecdsa_secp521r1_sha512_compact	Y	[This-Document]

Example Compact ECDSA Encoding The following shows an example compact ECDSA encoding. shows a 71 bytes DER encoded ecdsa_secp256r1_sha256 ECDSA-Sig-Value structure. The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal).

ecdsa_secp256r1_sha256

shows the 64 bytes ecdsa_secp256r1_sha256_compact encoding of the same signature.

ecdsa_secp256r1_sha256_compact

Security Considerations Compact representation of a ECDHE key share produces the same shared secret as the uncompressed encoding and does not change any requirements on point validation. Using compact representation has some security benefits. As described in it helps to protect against invalid-curve attacks as an implementation will naturally detect invalid inputs when it reconstructs the missing coordinate. As not even the sign of the y-coordinate is encoded, compact representation trivially avoids so called "benign malleability" attacks where an attacker changes the sign, see .

IANA Considerations IANA is requested to update the TLS Supported Groups registry under the Transport Layer Security (TLS) Parameters heading with the contents of . IANA is requested to update the TLS SignatureScheme registry under the Transport Layer Security (TLS) Parameters heading with the contents of .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. Informative References This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. Mozilla Cisco Arm Limited Google This document specifies a "compact" version of TLS and DTLS. It is logically isomorphic to ordinary TLS, but saves space by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS or DTLS, but it should eventually be possible for a single server port to offer cTLS alongside TLS or DTLS.

Acknowledgments The authors want to thank for their valuable comments and feedback.