Separating Crypto Negotiation and Communication

Document Type Expired Internet-Draft (individual)
Authors Mirja K├╝hlewind  , Tommy Pauly  , Christopher Wood 
Last updated 2019-01-01 (latest revision 2018-06-30)
Replaces draft-kuehlewind-crypto-sep
Stream (None)
Intended RFC status (None)
Expired & archived
plain text htmlized pdfized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


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 Wood (

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