Internet-Draft GoE2EE July 2026
Justo Expires 21 January 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-justo-goe2ee-latest
Published:
Intended Status:
Informational
Expires:
Author:
R. D. Justo
Teamwork.com

GoE2EE: An End-to-End Encryption Protocol with Flexible Server Key Retrieval

Abstract

This document specifies GoE2EE, an application-layer protocol that provides end-to-end confidentiality and integrity between a client and a server using an ephemeral Elliptic Curve Diffie-Hellman (ECDH) key exchange and an Authenticated Encryption with Associated Data (AEAD) cipher. The protocol aims to provide a security level comparable to TLS 1.3 while allowing a shared secret to be reused across multiple connections originating from the same host, reducing handshake overhead. GoE2EE runs over either TCP or UDP and offers several strategies for a client to retrieve and authenticate the server's long-term public key, including a strategy based on the DNSSEC chain of trust.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at https://datatracker.ietf.org/doc/draft-justo-goe2ee/.

Source for this draft and an issue tracker can be found at https://github.com/rafaeljusto/goe2ee.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 21 January 2027.

▲

Table of Contents

1. Introduction

Transport Layer Security (TLS) [RFC8446] is the dominant protocol for securing communication on the Internet. It couples confidentiality and integrity with an authentication model that, in its most common deployment, relies on the Web Public Key Infrastructure (PKI) and X.509 certificates [RFC5280].

GoE2EE is an application-layer protocol that provides similar cryptographic guarantees to TLS 1.3 but decouples two concerns that TLS binds tightly together:

  1. how peers agree on a shared secret and encrypt traffic; and

  2. how the client obtains and authenticates the server's long-term public key.

For the first concern, GoE2EE performs an ephemeral ECDH key exchange so that the shared secret is never transmitted over the network, derives a symmetric key from that secret, and protects every subsequent message with an AEAD cipher.

For the second concern, GoE2EE deliberately leaves the trust model pluggable. A client MAY authenticate the server's public key through the Web PKI, through the DNSSEC chain of trust, through a pre-provisioned key, or, when no authentication is acceptable, by retrieving the key directly from the server in-band.

A distinguishing feature of GoE2EE is that a shared secret is bound to a client-chosen identifier rather than to a single transport connection. Consequently, several connections from the same host MAY reuse a previously negotiated secret and skip the handshake entirely, which reduces latency and allows the protocol to operate efficiently over connectionless transports such as UDP.

This document specifies the wire format, the cryptographic constructions, the handshake and message-exchange procedures, and the security considerations of the protocol. It corresponds to protocol version 1.

1.1. Requirements Language

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. These words may also appear in this document in lower case as plain English words, absent their normative meanings.

1.2. Terminology

The following terms are used throughout this document:

Client:

The peer that initiates a session and originates request messages.

Server:

The peer that answers requests and holds a long-term signing key pair.

Global key:

The server's long-term ("global") signing key pair. The server's public global key is used by the client to authenticate the handshake.

Session identifier (id):

A 16-octet identifier chosen by the client and associated with a shared secret. It is carried in requests so that the server can locate the corresponding secret.

Shared secret:

The secret produced by the ECDH exchange, from which the symmetric key is derived.

Counter:

A per-secret, strictly increasing 64-bit value used to derive AEAD nonces and to detect replays.

2. Protocol Overview

A GoE2EE session has two logical phases: a handshake phase and a message-exchange phase.

During the handshake, the client generates an ephemeral ECDH key pair, chooses a session identifier, and sends its public key to the server (the Setup action, Section 5.2). The server generates its own ephemeral ECDH key pair, computes the shared secret, and returns its public key together with a signature over the handshake transcript produced with the server's long-term global key. The client verifies the signature using the server's public global key, which it obtained beforehand through one of the retrieval strategies in Section 6, and then computes the same shared secret.

The full handshake is illustrated below.

client                                             server
  |                                                  |
  |-- Setup: id + client ECDH public key ----------->|
  |                             (compute shared       |
  |                              secret, store by id) |
  |<-- Setup response: server ECDH public key + ------|
  |    hash-type + signature over transcript          |
  | (verify signature,                                |
  |  compute shared secret)                           |
  |                                                  |
  |== Process: id + counter + encrypted message ====>|
  |<===== Process response: counter + encrypted ======|
  |                                                  |
