Separating Crypto Negotiation and Communication
draft-kuehlewind-crypto-sep-00

Document Type Active Internet-Draft (individual)
Last updated 2017-03-13
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      M. Kuehlewind
Internet-Draft                                                ETH Zurich
Intended status: Informational                            March 13, 2017
Expires: September 14, 2017

            Separating Crypto Negotiation and Communication
                     draft-kuehlewind-crypto-sep-00

Abstract

   Based on the increasing deployment of session resumption mechanisms
   where cryptographic context can be resumed to transmit application
   data with the first packet without delay for connection setup and
   negotiation, this draft proposes a split to separate connections used
   to set up encryption context and negotiate capabilities from
   connections used to transmit application data.  While cryptographic
   context and endpoint capabilities need to be be known before
   encrypted application data can be sent, there is otherwise no
   technical constraint that the crypto handshake has to be performed on
   the same transport connection.  This document discusses requirements
   on the cryptographic protocol to establish medium- to long-lived
   association that can be used by different transport protocols that
   implement different transport services.

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 http://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 September 14, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Kuehlewind             Expires September 14, 2017               [Page 1]
Internet-Draft              crypto separation                 March 2017

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Support for different transport services  . . . . . . . .   3
     2.2.  Cryptographic context lifetime management . . . . . . . .   3
   3.  Crypto-Transport Interface  . . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   New cryptographic and transport protocols increasingly rely on
   session resumption mechanisms where cryptographic context can be
   resumed to transmit application data with the first packet without
   delay for connection setup and negotiation.  This draft proposed a
   split to separate connections that are used to set up encryption
   context and negotiate capabilities from the connection that is used
   to transmit application data.  In this draft we assume the use of TCP
   with a TLS-like protocol for cryptographic handshake and negotiation
   of endpoint capabilities, where TCP provides a fully reliable stream-
   based transport and the message framing is realized by TLS.  However,
   instead of using the same transport TCP connection for TLS or any new
   TLS-like protocol, the connection will be closed after the
   cryptographic handshake and a new transport connection that might not
   use TCP is open at anytime to transmit the actual application data.

   In the case where there is no cryptographic context available when an
   application expressed the wish to transmit data to a certain
   endpoint, the connection for crypto negotiation must be established
   first, immediately before the actual payload connection will be used.
Show full document text