]> Teamwork.com

Ireland rafael@justo.net.br

Security Internet-Draft end-to-end encryption Diffie-Hellman AEAD 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. Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Transport Layer Security (TLS) 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 . GoE2EE is an application-layer protocol that provides similar cryptographic guarantees to TLS 1.3 but decouples two concerns that TLS binds tightly together: how peers agree on a shared secret and encrypt traffic; and 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.

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 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.

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.

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, ). 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 , and then computes the same shared secret. The full handshake is illustrated below.

| | (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 ======| | | ]]>

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 () directly.

| |<===== Process response: counter + encrypted ======| | | ]]>

The server MUST maintain the mapping from session identifier to shared secret (and the associated replay state, ) 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.

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

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

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 .

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: Action Name Section 0x1 Hello 0x2 Setup 0x3 Process 0x4 Fetch Key A server that receives a request whose version it does not support MUST reply with an error response () carrying error code 0x04 (Unsupported version).

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

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.

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:

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 .

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: 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 .

Cryptographic Constructions

Key Exchange The ephemeral key exchange uses ECDH with the X25519 function . Public keys are exchanged encoded as a SubjectPublicKeyInfo structure in PKIX, ASN.1 DER form (). 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.

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 with SHA-256 as follows:

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.

Authenticated Encryption Messages are protected with AES-256-GCM , an AEAD algorithm , 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.

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:

where the direction octet is: 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 ). Together these guarantee nonce uniqueness, which is required for the security of AES-GCM.

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:

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 (): RSA keys: RSASSA-PKCS1-v1_5 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 over the transcript. Note that for Ed25519 the hash type carried in the response () 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: 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.

Actions

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

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

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 (). Request:

id (16 octets):

A client-chosen identifier for the secret, formatted as a UUID . 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:

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 ().

signature-size (8 octets):

The length in octets of the signature.

signature (variable):

The signature over the handshake transcript (), 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.

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

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 ), used both to derive the nonce () and to detect replays ().

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):

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.

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 ), 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.

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 () is available. Request:

Response:

key-algorithm (1 octet):

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

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: Algorithm Description 0x1 RSA 0x2 ECDSA 0x3 Ed25519

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 . To protect the resolution path between the client and the recursive resolver, the client SHOULD use DNS over HTTPS .

Web PKI:

The client obtains an X.509 certificate 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 (). 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.

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 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.

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 () tolerates limited reordering, and the deterministic nonce derivation () does not require in-order delivery. The fire-and-forget mode of the Process action () 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.

Security Considerations

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 () -- 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 ().

Handshake Integrity The server signs a transcript () 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.

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 . GoE2EE relies on the strictly increasing per-secret counter and the direction octet () to guarantee uniqueness. Implementations MUST ensure the counter never repeats or goes backwards for a given secret, including across pooled connections (), and MUST stop using a secret before the 64-bit counter would wrap.

Replay Protection The server maintains, per secret, a sliding-window replay filter in the style of the IPsec anti-replay algorithm . 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.

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 () 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.

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.

Downgrade and Versioning The version field () 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.

IANA Considerations This document has no IANA actions. The actions (), error codes (), hash types (), and key algorithms () 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.

This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] National Institute of Standards and Technology

US Gaithersburg

National Institute of Standards and Technology National Institute of Standards and Technology 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 presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating Security Protocol (ESP). The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted. This document is not an Internet Standards Track specification; it is published for informational purposes. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. 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.

Acknowledgements The design of GoE2EE draws on the architecture of TLS 1.3 and on established constructions for key derivation , authenticated encryption , and anti-replay .