Figure 1: Full handshake followed by message exchange.

Because the shared secret is indexed by the session identifier and not by the transport connection, a different connection from the same host that already knows a valid secret and identifier MAY skip the handshake and issue Process requests (Section 5.3) directly.

client                                             server
  |                                                  |
  |== Process: id + counter + encrypted message ====>|
  |<===== Process response: counter + encrypted ======|
  |                                                  |
Figure 2: Message exchange reusing a previously negotiated secret.

The server MUST maintain the mapping from session identifier to shared secret (and the associated replay state, Section 9.4) for as long as it is willing to accept messages for that session, which MAY outlive any individual transport connection. The mechanism and lifetime of this state are implementation choices.

3. Message Format

All messages are binary. Multi-octet integers are encoded in network byte order (big-endian) unless stated otherwise.

3.1. Request Header

Every request begins with a single octet whose two 4-bit fields are the protocol version and the action:

 0                   1
 0 1 2 3 4 5 6 7 8 9 ...
+-------+-------+---------------------------+
|version|action | message (variable)        |
+-------+-------+---------------------------+
Figure 3: Request header.
version (4 bits):

The protocol version. This document specifies version 1 (0x1). Up to 16 versions can be expressed.

action (4 bits):

An identifier that selects the request semantics. Up to 16 actions can be expressed. This document defines the actions in Table 1.

message (variable):

Action-specific content. It MAY be empty.

The fixed one-octet header, together with session identifiers carried inside Process requests, is what allows a client to issue actions in any order and to skip the handshake when a secret is already established.

The defined actions are:

Table 1: Actions defined in version 1.
Action Name Section
0x1 Hello Section 5.1
0x2 Setup Section 5.2
0x3 Process Section 5.3
0x4 Fetch Key Section 5.4

A server that receives a request whose version it does not support MUST reply with an error response (Section 3.3) carrying error code 0x04 (Unsupported version).

3.2. Success Response

When a request is processed successfully, the response begins with a single octet whose most significant bit is set to 1:

 0                   1
 0 1 2 3 4 5 6 7 8 9 ...
+-+-------------+---------------------------+
|1| reserved    | message (variable)        |
+-+-------------+---------------------------+
Figure 4: Success response header.
success (1 bit):

Set to 1 to indicate success.

reserved (7 bits):

Reserved for future use. A sender MUST set these bits to 0 and a receiver MUST ignore them.

message (variable):

Action-specific content. It MAY be empty.

3.3. Error Response

Any request MAY produce an error response. An error response begins with a single octet whose most significant bit is cleared to 0, followed by an error code and an optional human-readable message:

+---+----------+--------------+--------------+---------------+
| 0 | resv (7) | err-code (4) | err-size (8) | err-msg (var) |
+---+----------+--------------+--------------+---------------+
Figure 5: Error response. resv = reserved bits, err = error, msg = message. Field widths in octets except where noted.
success (1 bit):

Cleared to 0 to indicate failure.

reserved (7 bits):

Reserved for future use; set to 0 on transmit and ignored on receipt.

error-code (4 octets):

An unsigned 32-bit integer identifying the error. Defined values appear in Table 2.

error-message-size (8 octets):

An unsigned 64-bit integer giving the length in octets of the error message.

error-message (variable):

A UTF-8 diagnostic string of the indicated length. It MAY be empty and MUST NOT be relied upon for automated decision-making.

The defined error codes are:

Table 2: Error codes defined in version 1.
Error Code Description
0x00000001 Malformed request
0x00000002 Server error
0x00000003 Unknown client
0x00000004 Unsupported version
0x00000005 Replay detected

A receiver MUST treat an error message whose declared size would exceed the receiver's configured limits as a malformed response and abort the session. See Section 9.6.

4. Cryptographic Constructions

4.1. Key Exchange

The ephemeral key exchange uses ECDH with the X25519 function [RFC7748]. Public keys are exchanged encoded as a SubjectPublicKeyInfo structure in PKIX, ASN.1 DER form (Section 4.1 of [RFC5280]).

