RFC 9934

Privacy-Enhanced Mail (PEM) File Format for Encrypted ClientHello (ECH)

📅 published March 2026, from ietf

RFC 9934: Privacy-Enhanced Mail (PEM) File Format for Encrypted ClientHello (ECH) 💖

Okay bestie, here's the tea 🫖. This is RFC 9934, and it's the Privacy-Enhanced Mail (PEM) File Format for Encrypted ClientHello (ECH). Stephen Farrell from Trinity College Dublin wrote it. It's a Standards Track document dated March 2026 (ISSN 2070-1721). The header doesn't list anything it obsoletes or updates. 🦋

Abstract

Okay so, ECH key pairs need to get set up in TLS servers, and those servers can be built with different TLS libraries 🧚. This document defines a standard file format for that job, kind of like how RFC 7468 sets up the other PEM file formats. It's giving organization ✨.

Status of This Memo

This is an Internet Standards Track document. 🎀

It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on Internet Standards, check out Section 2 of RFC 7841.

To find the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9934.

Copyright (c) 2026 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. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License.

Table of Contents 📖

1.  Introduction
2.  Terminology
3.  ECHConfig File
4.  Security Considerations
5.  IANA Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Author's Address

1. Introduction ✨

Okay so, Encrypted ClientHello (ECH) [RFC9849] for TLS1.3 [RFC8446] is a confidentiality mechanism for server names and other ClientHello content in TLS 🔒. To make it work, an ECHConfigList data structure has to be published in an HTTPS or SVCB RR [RFC9460] in the DNS. An ECHConfigList can hold one or more ECHConfig values. An ECHConfig structure carries the public component of a key pair, and that key pair usually gets (re-)generated every so often by some key manager for a TLS server. TLS servers then need to be set up to use these key pairs. Since different TLS servers can be built with different TLS libraries, it's a big win to have a standard format for ECH key pairs and configs, just like [RFC7468] did for PEM 🫶.

2. Terminology

Here's the key word rule, bestie 🍓. 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.

3. ECHConfig File 🎀

A PEM ECH file contains zero or one private key and one encoded ECHConfigList. Think of it as a tiny bundle 🧺.

The public and private keys MUST both be PEM encoded [RFC7468]. The file holds the concatenation of the PEM encoding of the private key (if present), followed by the PEM encoding of the public key(s) as an ECHConfigList. When a private key is present, the ECHConfigList MUST contain an ECHConfig that matches the private key. The private key MUST be encoded as a PKCS #8 PrivateKey [RFC7468]. The public key(s) MUST be the base64-encoded form (see Section 4 of [RFC4648]) of an ECHConfigList value that can be published in the DNS using an HTTPS RR as described in [RFC9848]. The string "ECHCONFIG" MUST be used in the PEM file delimiter for the public key.

Any content after the PEM encoded ECHConfigList SHOULD be ignored. 🙈

Here's an example ECHConfig PEM File, served fresh 💅:

-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VuBCIEICjd4yGRdsoP9gU7YT7My8DHx1Tjme8GYDXrOMCi8v1V
-----END PRIVATE KEY-----
-----BEGIN ECHCONFIG-----
AD7+DQA65wAgACA8wVN2BtscOl3vQheUzHeIkVmKIiydUhDCliA4iyQRCwAEAAEA
AQALZXhhbXBsZS5jb20AAA==
-----END ECHCONFIG-----

Figure 1: Example ECHConfig PEM File

If that ECHConfigList got published in the DNS for foo.example.com, you could grab it like this 👀:

$ dig +short HTTPS foo.example.com
1 . ech=AD7+DQA65wAgACA8wVN2BtscOl3vQheUzHeIkVmKIiydUhDCliA4iyQR
wAEAAEAAQALZXhhbXBsZS5jb20AAA==

Figure 2: Use of Dig to Get the ECHConfigList from DNS

TLS servers using this file format might configure multiple file names as part of their overall setup. For example, they might only use the ECHConfigList values from a subset of those files as the retry_configs value in the ECH fallback scenario. 🦋

An ECHConfigList in a PEM file might hold more than one ECHConfig, for example if those ECHConfig values have different extensions or different public_name values. Consistent with [RFC9849], the ECHConfig values within an ECHConfigList appear in decreasing order of preference. If the ECHConfigList value is going to be used as the retry_configs value, it might contain different public keys. (Nonetheless, when a private key is present, that MUST match the public key from one of the ECHConfig values.) ⭐

4. Security Considerations 💀

This section is serious business, so listen up 🚨.

Storing cryptographic keys in files leaves them vulnerable to anyone who gets read access to the filesystem where they're stored. The same protection mechanisms that would be used for a server's PEM-encoded HTTPS certificate private key should be used for the PEM ECH configuration.

The security considerations of [RFC9848] apply when retrieving an ECHConfigList from the DNS.

For clarity, only the ECHConfigList is to be published in the DNS. The private key from an ECH PEM file MUST NOT be published in the DNS. Repeat after me: never publish the private key 😭🔥.

5. IANA Considerations 🌸

This document has no IANA actions.

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgements 🫶

Huge thanks to Daniel McCarney, Jim Reid, and Peter Yee for their comments. 💜

Author's Address 🧚

Stephen Farrell
Trinity College Dublin
Dublin
2
Ireland
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie
📦 where this page comes from