EPP Over HTTPS Could Modernize Domain Registration Infrastructure

A new Internet Engineering Task Force (IETF) draft could change how domain registrars and registries carry the Extensible Provisioning Protocol (EPP), the protocol used to exchange commands for registering and managing domain names. Published on September 8, 2026, draft-ietf-regext-epp-https-05 defines a way to transport EPP through HTTPS instead of its traditional TCP-based transport. The proposal is still an Internet-Draft, not a finished Internet standard, but it has reached the point where real implementations and operational questions are being documented.

The proposal moves EPP from dedicated TCP connections to HTTPS

EPP has traditionally been transported over a dedicated Transmission Control Protocol (TCP) connection protected by Transport Layer Security (TLS). RFC 5734, published in 2009, defines that model and describes EPP sessions as stateful connections between a client and server. In practical terms, a registrar's EPP software maintains connections to a registry and exchanges XML commands and responses over those connections.

The new proposal keeps EPP itself largely intact while changing the transport underneath it. EPP commands would be carried inside HTTPS POST requests, with EPP XML used as the request and response content. That means existing EPP software does not have to be replaced with a completely different domain-registration protocol; much of the application-level logic can remain in place while the connection layer changes.

Why HTTPS changes the infrastructure around EPP

The strongest argument for EPP over HTTPS is not that HTTP is inherently faster than TCP. It is that HTTP is already understood by modern infrastructure. The draft specifically points to cloud-native environments and the ability to reuse HTTP load balancers, firewalls and Web Application Firewalls (WAFs), which can reduce the amount of specialized networking infrastructure required around an EPP service.

The difference is particularly visible at the network boundary. Traditional EPP over TCP uses port 700 by default, while the proposed HTTPS mapping uses the normal HTTPS port, 443. That makes the service easier to carry through networks where ordinary web traffic is already permitted, although operators still need to keep EPP traffic logically separated from normal web applications.

The EPP session remains stateful even though HTTP is stateless

There is an important technical catch. HTTP itself does not maintain the state that EPP expects, so the draft introduces an HTTP session identifier using cookies. A client begins by sending an empty POST request to the EPP server. The server returns the EPP greeting and a session cookie, and subsequent EPP requests use that cookie to remain associated with the same EPP connection.

This distinction matters when EPP is deployed behind multiple servers. An operator can use sticky sessions so requests carrying the same session identifier continue reaching the same backend, or it can store session state in a shared system that any backend can access. The second approach is more suitable for horizontal scaling and failover, but it makes the shared session store part of the service's security and availability boundary.

HTTP/2 and HTTP/3 help the transport, but do not make EPP concurrent

It would be easy to assume that putting EPP on HTTP/2 or HTTP/3 automatically allows several domain commands to execute at the same time. The draft explicitly does not do that. EPP commands within a session must remain ordered, and an EPP client must not have more than one outstanding HTTP request per EPP session.

HTTP/2 and HTTP/3 can still improve the underlying connection by providing more efficient connection management and reducing some transport-level head-of-line blocking. But they do not turn EPP itself into a parallel command-processing protocol. That limitation is important for operators evaluating performance: the proposal changes how EPP travels through the network more than it changes the semantics of domain provisioning.

Retries become a bigger concern when EPP rides on HTTP

HTTP POST is normally treated as a method that should not be automatically retried because repeating an operation can potentially repeat its side effects. EPP has a useful property here: its commands are designed with idempotent semantics, meaning repeating the same command can produce the same final repository state rather than applying the operation twice.

The draft nevertheless puts conditions around retries. An EPP client may retry a POST only when the failure could be temporary, the HTTP status allows such a retry, and the client knows that the complete EPP command and its extensions are idempotent. The retry must preserve the same command and transaction identifier, and the client must maintain command ordering. Intermediaries controlled by operators are specifically not supposed to invent their own automatic retry behavior for these requests.

Security becomes easier to integrate, but session protection still matters

The proposed transport requires HTTPS because EPP login credentials and other sensitive information must be protected in transit. The draft requires servers to support TLS 1.2 or later and recommends current TLS configuration practices. It also recommends client certificate authentication, commonly called mutual TLS (mTLS), as an additional way to verify EPP clients.

The HTTP session cookie receives equally strong treatment. The proposal requires the session cookie to use Secure, HttpOnly and SameSite=Strict attributes. It also calls for cryptographically secure session identifiers with at least 128 bits of entropy. These controls matter because possession of a valid session identifier could allow an attacker to impersonate an established EPP connection and potentially manipulate registry objects.

There are already implementations behind the proposal

This is not purely theoretical work. The September draft records a development implementation in the Verisign EPP SDK, with both client and server support for HTTP/1.1 and HTTP/2. The draft says HTTP/3 was not implemented there because of limitations in the underlying library.

Registro.it provides another useful data point. Its .it EPP client and server have already used a somewhat different HTTPS-based implementation in its live platform since 2009, according to the draft. That implementation does not exactly match the proposed session-establishment procedure, but it gives the working group evidence from a production environment rather than relying only on a laboratory design.

The biggest benefit may be operational rather than protocol-level

The proposal does not promise that domain registration will suddenly become dramatically faster. In fact, the draft acknowledges that HTTPS adds HTTP headers and TLS negotiation overhead compared with direct TCP transport. Persistent connections can reduce repeated setup costs, while HTTP/2 and HTTP/3 can improve connection efficiency, but the EPP command model remains sequential.

The more significant change is architectural. An EPP operator could put domain-registration traffic into infrastructure already designed for HTTPS, including standard load balancing, Layer 7 monitoring and modern DDoS protection. At the same time, that flexibility introduces new failure points: session affinity, shared state, HTTP intermediaries, retry policies and certificate management all have to be configured correctly.

It is a draft, not a replacement for EPP over TCP yet

The September 8 document is an Internet-Draft with an intended Standards Track status. IETF drafts can be revised, replaced or abandoned, so registrars and registries should not treat this document as a finalized Internet standard or assume that every detail will remain unchanged.

For now, the interesting development is that EPP over HTTPS has moved beyond a purely conceptual proposal. The draft now documents operational deployment models, security requirements and running implementations. If the work progresses toward an RFC, the result could give domain registries and registrars a standardized way to retain EPP while fitting the protocol more naturally into the HTTPS infrastructure that already dominates modern web services.