Each peer generates a fresh X25519 key pair for every handshake. The shared secret is the X25519 output computed from one peer's private key and the other peer's public key.

4.2. Key Derivation

The raw ECDH output MUST NOT be used directly as a symmetric key, as it is not uniformly distributed. The symmetric key is derived using HKDF [RFC5869] with SHA-256 [FIPS.180-4] as follows:

key = HKDF-SHA256(salt = "" (empty),
                  IKM  = ECDH shared secret,
                  info = "goe2ee/v1 aes-256-gcm",
                  L    = 32)

The info string provides domain separation and MUST be exactly the ASCII string goe2ee/v1 aes-256-gcm for this version. The salt is empty (a string of zero length). The output length L is 32 octets, producing a 256-bit key.

4.3. Authenticated Encryption

Messages are protected with AES-256-GCM [FIPS.197] [NIST.SP.800-38D], an AEAD algorithm [RFC5116], keyed with the 32-octet key from the previous section. The authentication tag is 16 octets and is appended to the ciphertext. The Associated Data is empty in this version.

4.4. Nonce Derivation

AES-GCM requires that a (key, nonce) pair never repeat. GoE2EE never transmits nonces; instead each peer derives the 12-octet GCM nonce deterministically from a direction octet and the message counter:

nonce[0]      = direction
nonce[1..3]   = 0x00 0x00 0x00
nonce[4..11]  = counter (64-bit, big-endian)

where the direction octet is:

Table 3: Nonce direction octets.
Value Direction
0x00 client to server
0x01 server to client

The direction octet ensures that the two halves of a conversation never derive the same nonce from the same counter under the shared secret. The counter MUST strictly increase for every message a peer sends under a given secret (see Section 5.3.1). Together these guarantee nonce uniqueness, which is required for the security of AES-GCM.

4.5. Handshake Transcript Signature

The server authenticates the handshake by signing a transcript that binds both ephemeral public keys and the session identifier. The transcript is the concatenation:

+----------+------------+----------+------------+---------+
| clen (4) | client-key | slen (4) | server-key | id (16) |
+----------+------------+----------+------------+---------+
Figure 6: Handshake transcript. clen/slen = client/server key size. Field widths in octets except where noted.

where client-key and server-key are the DER-encoded SubjectPublicKeyInfo representations of the client and server ephemeral public keys, each prefixed by its 32-bit big-endian length, and id is the 16-octet session identifier.

Signing the full transcript rather than the server key alone binds the signature to both parties and to the specific session, so a valid signature cannot be transplanted onto a different key exchange.

The signature is produced with the server's long-term global key. The signature algorithm depends on the type of the global key (Table 5):

  • RSA keys: RSASSA-PKCS1-v1_5 [RFC8017] over the hash of the transcript.

  • ECDSA keys: ECDSA over the hash of the transcript, with the signature encoded as an ASN.1 DER sequence.

  • Ed25519 keys: Ed25519 [RFC8032] over the transcript. Note that for Ed25519 the hash type carried in the response (Section 5.2) selects the digest applied to the transcript before signing; the pure Ed25519 algorithm is used (not Ed25519ph).

The hash function used to build the digest is signalled by the hash-type field of the Setup response:

Table 4: Hash types.
Type Hash
0x2 SHA-256
0x3 SHA-384
0x4 SHA-512

SHA-1 is intentionally omitted because it is cryptographically broken. A client MUST reject a Setup response that specifies a hash type it does not support.

5. Actions

5.1. Hello

The Hello action is a liveness check. It carries no message body.

Request:

+-------+-------+
|  0x1  |  0x1  |
+-------+-------+

Response: a success response (Section 3.3 defines the failure form) with an empty message body.

5.2. Setup

The Setup action performs the key exchange. The client sends its session identifier and ephemeral public key; the server replies with its ephemeral public key and a signature over the transcript (Section 4.5).

Request:

+-----+-----+---------+-----------+------------+
| 0x1 | 0x2 | id (16) | pklen (4) | public-key |
+-----+-----+---------+-----------+------------+
Figure 7: Setup request. pklen = public-key size. Field widths in octets except where noted.
id (16 octets):

