]> Ericsson AB

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

Hannes.Tschofenig@gmx.net

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 old encodings they reduce the size of a mutually authenticated TLS handshake with on average 80 bytes. The new encodings have the same security properties and requirements as the old encodings.

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 specified in 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]

The difference between compact representation and point compression ) is that point compression also communicates the sign bit of the y-coordinate along with the x-coordinate while compact representation only transmits the x-coordinate.

Example Compact ECDHE Encoding The following shows an example compact ECDHE encoding. shows a 65 bytes secp256r1 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 compatibility with APIs that do not support the full format an uncompressed y-coordinate might be required. For point validation an uncompressed y-coordinate is 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 is done by also checking that 0 x < p and that y² x³ + a x + b (mod p). The implementation MUST perform public-key validation.

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 The new encodings are just encodings and have the same security properties and security requirements as the old encodings. 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, the peers MUST validate each other's public key shares.

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. 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 describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms. This document obsoletes RFC 4492. 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. Windy Hill Systems, LLC Cisco Google This document specifies a "compact" version of TLS 1.3 and DTLS 1.3. It saves bandwidth by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS 1.3 or DTLS 1.3 since the over-the-wire framing is different. A single server can, however, offer cTLS alongside TLS or DTLS.

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