]> NVIDIA

boris.pismenny@gmail.com

Security TLS Working Group Internet-Draft This document specifies a TLS 1.3 extension that enables DTLS 1.3 to negotiate the use of plaintext sequence numbers instead of protected sequence numbers. Plaintext sequence numbers are advantageous in closed networks where the benefits of lower latency outweigh the risk of ossification and reduced privacy.

Introduction Datagram Transport Layer Security (DTLS) 1.3 packet encryption protects not only record data, but also the record header's sequence number. The sequence number is encrypted by XORing it with a mask which is generated by encrypting the leading 16 bytes of the record's ciphertext with a sequence number key. For high performance networking, sequence number encryption is a trade-off between ossification and privacy on the one hand and latency and complexity for hardware acceleration on the other hand. Sequence number encryption improves privacy by hiding the real ordering of packets from on-path observers. Sequence number encryption also prevents protocol ossification, when middleboxes manipulate packet delivery based on the sequence number. Sequence number encryption however adds latency to packet processing on both sender and receiver. Sequence number encryption also increases the complexity and cost of NIC encryption accelerators, which are crucial for enabling encryption in high performance computing systems that seek to maximize performance and lowest penalty possible for encryption.

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.

Sequence Number Encryption Extension ; case SH: SeqNumEncAlgs selected_alg; }; } SupportedSequenceNumberEncryptionAlgorithms; ]]>

• OPEN: This extension might fit nicely with the TLS flags extension , but TLS flags doesn't seem to apply to DTLS.

The "sequence_number_encryption_algorithms" extension is used by the client to specify the record sequence number encryption algorithms it supports and by the server to select the algorithm it prefers. The ClientHello message lists algorithms by the order of their preference, starting from the most preferred algorithm. If this extension is not present, in either ClientHello or EncryptedExtensions, then both parties MUST fallback to the default record sequence number encryption algorithm.

• OPEN: Do we want an encrypted extension for the server's response? It is possible to use an encrypted extension, by using the default record sequence encryption algorithm prior to epoch 3 (epoch < 3), and enabling the selected algorithm only after epoch 3 (epoch >= 3).

Security Considerations This document allows endpoints to disable the record sequence number encryption algorithm, which retracts the on-path tracking anti-ossification protection established in record sequence number encryption. It is therefore RECOMMENDED that users limit the deployment of this extension to closed environments, such as data centers, where the risk of on-path observers is negligible.

IANA Considerations IANA is requested to assign a new value from the TLS ExtensionType values registry:

• The Extension Name should be sequence_number_encryption_algorithms
• The TLS 1.3 value should be CH,HRR,SH
• The DTLS-Only value should be Y
• The Recommended value should be N
• The Reference should be this document

Normative References 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. 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. Dell Technologies A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8.

Acknowledgments TODO acknowledge.