A client-chosen identifier for the secret, formatted as a UUID [RFC4122]. It MUST be unique per host so that the server can distinguish concurrent sessions from the same host, including those traversing intermediaries such as proxies. The client SHOULD choose it so that it is unpredictable to other parties.

public-key-size (4 octets):

The length in octets of the following public key.

public-key (variable):

The client's ephemeral X25519 public key, DER-encoded SubjectPublicKeyInfo.

Response:

+---+------+-----------+--------+-----------+------------+-----+
| 1 | resv | pklen (4) | pubkey | htype (1) | siglen (8) | sig |
+---+------+-----------+--------+-----------+------------+-----+
Figure 8: Setup response. pklen = public-key size, htype = hash-type, siglen = signature size, sig = signature. Field widths in octets except where noted.
public-key-size (4 octets):

The length in octets of the server's public key.

public-key (variable):

The server's ephemeral X25519 public key, DER-encoded SubjectPublicKeyInfo.

hash-type (1 octet):

The hash used to build the signed digest (Table 4).

signature-size (8 octets):

The length in octets of the signature.

signature (variable):

The signature over the handshake transcript (Section 4.5), produced with the server's global key.

On receiving the Setup response, the client MUST rebuild the transcript from its own public key, the server's public key, and the session identifier, and MUST verify the signature using the server's public global key. If verification fails, the client MUST abort the session and MUST NOT send Process requests for that identifier. On success, the client computes the shared secret from its private key and the server's public key.

5.3. Process

The Process action exchanges application data protected by the shared secret.

Request:

+-----+-----+---+------+---------+---------+----------+---------+
| 0x1 | 0x3 | E | r(7) | id (16) | ctr (8) | mlen (8) | enc-msg |
+-----+-----+---+------+---------+---------+----------+---------+
Figure 9: Process request. E = expect-reply flag, r = reserved flags, ctr = counter, mlen = encrypted-message size, enc-msg = encrypted message. Field widths in octets except where noted.
E (expect-reply, 1 bit):

When set to 1, the client expects a response. When cleared to 0, the request is fire-and-forget and the server SHOULD NOT send a response. This is useful over UDP to avoid a return trip.

reserved-flags (7 bits):

Reserved for future use; set to 0 on transmit and ignored on receipt.

id (16 octets):

The session identifier chosen during Setup, identifying the shared secret.

counter (8 octets):

The per-secret message counter (see Section 5.3.1), used both to derive the nonce (Section 4.4) and to detect replays (Section 9.4).

encrypted-message-size (8 octets):

The length in octets of the ciphertext (including the AEAD tag).

encrypted-message (variable):

The application payload encrypted with AES-256-GCM under the derived key, using the nonce derived from direction 0x00 and this counter.

If the server does not recognise the identifier, it MUST reply with error code 0x03 (Unknown client). If the counter is a replay or falls before the replay window, the server MUST reply with error code 0x05 (Replay detected). If decryption or tag verification fails, the server MUST treat the request as malformed (0x01).

Response (sent only when E is set):

+-+----------+-----------+---------------------+---------------+
|1| reserved |counter (8)| enc-msg-size (8)    | enc-msg (var) |
+-+----------+-----------+---------------------+---------------+
Figure 10: Process response. Field widths in octets except where noted.
counter (8 octets):

The counter from the request being answered. The server derives the response nonce from direction 0x01 and this counter.

encrypted-message-size (8 octets):

The length in octets of the response ciphertext (including tag).

encrypted-message (variable):

The response payload encrypted under the same shared secret.

5.3.1. Counter Rules

The counter is a property of the shared secret, not of a transport connection. A client MUST ensure that every Process request it sends under a given secret carries a strictly greater counter than any previous request under that secret. When a secret is shared across several connections from the same host (see Section 7), the counter MUST be incremented atomically so that no value is ever reused across those connections.

The server echoes the request counter in the response and derives the response nonce from it with the server-to-client direction octet. Because request and response use different direction octets, the same counter value in both directions does not cause a nonce collision.

5.4. Fetch Key

The Fetch Key action lets a client retrieve the server's public global key in-band. This method provides no authentication of the key and is therefore vulnerable to man-in-the-middle attacks; it MUST NOT be used when an authenticated retrieval strategy (Section 6) is available.

