Skip to main content

Separating Crypto Negotiation and Communication

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Mirja Kühlewind , Tommy Pauly , Christopher A. Wood
Last updated 2019-01-01 (Latest revision 2018-06-30)
Replaces draft-kuehlewind-crypto-sep
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


Secure transport protocols often consist of three logically distinct components: transport, control (handshake), and record protection. Typically, such a protocol contains a single module that is responsible for all three functions. However, in many cases, this coupling is unnecessary. For example, while cryptographic context and endpoint capabilities need to be known before encrypted application data can be sent on a specific transport connection, there is otherwise no technical constraint that a cryptographic handshake must be performed on said connection. This document recommends a logical separation between transport, control, and record components of secure transport protocols. We compare existing protocols such as Transport Layer Security, QUIC, and IKEv2+ESP in the context of this logical separation.


Mirja Kühlewind
Tommy Pauly
Christopher A. Wood

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)