Request:

+-------+-------+
|  0x1  |  0x4  |
+-------+-------+

Response:

+---+------+------------+-----------+------------+
| 1 | resv | keyalg (1) | pklen (4) | public-key |
+---+------+------------+-----------+------------+
Figure 11: Fetch Key response. keyalg = key-algorithm, pklen = public-key size. Field widths in octets except where noted.
key-algorithm (1 octet):

The algorithm of the returned key, used to parse it (Table 5).

public-key-size (4 octets):

The length in octets of the public key.

public-key (variable):

The server's public global key.

The defined key algorithms are:

Table 5: Global key algorithms.
Algorithm Description
0x1 RSA
0x2 ECDSA
0x3 Ed25519

6. Server Public Key Retrieval

The security of the handshake rests on the client authenticating the server's public global key. This document does not mandate a single trust model; it defines the following strategies, of which a client MUST use an authenticated one unless the deployment explicitly accepts the risk of an unauthenticated key:

DNSSEC:

The client retrieves the key from a DNSKEY resource record of the server's domain name and validates it through the DNSSEC chain of trust [RFC4033]. To protect the resolution path between the client and the recursive resolver, the client SHOULD use DNS over HTTPS [RFC8484].

Web PKI:

The client obtains an X.509 certificate [RFC5280] for the server, for example over an HTTPS connection to the server's domain, and validates it against a trusted certification authority.

Pre-provisioned:

The key is provided to the client out of band, for example as a PEM file.

In-band (Fetch Key):

The client retrieves the key using the Fetch Key action (Section 5.4). This strategy is unauthenticated and is NOT RECOMMENDED.

The choice of strategy is a local deployment decision and does not affect the wire format of the handshake.

7. Secret Reuse and Connection Pooling

Because a shared secret is bound to a session identifier rather than to a transport connection, a client MAY reuse an established secret for multiple connections to the same host and MAY skip the handshake on those connections, issuing Process requests directly. This reduces both round trips and cryptographic work.

A client that reuses a secret across connections MUST coordinate the counter as described in Section 5.3.1 so that nonces are never reused. Implementations that pool connections SHOULD share a single counter, incremented atomically, per secret.

The server retains the association between identifier, shared secret, and replay state independently of any connection, so it can serve Process requests for a known identifier that arrive on a fresh connection.

8. Transport Considerations

GoE2EE operates over either TCP or UDP. Over TCP, the transport provides ordering and delivery guarantees. Over UDP, the protocol imposes none: messages may be lost, reordered, or duplicated.

The replay window (Section 9.4) tolerates limited reordering, and the deterministic nonce derivation (Section 4.4) does not require in-order delivery. The fire-and-forget mode of the Process action (Section 5.3) is particularly suited to UDP, where avoiding a return trip can significantly reduce overhead for small payloads.

Applications that require reliable, ordered delivery SHOULD use TCP or provide their own reliability layer above GoE2EE.

9. Security Considerations

9.1. Server Authentication and Trust Model

The confidentiality of a GoE2EE session depends entirely on the client authenticating the server's public global key before trusting the handshake signature. If a client accepts an unauthenticated key -- notably one obtained through the Fetch Key action (Section 5.4) -- an active attacker can mount a man-in-the-middle attack, presenting its own key and relaying or reading all traffic. Deployments SHOULD use an authenticated retrieval strategy (Section 6).

9.2. Handshake Integrity

The server signs a transcript (Section 4.5) that includes both ephemeral public keys and the session identifier. This binds the signature to the specific key exchange and session, preventing a signature captured from one handshake from being replayed into another. The client MUST verify this signature and MUST abort on failure.

The protocol as specified does not authenticate the client to the server at the cryptographic layer; any client that can present a valid identifier and correctly encrypted messages will be served. Deployments that require client authentication MUST provide it at the application layer or by another mechanism.

9.3. Nonce Uniqueness

AES-GCM catastrophically fails if a (key, nonce) pair is ever reused: an attacker who observes two messages encrypted with the same key and nonce can recover the authentication subkey and forge messages [NIST.SP.800-38D]. GoE2EE relies on the strictly increasing per-secret counter and the direction octet (Section 4.4) to guarantee uniqueness. Implementations MUST ensure the counter never repeats or goes backwards for a given secret, including across pooled connections (Section 5.3.1), and MUST stop using a secret before the 64-bit counter would wrap.

9.4. Replay Protection

The server maintains, per secret, a sliding-window replay filter in the style of the IPsec anti-replay algorithm [RFC6479]. The window tracks the highest counter seen and a bitmap of the 64 counter values immediately below it. A message is accepted only if its counter has not been seen before and is not older than the window; otherwise the server rejects it with error code 0x05 (Replay detected). This bounds the reordering the server tolerates over unreliable transports while preventing an attacker from replaying captured Process requests.

Because replay state is per secret and outlives connections, an implementation that reuses a secret across connections shares one replay window for all of them, consistent with the shared counter requirement.

9.5. Forward Secrecy

Each handshake uses fresh ephemeral X25519 key pairs, so the compromise of a server's long-term global key does not by itself reveal the shared secrets of past sessions. However, reusing a shared secret across many connections (Section 7) enlarges the amount of data protected by a single key and the impact of that secret's compromise. Deployments SHOULD bound the lifetime and volume of data associated with any single secret and re-run the handshake periodically.

9.6. Denial of Service

Several fields are length-prefixed with sizes up to 64 bits. A malicious peer could advertise an enormous size to force large allocations. Implementations MUST enforce sane upper bounds on the sizes of public keys, signatures, and encrypted messages before allocating, and MUST reject messages that exceed those bounds as malformed. The server also holds per-secret state indexed by client-chosen identifiers; an implementation SHOULD bound the number of concurrent sessions and expire idle state to limit memory exhaustion.

9.7. Downgrade and Versioning

The version field (Table 1) allows future evolution. A server MUST reject unsupported versions (0x04). Because the version and action occupy a single unauthenticated header octet at the start of each request, deployments concerned with downgrade across versions SHOULD ensure that any future version that changes the cryptographic constructions also changes the HKDF info label so that keys are not shared across versions.

10. IANA Considerations

This document has no IANA actions.

The actions (Table 1), error codes (Table 2), hash types (Table 4), and key algorithms (Table 5) defined here are namespaces internal to the protocol and are not requested for registration in any IANA registry by this document. Should this protocol be standardized, the creation of IANA registries for these code points would be appropriate.

11. References

11.1. Normative References

[FIPS.180-4]
National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, , <https://csrc.nist.gov/pubs/fips/180-4/upd1/final>.
[FIPS.197]
National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, , <https://csrc.nist.gov/pubs/fips/197/final>.
[NIST.SP.800-38D]
Dworkin, M J. and NIST, "Recommendation for block cipher modes of operation :GaloisCounter Mode (GCM) and GMAC", NIST Special Publications (General) 800-38d, DOI 10.6028/NIST.SP.800-38d, , <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4122]
Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, , <https://www.rfc-editor.org/rfc/rfc4122>.
[RFC5116]
McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, , <https://www.rfc-editor.org/rfc/rfc5116>.
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5869]
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, , <https://www.rfc-editor.org/rfc/rfc5869>.
[RFC7748]
Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, , <https://www.rfc-editor.org/rfc/rfc7748>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

11.2. Informative References

[RFC4033]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, , <https://www.rfc-editor.org/rfc/rfc4033>.
[RFC6479]
Zhang, X. and T. Tsou, "IPsec Anti-Replay Algorithm without Bit Shifting", RFC 6479, DOI 10.17487/RFC6479, , <https://www.rfc-editor.org/rfc/rfc6479>.
[RFC8017]
Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, , <https://www.rfc-editor.org/rfc/rfc8017>.
[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8484]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, , <https://www.rfc-editor.org/rfc/rfc8484>.

Acknowledgements

The design of GoE2EE draws on the architecture of TLS 1.3 [RFC8446] and on established constructions for key derivation [RFC5869], authenticated encryption [NIST.SP.800-38D], and anti-replay [RFC6479].

Author's Address

Rafael Dantas Justo
Teamwork.com
Ireland