< draft-friel-tls-atls-02.txt   draft-friel-tls-atls-03.txt >
Network Working Group O. Friel Network Working Group O. Friel
Internet-Draft R. Barnes Internet-Draft R. Barnes
Intended status: Standards Track M. Pritikin Intended status: Standards Track M. Pritikin
Expires: September 12, 2019 Cisco Expires: January 9, 2020 Cisco
H. Tschofenig H. Tschofenig
ARM Limited Arm Ltd.
M. Baugher M. Baugher
Consultant Consultant
March 11, 2019 July 08, 2019
Application-Layer TLS Application-Layer TLS
draft-friel-tls-atls-02 draft-friel-tls-atls-03
Abstract Abstract
This document specifies how TLS sessions can be established at the This document specifies how TLS and DTLS can be used at the
application layer over untrusted transport between clients and application layer for the purpose of establishing secure end-to-end
services for the purposes of establishing secure end-to-end encrypted encrypted communication security.
communications channels. Transport layer encodings for application
layer TLS records are specified for HTTP and CoAP transport. Encodings for carrying TLS and DTLS payloads are specified for HTTP
Explicit identification of application layer TLS packets enables and CoAP to improve interoperability. While the use of TLS and DTLS
middleboxes to provide transport services and enforce suitable is straight forward we present multiple deployment scenarios to
transport policies for these payloads, without requiring access to illustrate the need for end-to-end application layer encryption and
the unencrypted payload content. Multiple scenarios are presented the benefits of reusing a widely deployed and readily available
identifying the need for end-to-end application layer encryption protocol. Application software architectures for building, and
between clients and services, and the benefits of reusing the well-
defined TLS protocol, and a standard TLS stack, to accomplish this
are described. Application software architectures for building, and
network architectures for deploying application layer TLS are network architectures for deploying application layer TLS are
outlined. outlined.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Application Layer End-to-End Security Use Cases . . . . . . . 4 3. Application Layer End-to-End Security Use Cases . . . . . . . 4
3.1. Bootstrapping Devices . . . . . . . . . . . . . . . . . . 4 3.1. Bootstrapping Devices . . . . . . . . . . . . . . . . . . 4
3.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 5 3.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 5
3.2.1. Constrained Device Connecting over a Closed Network . 5 4. ATLS Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Constrained Device Connecting over the Internet . . . 6 5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7
4. Current Approaches to Application Layer End-to-End Security . 7 5.1. Application Architecture . . . . . . . . . . . . . . . . 7
4.1. Noise . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Functional Design . . . . . . . . . . . . . . . . . . . . 13
4.2. Signal . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Network Architecture . . . . . . . . . . . . . . . . . . 15
4.3. Google ALTS . . . . . . . . . . . . . . . . . . . . . . . 7 6. ATLS Session Establishment . . . . . . . . . . . . . . . . . 16
4.4. Ephemeral Diffie-Hellman Over COSE . . . . . . . . . . . 8 7. ATLS over HTTP Transport . . . . . . . . . . . . . . . . . . 18
5. ATLS Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 18
6. Architecture Overview . . . . . . . . . . . . . . . . . . . . 8 7.2. Content-Type Header . . . . . . . . . . . . . . . . . . . 19
6.1. Application Architecture . . . . . . . . . . . . . . . . 8 7.3. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 19
6.1.1. Application Architecture Benefits . . . . . . . . . . 11 7.4. ATLS Session Tracking . . . . . . . . . . . . . . . . . . 19
6.1.2. ATLS Packet Identification . . . . . . . . . . . . . 12 7.5. Session Establishment and Key Exporting . . . . . . . . . 19
6.1.3. ATLS Session Tracking . . . . . . . . . . . . . . . . 12 7.6. Illustrative ATLS over HTTP Session Establishment . . . . 19
6.1.4. ATLS Record Inspection . . . . . . . . . . . . . . . 12 7.7. ATLS and HTTP CONNECT . . . . . . . . . . . . . . . . . . 20
6.1.5. Implementation . . . . . . . . . . . . . . . . . . . 12 8. ATLS over CoAP Transport . . . . . . . . . . . . . . . . . . 23
6.2. Functional Design . . . . . . . . . . . . . . . . . . . . 13 9. Key Exporting and Application Data Encryption . . . . . . . . 24
6.3. Network Architecture . . . . . . . . . . . . . . . . . . 14 9.1. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Key Exporting and Application Data Encryption . . . . . . . . 16 9.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. ATLS Session Establishment . . . . . . . . . . . . . . . . . 17 10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping . . . . . . 26
9. ATLS over HTTP Transport . . . . . . . . . . . . . . . . . . 19 11. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 20 11.1. The "oscore_connection_id" Extension . . . . . . . . . . 27
9.2. Content-Type Header . . . . . . . . . . . . . . . . . . . 20 11.2. The "cose_ext" Extension . . . . . . . . . . . . . . . . 27
9.3. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9.4. ATLS Session Tracking . . . . . . . . . . . . . . . . . . 20 12.1. "oscore_connection_id" TLS extension . . . . . . . . . . 28
9.5. Session Establishment and Key Exporting . . . . . . . . . 20 12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping . . . . 28
9.6. Illustrative ATLS over HTTP Session Establishment . . . . 21 12.3. .well-known URI Registry . . . . . . . . . . . . . . . . 29
9.7. ATLS and HTTP CONNECT . . . . . . . . . . . . . . . . . . 21 12.4. Media Types Registry . . . . . . . . . . . . . . . . . . 29
10. ATLS over CoAP Transport . . . . . . . . . . . . . . . . . . 24 12.5. HTTP Content-Formats Registry . . . . . . . . . . . . . 30
11. The "oscore_connection_id" Extension . . . . . . . . . . . . 25 12.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 30
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12.7. TLS Key Extractor Label . . . . . . . . . . . . . . . . 31
12.1. "oscore_connection_id" TLS extension . . . . . . . . . . 26 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12.2. .well-known URI Registry . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.3. Media Types Registry . . . . . . . . . . . . . . . . . . 27 14.1. Normative References . . . . . . . . . . . . . . . . . . 31
12.4. HTTP Content-Formats Registry . . . . . . . . . . . . . 28 14.2. Informative References . . . . . . . . . . . . . . . . . 33
12.5. CoAP Content-Formats Registry . . . . . . . . . . . . . 28 Appendix A. Pseudo Code . . . . . . . . . . . . . . . . . . . . 34
12.6. TLS Key Extractor Label . . . . . . . . . . . . . . . . 28 A.1. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 A.2. Java JSSE . . . . . . . . . . . . . . . . . . . . . . . . 36
14. Informative References . . . . . . . . . . . . . . . . . . . 29 Appendix B. Example ATLS Handshake . . . . . . . . . . . . . . . 38
Appendix A. Pseudo Code . . . . . . . . . . . . . . . . . . . . 31 Appendix C. Alternative Approaches to Application Layer End-to-
A.1. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 31 End Security . . . . . . . . . . . . . . . . . . . . 38
A.2. Java JSSE . . . . . . . . . . . . . . . . . . . . . . . . 33 C.1. Noise . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix B. Example ATLS Handshake . . . . . . . . . . . . . . . 35 C.2. Signal . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 C.3. Google ALTS . . . . . . . . . . . . . . . . . . . . . . . 39
C.4. Ephemeral Diffie-Hellman Over COSE (EDHOC) . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
There are multiple scenarios where there is a need for application There are multiple scenarios where there is a need for application
layer end-to-end security between clients and application services. layer end-to-end security between clients and application services.
Two examples include: Two examples include:
o Bootstrapping devices that must connect to HTTP application o Bootstrapping devices that must connect to HTTP application
services across untrusted TLS interception middleboxes services across untrusted TLS interception middleboxes
o Constrained devices connecting via gateways to application o Constrained devices connecting via gateways to application
services, where different transport layer protocols may be in use services, where different transport layer protocols may be in use
on either side of the gateway, with the gateway transcoding on either side of the gateway, with the gateway transcoding
between the different transport layer protocols. between the different transport layer protocols.
These two scenarios are described in more detail in Section 3. These two scenarios are described in more detail in Section 3.
This document describes how clients and applications can leverage This document describes how clients and applications can leverage
standard TLS software stacks to establish secure end-to-end encrypted standard TLS software stacks to establish secure end-to-end encrypted
connections at the application layer. The connections may establish connections at the application layer. TLS [RFC5246] [RFC8446] or
TLS [RFC5246] [I-D.ietf-tls-tls13] or DTLS [RFC6347] DTLS [RFC6347] [I-D.ietf-tls-dtls13] can be used and this document is
[I-D.ietf-tls-dtls13] sessions. There are multiple advantages to agnostic to the versions being used. There are multiple advantages
reuse of existing TLS software stacks for establishment of to reuse of existing TLS software stacks for establishment of
application layer secure connections. These include: application layer secure connections. These include:
o many clients and application services already include a TLS o many clients and application services already include a TLS
software stack, so there is no need to include yet another software stack, so there is no need to include yet another
software stack in the software build software stack in the software build
o no need to define a new cryptographic negotiation, authentication, o no need to define a new cryptographic negotiation, authentication,
and key exchange protocol between clients and services and key exchange protocol between clients and services
o provides standards based PKI mutual authentication between clients o provides standards based PKI mutual authentication between clients
skipping to change at page 4, line 17 skipping to change at page 4, line 20
o no need to train software developers on how to use a new o no need to train software developers on how to use a new
cryptographic protocols or libraries cryptographic protocols or libraries
o automatically benefit from new cipher suites by simply upgrading o automatically benefit from new cipher suites by simply upgrading
the TLS software stack the TLS software stack
o automatically benefit from new features, bugfixes, etc. in TLS o automatically benefit from new features, bugfixes, etc. in TLS
software stack upgrades software stack upgrades
This document also explicitly defines how application layer TLS When TLS or DTLS is used at the application layer we refer to it as
connections can be established using HTTP [RFC7230] [RFC7540] or CoAP Application-Layer TLS, or ATLS. There is, however, no difference to
as transport layers. This document does not preclude the use of TLS versions used over connection-oriented transports, such as TCP or
other transport layers. However, defining how application layer TLS SCTP. The same is true for DTLS. The difference is mainly in its
connections can be established over other transport layers, such as use and the requirements placed on the underlying transport.
[ZigBee] or [Bluetooth], is beyond the scope of this document.
Explicitly identifying application layer TLS packets enables This document defines how ATLS can be used over HTTP [RFC7230]
transport layer middleboxes to provide transport capabilities and [RFC7540] and over CoAP. This document does not preclude the use of
enforce suitable transport policies for these payloads, without other transports. However, defining how ATLS can be established over
requiring access to unencrypted application data. [ZigBee], [Bluetooth], etc. is beyond the scope of this document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Application layer TLS is referred to as ATLS throughout this Application-Layer TLS is referred to as ATLS throughout this
document. document.
3. Application Layer End-to-End Security Use Cases 3. Application Layer End-to-End Security Use Cases
This section describes in more detail the bootstrapping and This section describes describes a few end-to-end use cases in more
constrained device use cases mentioned in the introduction. detail.
3.1. Bootstrapping Devices 3.1. Bootstrapping Devices
There are far more classes of clients being deployed on today's There are far more classes of clients being deployed on today's
networks than at any time previously. This poses challenges for networks than at any time previously. This poses challenges for
network administrators who need to manage their network and the network administrators who need to manage their network and the
clients connecting to their network, and poses challenges for client clients connecting to their network, and poses challenges for client
vendors and client software developers who must ensure that their vendors and client software developers who must ensure that their
clients can connect to all required services. clients can connect to all required services.
skipping to change at page 5, line 44 skipping to change at page 5, line 46
across network domain boundaries. The purpose of this connection may across network domain boundaries. The purpose of this connection may
simply be to facilitate a bootstrapping process, for example simply be to facilitate a bootstrapping process, for example
[I-D.ietf-anima-bootstrapping-keyinfra], whereby the client securely [I-D.ietf-anima-bootstrapping-keyinfra], whereby the client securely
discovers the local domain certificate authorities required to discovers the local domain certificate authorities required to
establish a trusted network layer TLS connection to the middlebox. establish a trusted network layer TLS connection to the middlebox.
3.2. Constrained Devices 3.2. Constrained Devices
Two constrained device use cases are outlined here. Two constrained device use cases are outlined here.
3.2.1. Constrained Device Connecting over a Closed Network 3.2.1. Constrained Device Connecting over a Non-IP Network
There are industry examples of home smart lighting systems where the There are industry examples of smart lighting systems where
smart light bulbs connect using ZigBee to a gateway device. A luminaires are connected using ZigBee to a gateway. A server
controller application running on a mobile device connects to the connects to the gateway using CoAP over DTLS. The server can control
gateway using CoAP over DTLS. The controller can then control the the luminaires by sending messages and commands via the gateway. The
light bulbs by sending messages and commands via the gateway. The gateway has full access to all messages sent between the luminaires
gateway device has full access to all messages sent between the light and the server.
bulbs and the controller application.
A generic use case similar to the smart lighting system outlined A generic use case similar to the smart lighting system outlined
above has an IoT device talking ZigBee to a gateway, with the gateway above has an IoT device talking ZigBee, Bluetooth Low Energy,
in turn talking CoAP over DTLS to a controller application running on LoRaWAN, NB-IoT, etc. to a gateway, with the gateway in turn talking
a mobile device. This is illustrated in Figure 2. CoAP over DTLS or another protocol to a server located in the cloud
or on-premise. This is illustrated in Figure 2.
There are scenarios where the messages sent between the IoT device There are scenarios where certain messages sent between the IoT
and the controller application must not be exposed to the gateway device and the server must not be exposed to the gateway function.
function. Additionally, the end devices (the IoT device and the Additionally, the two endpoints may not have visibility to and no
controller application service) have no visibility to and no
guarantees about what transport layer security and encryption is guarantees about what transport layer security and encryption is
enforced across all hops end-to-end as they only have visibility to enforced across all hops end-to-end as they only have visibility to
their immediate next hop. ATLS addresses these concerns. their immediate next hop. ATLS addresses these concerns.
+--------+ ZigBee +---------+ CoAP/DTLS +------------+ +--------+ ZigBee +---------+ CoAP/DTLS +------------+
| Device |-------------->| Gateway |------------->| Mobile App | | Device |-------------->| Gateway |------------->| Server |
+--------+ +---------+ +------------+ +--------+ +---------+ +------------+
^ ^ ^ ^
| | | |
+--------Device to Mobile App ATLS Connection-------+ +-------- Device to Server -------+
Figure 2: IoT Closed Network Gateway Figure 2: IoT Closed Network Gateway
3.2.2. Constrained Device Connecting over the Internet 3.2.2. Constrained Device Connecting over IP
In this example an IoT device connecting to a gateway using a In this example an IoT device connecting to a gateway using a
suitable transport mechanism, such as ZigBee, CoAP, MQTT, etc. The suitable transport mechanism, such as ZigBee, CoAP, MQTT, etc. The
gateway function in turn talks HTTP over TLS (or, for example, HTTP gateway function in turn talks HTTP over TLS (or, for example, HTTP
over QUIC) to an application service over the Internet. This is over QUIC) to an application service over the Internet. This is
illustrated in Figure 3. illustrated in Figure 3.
The gateway may not be trusted and all messages between the IoT The gateway may not be trusted and all messages between the IoT
device and the application service must be end-to-end encrypted. device and the application service must be end-to-end encrypted.
Similar to the previous use case, the endpoints have no guarantees Similar to the previous use case, the endpoints have no guarantees
skipping to change at page 7, line 5 skipping to change at page 7, line 5
+--------+ CoAP/DTLS +------------------+ HTTP/TLS +---------+ +--------+ CoAP/DTLS +------------------+ HTTP/TLS +---------+
| Device |-------------->| Internet Gateway |------------>| Service | | Device |-------------->| Internet Gateway |------------>| Service |
+--------+ +------------------+ +---------+ +--------+ +------------------+ +---------+
^ ^ ^ ^
| | | |
+---------Device to Cloud Service ATLS Connection----------+ +---------Device to Cloud Service ATLS Connection----------+
Figure 3: IoT Internet Gateway Figure 3: IoT Internet Gateway
4. Current Approaches to Application Layer End-to-End Security 4. ATLS Goals
End-to-end security at the application layer is increasing seen as a
key requirement across multiple applications and services. Some
examples of end-to-end security mechanisms are outlined here. All
the solutions outlined here have some common characteristics. The
solutions:
o do not rely on transport layer security
o define a new handshake protocol for establishment of a secure end-
to-end session
4.1. Noise
[Noise] is a framework for cryptographic protocols based on Elliptic
Curve Diffie-Hellman (ECDH) key agreement, AEAD encryption, and
BLAKE2 and SHA2 hash functions. Noise is currently used by WhatsApp,
WireGuard, and Lightning.
The current Noise protocol framework defines mechanisms for proving
possession of a private key, but does not define authentication
mechanisms. Section 14 "Security Considerations" of Noise states:
~~~ it's up to the application to determine whether the remote
party's static public key is acceptable ~~~
4.2. Signal
The [Signal] protocol provides end-to-end encryption and uses EdDSA
signatures, Triple Diffie-Hellman handshake for shared secret
establishment, and the Double Ratchet Algorithm for key management.
It is used by Open Whisper Systems, WhatsApp and Google.
Similar to Noise, Signal does not define an authentication mechanism.
The current [X3DH] specification states in Section 4.1
"Authentication":
Methods for doing this are outside the scope of this document
4.3. Google ALTS
Google's Application Layer Transport Security [ALTS] is a mutual
authentication and transport encryption system used for securing
Remote Procedure Call (RPC) communications within Google's
infrastructure. ALTS uses an ECDH handshake protocol and a record
protocol containing AES encrypted payloads.
4.4. Ephemeral Diffie-Hellman Over COSE
There is ongoing work to standardise [I-D.selander-ace-cose-ecdhe],
whiich defines a SIGMA-I based authenticated key exchange protocol
using COSE and CBOR.
5. ATLS Goals
The high level goals driving the design of this mechanism are: The high level goals driving the design of this mechanism are:
o enable authenticated key exchange at the application layer by o enable authenticated key exchange at the application layer by
reusing existing technologies reusing existing technologies,
o ensure that ATLS packets are explicitly identified thus ensuring o ensure that ATLS packets are explicitly identified thus ensuring
that any middleboxes or gateways at the transport layer are that any middleboxes or gateways at the transport layer are
content aware content aware,
o leverage existing TLS stacks and handshake protocols thus avoiding o leverage TLS stacks and handshake protocols thus avoiding
introducing new software or protocol dependencies in clients and introducing new software or protocol dependencies in clients and
applications applications
o reuse existing TLS [RFC5246] [I-D.ietf-tls-tls13] and DTLS o reuse TLS [RFC5246] [RFC8446] and DTLS [RFC6347]
[RFC6347] [I-D.ietf-tls-dtls13] specifications as is without [I-D.ietf-tls-dtls13] specifications,
requiring any protocol changes or software stack changes
o do not mandate constraints on how the TLS stack is configured or o do not mandate constraints on how the TLS stack is configured or
used used,
o be forward compatible with future TLS versions
o avoid introducing TLS protocol handling logic or semantics into o be forward compatible with future TLS versions including new
the application layer, i.e. TLS protocol knowledge and logic is developments such as compact TLS [I-D.rescorla-tls-ctls], and
handled by the TLS stack, not the application
o ensure the client and server software implementations are as o ensure that the design is as simple as possible.
simple as possible
6. Architecture Overview 5. Architecture Overview
6.1. Application Architecture 5.1. Application Architecture
TLS software stacks allow application developers to 'unplug' the TLS software stacks allow application developers to 'unplug' the
default network socket transport layer and read and write TLS records default network socket transport layer and read and write TLS records
directly from byte buffers. This enables application developers to directly from byte buffers. This enables application developers to
create application layer TLS sessions, extract the raw TLS record use ATLS, extract the raw TLS record bytes from the bottom of the TLS
bytes from the bottom of the TLS stack, and transport these bytes stack, and transport these bytes over any suitable transport. The
over any suitable transport. The TLS software stacks can generate TLS software stacks can generate byte streams of full TLS flights,
byte streams of full TLS flights which may include multiple TLS which may include multiple TLS records. Additionally, TLS software
records. Additionally, TLS software stacks support Keying Material stacks support Keying Material Exporters [RFC5705] and allow
Exporters [RFC5705] and allow applications to export keying material applications to export keying material from established TLS sessions.
from established TLS sessions. This keying material can then be used This keying material can then be used by the application for
by the application for encryption of data outside the context of the encryption of data outside the context of the TLS session. This is
TLS session. This is illustrated in Figure 4 below. illustrated in Figure 4 below.
+------------+ +---------+ +------------+ +---------+
Handshake Records | | Handshake Records | | Handshake Records | | Handshake Records | |
------------------->| |------------------->| | ------------------->| |------------------->| |
| | | Byte | | | | Byte |
Unencrypted Data | TLS | Encrypted Data | | Unencrypted Data | TLS | Encrypted Data | |
------------------->| |------------------->| Buffers | ------------------->| |------------------->| Buffers |
| Software | | | | Software | | |
Encrypted Data | | Unencrypted Data | | Encrypted Data | | Unencrypted Data | |
------------------->| Stack |------------------->| | ------------------->| Stack |------------------->| |
skipping to change at page 11, line 33 skipping to change at page 10, line 33
Figure 6: TLS stack used for key agreement and exporting Figure 6: TLS stack used for key agreement and exporting
The choice of which application architecture to use will depend on The choice of which application architecture to use will depend on
the overall solution architecture, and the underlying transport layer the overall solution architecture, and the underlying transport layer
or layers in use. While the choice of application architecture is or layers in use. While the choice of application architecture is
outside the scope of this document, some considerations are outlined outside the scope of this document, some considerations are outlined
here. here.
o in some IoT use cases reducing the number of bytes transmitted is o in some IoT use cases reducing the number of bytes transmitted is
important. [I-D.mattsson-core-security-overhead] analyses the important. [I-D.mattsson-lwig-security-protocol-comparison]
overhead of TLS headers compared with OSCORE analyses the overhead of TLS headers compared with OSCORE
[I-D.ietf-core-object-security] illustrating the additional [I-D.ietf-core-object-security] illustrating the additional
overhead associated with TLS headers. The overhead varies between overhead associated with TLS headers. The overhead varies between
the different TLS versions and also between TLS and DTLS. It may the different TLS versions and also between TLS and DTLS. It may
be more appropriate to use the architecture defined in Figure 6 in be more appropriate to use the architecture defined in Figure 6 in
order to establish shared encryption keys, and then transport order to establish shared encryption keys, and then transport
encrypted data directly without the overhead of unwanted TLS encrypted data directly without the overhead of unwanted TLS
record headers. record headers.
o when using HTTP as a transport layer, it may be more appropriate o when using HTTP as a transport layer, it may be more appropriate
to use the architecture defined in Figure 6 in order to avoid any to use the architecture defined in Figure 6 in order to avoid any
TLS session vs. HTTP session affinity issues. TLS session vs. HTTP session affinity issues.
6.1.1. Application Architecture Benefits 5.1.1. Application Architecture Benefits
There are several benefits to using a standard TLS software stack to There are several benefits to using a standard TLS software stack to
establish an application layer secure communications channel between establish an application layer secure communications channel between
a client and a service. These include: a client and a service. These include:
o no need to define a new cryptographic negotiation and exchange o no need to define a new cryptographic negotiation and exchange
protocol between client and service protocol between client and service
o automatically benefit from new cipher suites by simply upgrading o automatically benefit from new cipher suites by simply upgrading
the TLS software stack the TLS software stack
o automatically benefit from new features, bugfixes, etc. in TLS o automatically benefit from new features, bugfixes, etc. in TLS
software stack upgrades software stack upgrades
6.1.2. ATLS Packet Identification 5.1.2. ATLS Packet Identification
It is recommended that ATLS packets are explicitly identified by a It is recommended that ATLS packets are explicitly identified by a
standardized, transport-specific identifier enabling any gateways and standardized, transport-specific identifier enabling any gateways and
middleboxes to identify ATLS packets. Middleboxes have to contend middleboxes to identify ATLS packets. Middleboxes have to contend
with a vast number of applications and network operators have with a vast number of applications and network operators have
difficulty configuring middleboxes to distinguish unencrypted but not difficulty configuring middleboxes to distinguish unencrypted but not
explicitly identified application data from end-to-end encrypted explicitly identified application data from end-to-end encrypted
data. This specification aims to assist network operators by data. This specification aims to assist network operators by
explicitly identifying ATLS packets. The HTTP and CoAP encodings explicitly identifying ATLS packets. The HTTP and CoAP encodings
documented in Section 9 and Section 10 explicitly identify ATLS documented in Section 7 and Section 8 explicitly identify ATLS
packets. packets.
6.1.3. ATLS Session Tracking 5.1.3. ATLS Session Tracking
The ATLS application service establishes multiple ATLS sessions with The ATLS application service establishes multiple ATLS sessions with
multiple clients. As TLS sessions are stateful, the application multiple clients. As TLS sessions are stateful, the application
service must be able to correlate ATLS records from different clients service must be able to correlate ATLS records from different clients
across the relevant ATLS sessions. The details of how session across the relevant ATLS sessions. The details of how session
tracking is implemented are outside the scope of this document. tracking is implemented are outside the scope of this document.
Recommendations are given in Section 9 and Section 10, but session Recommendations are given in Section 7 and Section 8, but session
tracking is application and implementation specific. tracking is application and implementation specific.
6.1.4. ATLS Record Inspection 5.1.4. ATLS Record Inspection
It should not be necessary for the application layer to have to No constraints are placed on the ContentType contained within the
inspect, parse or understand the contents of ATLS records. No
constraints are placed on the ContentType contained within the
transported TLS records. The TLS records may contain handshake, transported TLS records. The TLS records may contain handshake,
application_data, alert or change_cipher_spec messages. If new application_data, alert or change_cipher_spec messages. If new
ContentType messages are defined in future TLS versions, these may ContentType messages are defined in future TLS versions, these may
also be transported using this protocol. also be transported using this protocol.
6.1.5. Implementation 5.1.5. ATLS Message Routing
In many cases ATLS message routing is trival. However, there are
potentially cases where the middlebox topology is quite complex and
an example is shown in Figure 7. In this scenario multiple devices
(Client 1-3) are connected using serial communication to a gateway
(referred as middlebox A). Middlebox A communicates with another
middlebox B over UDP/IP. Middlebox B then interacts with some
servers in the backend using CoAP over TCP.
This scenario raises the question about the ATLS message routing. In
particular, there are two questions:
o How do the middleboxes know to which IP address to address the
ATLS packet? This question arises in scenarios where clients are
communicating over non-IP transports.
o How are response messages demultiplexed?
In some scenarios it is feasible to pre-configure the destination IP
address of outgoing packets. Another other scenarios extra
information available in the ATLS message or in a shim layer has to
provide the necessary information. In the case of ATLS the use of
the Server Name Indicating (SNI) parameter in the TLS/DTLS
ClientHello message is a possibility to give middleboxes enough
information to determine the ATLS communication endpoint. This
approach is also compatible with SNI encryption.
For demultiplexing again different approaches are possible. The
simplest approach is to use separate source ports for each ATLS
session. In our example, Middlebox A allocates a dedicated socket
(with a separate source port) for outgoing UDP datagrams in order to
be able to relay a response message to the respective client.
Alternatively, it is possible to make use of a shim layer on top of
the transport that provides this extra demultiplexing capabilities.
The use of multiple UDP "sessions" (as well as different TCP
sessions) has the advantage of avoiding head-of-line blocking.
+---------+ +---------+
| Server 1|----+-----| Server 2|
+---------+ | +---------+
|
|CoAP
|over
|TCP/TLS
|
+-----+-----+
|Middlebox B|
+-----------+
|
|
|CoAP
|over
|UDP/DTLS
|
+-----------+
+---------|Middlebox A|-----------+
| +-----------+ |
| | |
|CoAP |CoAP |CoAP
|over |over |over
|Serial |Serial |Serial
| | |
+--------+ +--------+ +--------+
|Client 1| |Client 2| |Client 3|
+--------+ +--------+ +--------+
Figure 7: Message Routing Scenario
5.1.6. Implementation
Pseudo code illustrating how to read and write TLS records directly Pseudo code illustrating how to read and write TLS records directly
from byte buffers using both OpenSSL BIO functions and Java JSSE from byte buffers using both OpenSSL BIO functions and Java JSSE
SSLEngine is given in the appendices. A blog post by [Norrell] SSLEngine is given in the appendices. A blog post by [Norrell]
outlines a similar approach to leveraging OpenSSL BIO functions, and outlines a similar approach to leveraging OpenSSL BIO functions, and
Oracle publish example code for leveraging [SSLEngine]. Oracle publish example code for leveraging [SSLEngine].
6.2. Functional Design 5.2. Functional Design
The functional design assumes that an authorization system has The functional design assumes that an authorization system has
established operational keys for authenticating endpoints. In a established operational keys for authenticating endpoints. In a
layered design, this needs to be done for each layer, which may layered design, this needs to be done for each layer, which may
operate in two separate authorization domains. Note that Figure 7 operate in two separate authorization domains. Note that Figure 8
shows a generic setup where TLS/DTLS is used at two layers. In some shows a generic setup where TLS/DTLS is used at two layers. In some
cases, use of TLS/DTLS at the application layer may be sufficient cases, use of TLS/DTLS at the application layer may be sufficient
where lower layer security mechanisms provide protection of the where lower layer security mechanisms provide protection of the
transport-specific headers. transport-specific headers.
+-------------------------------------------------------+ +-------------------------------------------------------+
| +---+ +---+ | | +---+ +---+ |
| +--------+ |APP| |APP| +--------+ | | +--------+ |APP| |APP| +--------+ |
| |security| +---+ +---+ |security| | | |security| +---+ +---+ |security| |
| |--------+ ^ ^ |--------+ | | |--------+ ^ ^ |--------+ |
skipping to change at page 13, line 45 skipping to change at page 14, line 34
| | TLS- |<--------->| TLS- | | | | TLS- |<--------->| TLS- | |
| +--------+ |SERVER| LAYER |CLIENT| +--------+ | | +--------+ |SERVER| LAYER |CLIENT| +--------+ |
| |security| +------+ +------+ |security| | | |security| +------+ +------+ |security| |
| |--------+ ^ ^ |--------+ | | |--------+ ^ ^ |--------+ |
| |policies| | | |policies| | | |policies| | | |policies| |
| |LAYER 1 +-----+ +-----+LAYER 1 | | | |LAYER 1 +-----+ +-----+LAYER 1 | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
Figure 7: Functional Design Figure 8: Functional Design
The security policies of one layer are distinct from those of another The security policies of one layer are distinct from those of another
in Figure 7. They may overlap, but that is not necessary or perhaps in Figure 8. They may overlap, but that is not necessary or perhaps
even likely since the key exchanges at the different layers terminate even likely since the key exchanges at the different layers terminate
at different endpoints and the two often have different authorization at different endpoints and the two often have different authorization
domains. domains.
TLS can protect IoT device-to-gateway communications "on the wire" TLS can protect IoT device-to-gateway communications "on the wire"
using the "bottom layer" of Figure 7, and it can protect application using the "bottom layer" of Figure 8, and it can protect application
data from the device to the application server using the "top layer." data from the device to the application server using the "top layer."
Application and transport security each have a role to play. Application and transport security each have a role to play.
Transport security restricts access to messages on the networks, Transport security restricts access to messages on the networks,
notably application headers and application-layer TLS restricts notably application headers and application-layer TLS restricts
access to the application payloads. access to the application payloads.
As shown in Figure 7, an application-layer message, which gets As shown in Figure 8, an application-layer message, which gets
encrypted and integrity protected and, in the generic case, the the encrypted and integrity protected and, in the generic case, the the
resulting TLS message and headers are passed to a TLS socket at the resulting TLS message and headers are passed to a TLS socket at the
bottom layer, which may have a different security policy than the bottom layer, which may have a different security policy than the
application layer. application layer.
6.3. Network Architecture 5.3. Network Architecture
An example network deployment is illustrated in Figure 8. It shows a An example network deployment is illustrated in Figure 9. It shows a
constrained client connecting to an application service via an constrained client connecting to an application service via an
internet gateway. The client uses CoAP over DTLS to communicate with internet gateway. The client uses CoAP over DTLS to communicate with
the gateway. The gateway extracts the messages the client sent over the gateway. The gateway extracts the messages the client sent over
CoAP and sends these messages inside HTTP message bodies to the CoAP and sends these messages inside HTTP message bodies to the
application service. It also shows a TLS terminator deployed in application service. It also shows a TLS terminator deployed in
front of the application service. The client establishes a transport front of the application service. The client establishes a transport
layer CoAP/DTLS connection with the gateway (C->G DTLS), the gateway layer CoAP/DTLS connection with the gateway (C->G DTLS), the gateway
in turn opens a transport layer TLS connection with the TLS in turn opens a transport layer TLS connection with the TLS
terminator deployed in front of the service (G->T TLS). The client terminator deployed in front of the service (G->T TLS). The client
can ignore any certificate validation errors when it connects to the can ignore any certificate validation errors when it connects to the
skipping to change at page 15, line 24 skipping to change at page 15, line 46
| UDP | | TCP | | TCP | | UDP | | TCP | | TCP |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
+--------+ +-----------+ +----------------+ +---------+ +--------+ +-----------+ +----------------+ +---------+
| Client |----->| Gateway |----->| TLS Terminator |---->| Service | | Client |----->| Gateway |----->| TLS Terminator |---->| Service |
+--------+ +-----------+ +----------------+ +---------+ +--------+ +-----------+ +----------------+ +---------+
^ ^ ^ ^
| | | |
+-------------Client to Service ATLS Connection-------------+ +-------------Client to Service ATLS Connection-------------+
Figure 8: Constrained Device Gateway Network Architecture Figure 9: Constrained Device Gateway Network Architecture
Another typical network deployment is illustrated in Figure 9. It Another typical network deployment is illustrated in Figure 10. It
shows a client connecting to a service via a middlebox. It also shows a client connecting to a service via a middlebox. It also
shows a TLS terminator deployed in front of the service. The client shows a TLS terminator deployed in front of the service. The client
establishes a transport layer TLS connection with the middlebox (C->M establishes a transport layer TLS connection with the middlebox (C->M
TLS), the middlebox in turn opens a transport layer TLS connection TLS), the middlebox in turn opens a transport layer TLS connection
with the TLS terminator deployed in front of the service (M->T TLS). with the TLS terminator deployed in front of the service (M->T TLS).
The client can ignore any certificate validation errors when it The client can ignore any certificate validation errors when it
connects to the middlebox. HTTP messages are transported over this connects to the middlebox. HTTP messages are transported over this
layer between the client and the service. Finally, application layer layer between the client and the service. Finally, application layer
TLS messages are exchanged inside the HTTP message bodies in order to TLS messages are exchanged inside the HTTP message bodies in order to
establish an end-to-end TLS session between the client and the establish an end-to-end TLS session between the client and the
skipping to change at page 16, line 24 skipping to change at page 16, line 32
| TCP | | TCP | | TCP | | TCP | | TCP | | TCP |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
+--------+ +-----------+ +----------------+ +---------+ +--------+ +-----------+ +----------------+ +---------+
| Client |----->| Middlebox |----->| TLS Terminator |---->| Service | | Client |----->| Middlebox |----->| TLS Terminator |---->| Service |
+--------+ +-----------+ +----------------+ +---------+ +--------+ +-----------+ +----------------+ +---------+
^ ^ ^ ^
| | | |
+-------------Client to Service ATLS Connection-------------+ +-------------Client to Service ATLS Connection-------------+
Figure 9: HTTP Middlebox Network Architecture Figure 10: HTTP Middlebox Network Architecture
7. Key Exporting and Application Data Encryption
When solutions implement the architecture described in Figure 6, they
leverage [RFC5705] for exporting keys. When the OSCORE mode has been
agreed using the "oscore_connection_id" extension defined in this
document, different keys are used for ordinary DTLS/TLS record
protection and OSCORE packet protection. These keys are produced
using a TLS exporter [RFC5705] and the exporter takes three input
values:
o a disambiguating label string,
o a per-association context value provided by the application using
the exporter, and
o a length value.
The label string for use with this specification is defined as
'application-layer-tls'. The per-association context value is empty.
The length value is twice the size of the key size utilized by the
negotiated algorithm since the lower-half is used for the Master
Secret and the upper-half is used for the Master Salt.
For example, if a TLS/DTLS 1.2 handshake negotiated the
TLS_PSK_WITH_AES_128_CCM_8 ciphersuite then the key size utilized by
the negotiated algorithm, i.e. AES 128, is 128 bit. Hence, the key
extractor is requested to produce 2 x 128 bit keying material.
The following parameters are needed for use with OSCORE:
o Master Secret: The master secret is described as described above.
o Sender ID: This values is negotiated using the
"oscore_connection_id" extension, as described in Section 11.
o Recipient ID: This values is negotiated using the
"oscore_connection_id" extension, as described in Section 11.
o AEAD Algorithm: This value is negotiated using the ciphersuite
exchange provided by the TLS/DTLS handshake. For example, if a
TLS/DTLS 1.2 handshake negotiated the TLS_PSK_WITH_AES_128_CCM_8
ciphersuite then AEAD algorithm identifier is AES_128_CCM_8, which
corresponds to COSE algorithms AES-CCM-64-64-128 or AES-CCM-
16-64-128, whereby the former uses a 7-byte nonce and the later
13-byte nonce. Since in TLS/DTLS the nonce value is not
negotiated but rather fixed, a 7-byte nonce value is assumed as a
default in this document.
o Master Salt: The master salt is described as described above.
o HKDF Algorithm: This value is negotiated using the ciphersuite
exchange provided by the TLS/DTLS handshake. As a default,
SHA-256 is assumed as a HKDF algorithm.
o Replay Window: A default window size of 32 packets is assumed.
A future version of this specification will describe how to establish
keying material and parameters for security contexts other than
OSCORE.
8. ATLS Session Establishment 6. ATLS Session Establishment
Figure 10 illustrates how an ATLS session is established using the Figure 11 illustrates how an ATLS session is established using the
key exporting architectural model shown in Figure 6. The number of key exporting architectural model shown in Figure 6. The number of
RTTs that take place when establishing a TLS session depends on the RTTs that take place when establishing a TLS session depends on the
version of TLS and what capabilities are enabled on the TLS software version of TLS and what capabilities are enabled on the TLS software
stack. For example, a 0-RTT exchange is possible with TLS 1.3. If stack. For example, a 0-RTT exchange is possible with TLS 1.3. If
applications wish to ensure a predictable number of RTTs when applications wish to ensure a predictable number of RTTs when
establishing an application layer TLS connection, this may be establishing an application layer TLS connection, this may be
achieved by configuring the TLS software stack appropriately. achieved by configuring the TLS software stack appropriately.
The outline is as follows: The outline is as follows:
skipping to change at page 19, line 38 skipping to change at page 18, line 34
| | | | | Records | | | | | | Records |
2 |<---------|<--------|<------------|<---------|<---------| 2 |<---------|<--------|<------------|<---------|<---------|
| Session | | | | | | Session | | | | |
| | Up | | | | | | | Up | | | | |
+ |--------->| | | | | + |--------->| | | | |
| Export | | | | Export | | Export | | | | Export |
| Keys | | | | Keys | | Keys | | | | Keys |
|--------->| | E2E Session | |<---------| |--------->| | E2E Session | |<---------|
| |<--------|-------------|--------->| | | |<--------|-------------|--------->| |
Figure 10: ATLS Session Establishment Figure 11: ATLS Session Establishment
9. ATLS over HTTP Transport 7. ATLS over HTTP Transport
The assumption is that the client will establish a transport layer The assumption is that the client will establish a transport layer
connection to the server for exchange of HTTP messages. The connection to the server for exchange of HTTP messages. The
underlying transport layer connection could be over TCP or TLS. The underlying transport layer connection could be over TCP or TLS. The
client will then establish an application layer TLS connection with client will then establish an application layer TLS connection with
the server by exchanging TLS records with the server inside HTTP the server by exchanging TLS records with the server inside HTTP
message request and response bodies. message request and response bodies.
9.1. Protocol Summary 7.1. Protocol Summary
All ATLS records are transported unmodified as binary data within All ATLS records are transported unmodified as binary data within
HTTP message bodies. The application simply extracts the TLS records HTTP message bodies. The application simply extracts the TLS records
from the TLS stack and inserts them directly into HTTP message from the TLS stack and inserts them directly into HTTP message
bodies. Each message body contains a full TLS flight, which may bodies. Each message body contains a full TLS flight, which may
contain multiple TLS records. contain multiple TLS records.
The client sends all ATLS records to the server in the bodies of POST The client sends all ATLS records to the server in the bodies of POST
requests. requests.
The server sends all ATLS records to the client in the bodies of 200 The server sends all ATLS records to the client in the bodies of 200
OK responses to the POST requests. OK responses to the POST requests.
The URI path used by ATLS is "/.well-known/atls". The URI path used by ATLS is "/.well-known/atls".
9.2. Content-Type Header 7.2. Content-Type Header
A new Content-Type header value is defined: A new Content-Type header value is defined:
Content-type: application/atls Content-type: application/atls
All message bodies containing ATLS records must set this Content- All message bodies containing ATLS records must set this Content-
Type. This enables middleboxes to readily identify ATLS payloads. Type. This enables middleboxes to readily identify ATLS payloads.
9.3. HTTP Status Codes 7.3. HTTP Status Codes
This document does not define any new HTTP status codes, and does not This document does not define any new HTTP status codes, and does not
specify additional semantics or refine existing semantics for status specify additional semantics or refine existing semantics for status
codes. This is the best current practice as outlined in codes. This is the best current practice as outlined in
[I-D.ietf-httpbis-bcp56bis]. [I-D.ietf-httpbis-bcp56bis].
9.4. ATLS Session Tracking 7.4. ATLS Session Tracking
The application service needs to track multiple client application The application service needs to track multiple client application
layer TLS sessions so that it can correlate TLS records received in layer TLS sessions so that it can correlate TLS records received in
HTTP message bodies with the appropriate TLS session. The HTTP message bodies with the appropriate TLS session. The
application service should use stateful cookies [RFC6265] in order to application service should use stateful cookies [RFC6265] in order to
achieve this as recommended in [I-D.ietf-httpbis-bcp56bis]. achieve this as recommended in [I-D.ietf-httpbis-bcp56bis].
9.5. Session Establishment and Key Exporting 7.5. Session Establishment and Key Exporting
It is recommended that applications using ATLS over HTTP transport It is recommended that applications using ATLS over HTTP transport
only use ATLS for session establishment and key exchange, resulting only use ATLS for session establishment and key exchange, resulting
in only 2 ATLS RTTs between the client and the application service. in only 2 ATLS RTTs between the client and the application service.
Key exporting must be carried out as described in Section 7. Key exporting must be carried out as described in Section 9.
9.6. Illustrative ATLS over HTTP Session Establishment 7.6. Illustrative ATLS over HTTP Session Establishment
A client initiates an ATLS session by sending the first TLS flight in A client initiates an ATLS session by sending the first TLS flight in
a POST request message body to the ATLS server. a POST request message body to the ATLS server.
POST /.well-known/atls POST /.well-known/atls
Content-Type: application/atls Content-Type: application/atls
<binary TLS client flight 1 records> <binary TLS client flight 1 records>
The server handles the request, creates an ATLS session object, and The server handles the request, creates an ATLS session object, and
skipping to change at page 21, line 42 skipping to change at page 20, line 37
<binary TLS client flight 2 records> <binary TLS client flight 2 records>
The server handles the second flight, establishes the ATLS session, The server handles the second flight, establishes the ATLS session,
and replies with its second flight. and replies with its second flight.
200 OK 200 OK
Content-Type: application/atls Content-Type: application/atls
<binary TLS server flight 2 records> <binary TLS server flight 2 records>
9.7. ATLS and HTTP CONNECT 7.7. ATLS and HTTP CONNECT
It is worthwhile comparing and contrasting ATLS with HTTP CONNECT It is worthwhile comparing and contrasting ATLS with HTTP CONNECT
tunneling. tunneling.
First, let us introduce some terminology: First, let us introduce some terminology:
o HTTP Proxy: A HTTP Proxy operates at the application layer, o HTTP Proxy: A HTTP Proxy operates at the application layer,
handles HTTP CONNECT messages from clients, and opens tunnels to handles HTTP CONNECT messages from clients, and opens tunnels to
remote origin servers on behalf of clients. If a client remote origin servers on behalf of clients. If a client
establishes a tunneled TLS connection to the origin server, the establishes a tunneled TLS connection to the origin server, the
skipping to change at page 22, line 22 skipping to change at page 21, line 17
Certificate Authority is installed in the client's trust store. Certificate Authority is installed in the client's trust store.
HTTP Proxies and middleboxes are logically separate entities and one HTTP Proxies and middleboxes are logically separate entities and one
or both of these may be deployed in a network. or both of these may be deployed in a network.
HTTP CONNECT is used by clients to instruct a HTTP Forward Proxy HTTP CONNECT is used by clients to instruct a HTTP Forward Proxy
deployed in the local domain to open up a tunnel to a remote origin deployed in the local domain to open up a tunnel to a remote origin
server that is typically deployed in a different domain. Assuming server that is typically deployed in a different domain. Assuming
that TLS transport is used between both client and proxy, and proxy that TLS transport is used between both client and proxy, and proxy
and origin server, the network architecture is as illustrated in and origin server, the network architecture is as illustrated in
Figure 11. Once the proxy opens the transport tunnel to the service, Figure 12. Once the proxy opens the transport tunnel to the service,
the client establishes an end-to-end TLS session with the service, the client establishes an end-to-end TLS session with the service,
and the proxy is blindly transporting TLS records (the C->S TLS and the proxy is blindly transporting TLS records (the C->S TLS
session records) between the client and the service. From the client session records) between the client and the service. From the client
perspective, it is tunneling a TLS session to the service inside the perspective, it is tunneling a TLS session to the service inside the
TLS session it has established to the proxy (the C->P TLS session). TLS session it has established to the proxy (the C->P TLS session).
No middlebox is attempting to intercept or inspect the HTTP messages No middlebox is attempting to intercept or inspect the HTTP messages
between the client and the service. between the client and the service.
+----------+ +----------+ +----------+ +----------+
| C->S HTTP| | C->S HTTP| | C->S HTTP| | C->S HTTP|
skipping to change at page 22, line 45 skipping to change at page 21, line 40
+----------+ +----------+ +----------+ +----------+
| C->P TLS | | P->S TCP | | C->P TLS | | P->S TCP |
+----------+ +----------+ +----------+ +----------+
| C->P TCP | | C->P TCP |
+----------+ +----------+
+--------+ +------------+ +---------+ +--------+ +------------+ +---------+
| Client |----->| HTTP Proxy |----->| Service | | Client |----->| HTTP Proxy |----->| Service |
+--------+ +------------+ +---------+ +--------+ +------------+ +---------+
Figure 11: HTTP Proxy transport layers Figure 12: HTTP Proxy transport layers
A more complex network topology where the network operator has both a A more complex network topology where the network operator has both a
HTTP Proxy and a middlebox deployed is illustrated in Figure 12. In HTTP Proxy and a middlebox deployed is illustrated in Figure 13. In
this scenario, the proxy has tunneled the TLS session from the client this scenario, the proxy has tunneled the TLS session from the client
towards the origin server, however the middlebox is intercepting and towards the origin server, however the middlebox is intercepting and
terminating this TLS session. A TLS session is established between terminating this TLS session. A TLS session is established between
the client and the middlebox (C->M TLS), and not end-to-end between the client and the middlebox (C->M TLS), and not end-to-end between
the client and the server. It can clearly be seen that HTTP CONNECT the client and the server. It can clearly be seen that HTTP CONNECT
and HTTP Proxies serve completely different functions than and HTTP Proxies serve completely different functions than
middleboxes. middleboxes.
Additionally, the fact that the TLS session is established between Additionally, the fact that the TLS session is established between
the client and the middlebox can be problematic for two reasons: the client and the middlebox can be problematic for two reasons:
skipping to change at page 23, line 34 skipping to change at page 22, line 30
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| C->P TLS | | P->M TCP | | M->S TCP | | C->P TLS | | P->M TCP | | M->S TCP |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| C->P TCP | | C->P TCP |
+----------+ +----------+
+--------+ +------------+ +-----------+ +---------+ +--------+ +------------+ +-----------+ +---------+
| Client |----->| HTTP Proxy |----->| Middlebox |----->| Service | | Client |----->| HTTP Proxy |----->| Middlebox |----->| Service |
+--------+ +------------+ +-----------+ +---------+ +--------+ +------------+ +-----------+ +---------+
Figure 12: HTTP Proxy and middlebox transport layers Figure 13: HTTP Proxy and middlebox transport layers
As HTTP CONNECT can be used to establish a tunneled TLS connection, As HTTP CONNECT can be used to establish a tunneled TLS connection,
one hypothetical solution to this middlebox issue is for the client one hypothetical solution to this middlebox issue is for the client
to issue a HTTP CONNECT command to a HTTP Reverse Proxy deployed in to issue a HTTP CONNECT command to a HTTP Reverse Proxy deployed in
front of the origin server. This solution is not practical for front of the origin server. This solution is not practical for
several reasons: several reasons:
o if there is a local domain HTTP Forward Proxy deployed, this would o if there is a local domain HTTP Forward Proxy deployed, this would
result in the client doing a first HTTP CONNECT to get past the result in the client doing a first HTTP CONNECT to get past the
Forward Proxy, and then a second HTTP CONNECT to get past the Forward Proxy, and then a second HTTP CONNECT to get past the
skipping to change at page 24, line 40 skipping to change at page 23, line 38
It is also worth noting that if HTTP CONNECT to a Reverse Proxy were It is also worth noting that if HTTP CONNECT to a Reverse Proxy were
a conceptually sound solution, the solution still ultimately results a conceptually sound solution, the solution still ultimately results
in encrypted traffic traversing the middlebox that the middlebox in encrypted traffic traversing the middlebox that the middlebox
cannot intercept and inspect. That is ultimately what ATLS results cannot intercept and inspect. That is ultimately what ATLS results
in - traffic traversing the middle box that the middlebox cannot in - traffic traversing the middle box that the middlebox cannot
intercept and inspect. Therefore, from a middlebox perspective, the intercept and inspect. Therefore, from a middlebox perspective, the
differences between the two solutions are in the areas of solution differences between the two solutions are in the areas of solution
complexity and protocol semantics. It is clear that ATLS is a complexity and protocol semantics. It is clear that ATLS is a
simpler, more elegant solution that HTTP CONNECT. simpler, more elegant solution that HTTP CONNECT.
10. ATLS over CoAP Transport 8. ATLS over CoAP Transport
To carry TLS messages over CoAP it is recommended to use Confirmable To carry TLS messages over CoAP [RFC7252] it is recommended to use
messages while DTLS payloads may as well use non-confirmable Confirmable messages while DTLS payloads may as well use non-
messages. The exchange pattern in CoAP uses the following style: A confirmable messages. The exchange pattern in CoAP uses the
request from the CoAP client to the CoAP server uses a POST with the following style: A request from the CoAP client to the CoAP server
ATLS message contained in the payload of the request. An ATLS uses a POST with the ATLS message contained in the payload of the
response is returned by the CoAP server to the CoAP client in a 2.04 request. An ATLS response is returned by the CoAP server to the CoAP
(Changed) message. client in a 2.04 (Changed) message.
When DTLS messages are conveyed in CoAP over UDP then the DDoS When DTLS messages are conveyed in CoAP over UDP then the DDoS
protection offered by DTLS MAY be used instead of replicating the protection offered by DTLS MAY be used instead of replicating the
functionality at the CoAP layer. If TLS is conveyed in CoAP over UDP functionality at the CoAP layer. If TLS is conveyed in CoAP over UDP
then DDoS protection by CoAP has to be utilized. Carrying ATLS then DDoS protection by CoAP has to be utilized. Carrying ATLS
messages in CoAP over TCP does not require any additional DDoS messages in CoAP over TCP does not require any additional DDoS
protection. protection.
The URI path used by ATLS is "/.well-known/atls". The URI path used by ATLS is "/.well-known/atls".
skipping to change at page 25, line 35 skipping to change at page 24, line 34
+--------->| Header: POST (Code=0.02) +--------->| Header: POST (Code=0.02)
| POST | Uri-Path: "/.well-known/atls" | POST | Uri-Path: "/.well-known/atls"
| | Content-Format: application/atls | | Content-Format: application/atls
| | Payload: ATLS ({Certificate*}, | | Payload: ATLS ({Certificate*},
| | {CertificateVerify*}, {Finished}) | | {CertificateVerify*}, {Finished})
| | | |
|<---------+ Header: 2.04 Changed |<---------+ Header: 2.04 Changed
| 2.04 | | 2.04 |
| | | |
Figure 13: Transferring ATLS in CoAP Figure 14: Transferring ATLS in CoAP
Note that application data can already be sent by the server in the Note that application data can already be sent by the server in the
second message and by the client in the third message, in case of the second message and by the client in the third message, in case of the
full TLS 1.3 handshake. In case of the 0-RTT handshake application full TLS 1.3 handshake. In case of the 0-RTT handshake application
data can be sent earlier. To mix different media types in the same data can be sent earlier. To mix different media types in the same
CoAP payload the application/multipart-core content type is used. CoAP payload the application/multipart-core content type is used.
Note also that CoAP blockwise transfer MAY be used if the payload Note also that CoAP blockwise transfer MAY be used if the payload
size, for example due to the size of the certificate chain, exceeds size, for example due to the size of the certificate chain, exceeds
the MTU size. the MTU size.
11. The "oscore_connection_id" Extension 9. Key Exporting and Application Data Encryption
When solutions implement the architecture described in Figure 6, they
leverage [RFC5705] for exporting keys. This section describes how to
establish keying material and negotiate algorithms for OSCORE and for
COSE.
9.1. OSCORE
When the OSCORE mode has been agreed using the "oscore_connection_id"
extension defined in this document, different keys are used for DTLS/
TLS record protection and for OSCORE packet protection. These keys
are produced using a TLS exporter [RFC5705] and the exporter takes
three input values:
o a disambiguating label string,
o a per-association context value provided by the application using
the exporter, and
o a length value.
The label string for use with this specification is defined as 'atls-
oscore'. The per-association context value is empty.
The length value is twice the size of the key size utilized by the
negotiated algorithm since the lower-half is used for the Master
Secret and the upper-half is used for the Master Salt.
For example, if a TLS/DTLS 1.2 handshake negotiated the
TLS_PSK_WITH_AES_128_CCM_8 ciphersuite then the key size utilized by
the negotiated algorithm, i.e. AES 128, is 128 bit. Hence, the key
extractor is requested to produce 2 x 128 bit keying material.
The following parameters are needed for use with OSCORE:
o Master Secret: The master secret is derived as described above.
o Sender ID: This values is negotiated using the
"oscore_connection_id" extension, as described in Section 11.1.
o Recipient ID: This values is negotiated using the
"oscore_connection_id" extension, as described in Section 11.1.
o AEAD Algorithm: This value is negotiated using the ciphersuite
exchange provided by the TLS/DTLS handshake. For example, if a
TLS/DTLS 1.2 handshake negotiated the TLS_PSK_WITH_AES_128_CCM_8
ciphersuite then the AEAD algorithm identifier is AES_128_CCM_8,
which corresponds to two COSE algorithms, which both use AES-CCM
mode with a 128-bit key, a 64-bit tag:
* AES-CCM-64-64-128
* AES-CCM-16-64-128 The difference between the two is only the
length of the nonce, which is 7-bytes in the former case and
13-bytes in the latter. In TLS/DTLS the nonce value is not
negotiated but fixed instead. Figure 15 provides the mapping
between the TLS defined ciphersuite and the COSE algorithms.
o Master Salt: The master salt is derived as described above.
o HKDF Algorithm: This value is negotiated using the ciphersuite
exchange provided by the TLS/DTLS handshake. As a default,
SHA-256 is assumed as a HKDF algorithm for algorithms using
128-bit key sizes and SHA384 for 256-bit key sizes.
o Replay Window: A default window size of 32 packets is assumed.
9.2. COSE
The key exporting procedure for COSE is similiar to the one defined
for OSCORE. The label string for use with this specification is
defined as 'atls-cose'. The per-association context value is empty.
The length value is twice the size of the key size utilized by the
negotiated algorithm since the lower-half is used for the Master
Secret and the upper-half is used for the Master Salt.
The COSE algorithm corresponds to the ciphersuite negotiated during
the TLS/DTLS handshake with with the mapping provided in Figure 15.
The HKDF algorithm is negotiated using the the TLS/DTLS handshake.
As a default, SHA-256 is assumed as a HKDF algorithm for algorithms
using 128-bit key sizes and SHA384 for 256-bit key sizes.
COSE uses key ids to allow finding the appropriate security context.
Those key IDs conceptually correspond to CIDs, as described in
Section 11.2.
10. TLS Ciphersuite to COSE/OSCORE Algorithm Mapping
TLS Ciphersuite | COSE/OSCORE Algorithm
------------------+--------------------------------------------------
AES_128_CCM_8 | AES-CCM w/128-bit key, 64-bit tag, 13-byte nonce
AES_256_CCM_8 | AES-CCM w/256-bit key, 64-bit tag, 13-byte nonce
CHACHA20_POLY1305 | ChaCha20/Poly1305 w/256-bit key, 128-bit tag
AES_128_CCM | AES-CCM w/128-bit key, 128-bit tag, 13-byte nonce
AES_256_CCM | AES-CCM w/256-bit key, 128-bit tag, 13-byte nonce
AES_128_GCM | AES-GCM w/128-bit key, 128-bit tag
AES_256_GCM | AES-GCM w/256-bit key, 128-bit tag
Figure 15: TLS Ciphersuite to COSE/OSCORE Algorithm Mapping
11. TLS Extensions
11.1. The "oscore_connection_id" Extension
This document defines the "oscore_connection_id" extension, which is This document defines the "oscore_connection_id" extension, which is
used in ClientHello and ServerHello messages. It is used only for used in ClientHello and ServerHello messages. It is used only for
establishing the client's OSCORE Sender ID and the server's OSCORE establishing the OSCORE Sender ID and the OSCORE Recipient ID. The
Sender ID. The client's OSCORE Sender ID maps to the CID provided by OSCORE Sender ID maps to the CID provided by the server in the
the server in the ServerHello and the server's OSCORE Sender ID maps ServerHello and the OSCORE Recipient ID maps to the CID provided by
to the CID provided by the client in the ClientHello. the client in the ClientHello.
The negotiation mechanism follows the procedure used in The negotiation mechanism follows the procedure used in
[I-D.ietf-tls-dtls-connection-id] with the exception that the [I-D.ietf-tls-dtls-connection-id] with the exception that the
negotiated CIDs agreed with the "oscore_connection_id" extension is negotiated CIDs agreed with the "oscore_connection_id" extension is
only used with OSCORE and does not impact the record layer format of only used with OSCORE and does not impact the record layer format of
the DTLS/TLS payloads nor the MAC calculation used by DTLS/TLS. As the DTLS/TLS payloads nor the MAC calculation used by DTLS/TLS. As
such, this extension can be used with DTLS as well as with TLS when such, this extension can be used with DTLS as well as with TLS when
those protocols are used at the application layer. those protocols are used at the application layer.
The extension type is specified as follows. The extension type is specified as follows.
enum { oscore_connection_id(TBD), (65535) } ExtensionType; enum {
oscore_connection_id(TBD), (65535)
} ExtensionType;
struct { opaque cid<0..2^8-1>; } ConnectionId; struct {
opaque cid<0..2^8-1>;
} ConnectionId;
Figure 16: The 'oscore_connection_id' Extension
Note: This extension allows a client and a server to determine Note: This extension allows a client and a server to determine
whether an OSCORE security context should be established. whether an OSCORE security context should be established.
A future version of this specification may extend the negotiation 11.2. The "cose_ext" Extension
capabilities.
This document defines the "cose_ext" extension, which is used in
ClientHello and ServerHello messages. It is used only for
establishing the key identifiers, AEAD algorithms, as well as keying
material for use with application layer protection using COSE. The
CID provided by the server in the ServerHello maps to the COSE kid
transmitted from the client to the server and the CID provided by the
client in the ClientHello maps to the COSE kid transmitted from the
server to the client.
The negotiation mechanism follows the procedure used in
[I-D.ietf-tls-dtls-connection-id] with the exception that the
negotiated CIDs agreed with the "cose_ext" extension is only used
with COSE and does not impact the record layer format of the DTLS/TLS
payloads nor the MAC calculation used by DTLS/TLS. As such, this
extension can be used with DTLS as well as with TLS when those
protocols are used at the application layer.
The extension type is specified as follows.
enum {
oscore_connection_id(TBD), (65535)
} ExtensionType;
struct {
opaque cid<0..2^8-1>;
} ConnectionId;
Figure 17: The 'cose_ext' Extension
Note: This extension allows a client and a server to determine
whether an COSE security context should be established.
12. IANA Considerations 12. IANA Considerations
12.1. "oscore_connection_id" TLS extension 12.1. "oscore_connection_id" TLS extension
IANA is requested to allocate an entry to the existing TLS IANA is requested to allocate two entries to the existing TLS
"ExtensionType Values" registry, defined in [RFC5246], for "ExtensionType Values" registry, defined in [RFC5246], for
oscore_connection_id(TBD) defined in this document. oscore_connection_id(TBD1) and cose_ext(TBD2) defined in this
document, as described in the table below.
12.2. .well-known URI Registry Value Extension Name TLS 1.3 DTLS Only Recommended Reference
-----------------------------------------------------------------------
TBD1 oscore_connection_id Y N N [[This doc]]
TBD2 cose_ext Y N N [[This doc]]
Note: The "N" values in the Recommended column are set because these
extensions are intended only for specific use cases.
12.2. TLS Ciphersuite to OSCORE/COSE Algorithm Mapping
IANA is requested to create a new registry for mapping TLS
ciphersuites to SCORE/COSE algorithms
An initial mapping can be found in Figure 15.
Registration requests are evaluated after a three-week review period
on the tls-reg-review@ietf.or mailing list, on the advice of one or
more Designated Experts [RFC8126]. However, to allow for the
allocation of values prior to publication, the Designated Experts may
approve registration once they are satisfied that such a
specification will be published.
Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register an TLS - OSCORE/
COSE algorithm mapping: example"). Registration requests that are
undetermined for a period longer than 21 days can be brought to the
IESG's attention (using the iesg@ietf.org mailing list) for
resolution.
Criteria that should be applied by the Designated Experts includes
determining whether the proposed registration duplicates existing
functionality, whether it is likely to be of general applicability or
whether it is useful only for a single extension, and whether the
registration description is clear.
IANA must only accept registry updates from the Designated Experts
and should direct all requests for registration to the review mailing
list.
12.3. .well-known URI Registry
IANA is requested to add the well-known URI 'atls' to the Well-Known IANA is requested to add the well-known URI 'atls' to the Well-Known
URIs registry. URIs registry.
o URI suffix: atls o URI suffix: atls
o Change controller: IETF o Change controller: IETF
o Specification document(s): [[this document]] o Specification document(s): [[this document]]
o Related information: None o Related information: None
12.3. Media Types Registry 12.4. Media Types Registry
IANA is requested to add the media type 'application/atls' to the IANA is requested to add the media type 'application/atls' to the
Media Types registry. Media Types registry.
o Type name: application o Type name: application
o Subtype name: atls o Subtype name: atls
o Required parameters: N/A o Required parameters: N/A
skipping to change at page 28, line 5 skipping to change at page 30, line 34
"Authors' Addresses" section. "Authors' Addresses" section.
o Intended usage: COMMON o Intended usage: COMMON
o Restrictions on usage: N/A o Restrictions on usage: N/A
o Author: See "Authors' Addresses" section. o Author: See "Authors' Addresses" section.
o Change Controller: IESG o Change Controller: IESG
12.4. HTTP Content-Formats Registry 12.5. HTTP Content-Formats Registry
IANA is requested to add the media type 'application/atls' to the IANA is requested to add the media type 'application/atls' to the
HTTP Content-Formats registry. HTTP Content-Formats registry.
o Media Type: application/atls o Media Type: application/atls
o Encoding: binary o Encoding: binary
o ID: TBD o ID: TBD
o Reference: [[this document]] o Reference: [[this document]]
12.5. CoAP Content-Formats Registry 12.6. CoAP Content-Formats Registry
IANA is requested to add the media type 'application/atls' to the IANA is requested to add the media type 'application/atls' to the
CoAP Content-Formats registry. CoAP Content-Formats registry.
o Media Type: application/atls o Media Type: application/atls
o Encoding: binary o Encoding: binary
o ID: TBD o ID: TBD
o Reference: [[this document]] o Reference: [[this document]]
12.6. TLS Key Extractor Label 12.7. TLS Key Extractor Label
IANA is requested to register the "application-layer-tls" label in IANA is requested to register the "application-layer-tls" label in
the TLS Extractor Label Registry to correspond to this specification. the TLS Extractor Label Registry to correspond to this specification.
13. Security Considerations 13. Security Considerations
This specification re-uses the TLS and DTLS and hence the security This specification re-uses the TLS and DTLS and hence the security
considerations of the respective TLS/DTLS version applies. As considerations of the respective TLS/DTLS version applies. As
described in Section 6.2, implementers need to take the policy described in Section 5.2, implementers need to take the policy
configuration into account when applying security protection at configuration into account when applying security protection at
various layers of the stack even if the same protocol is used since various layers of the stack even if the same protocol is used since
the communiation endpoints and the security requirements are likely the communiation endpoints and the security requirements are likely
going to vary. going to vary.
For use in the IoT environment the considerations described in For use in the IoT environment the considerations described in
[RFC7925] apply and other environments the guidelines in [RFC7525] [RFC7925] apply and other environments the guidelines in [RFC7525]
are applicable. are applicable.
14. Informative References 14. References
[ALTS] Google, "Application Layer Transport Security", December
2017, <https://cloud.google.com/security/encryption-in-
transit/application-layer-transport-security/>.
[Bluetooth]
Bluetooth, "Bluetooth Core Specification v5.0", 2016,
<https://www.bluetooth.com/>.
[I-D.ietf-anima-bootstrapping-keyinfra] 14.1. Normative References
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-19 (work in progress), March 2019.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-httpbis-bcp56bis]
Nottingham, M., "Building Protocols with HTTP", draft-
ietf-httpbis-bcp56bis-08 (work in progress), November
2018.
[I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
id-04 (work in progress), March 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-30 (work in progress), 1.3", draft-ietf-tls-dtls13-31 (work in progress), March
November 2018. 2019.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018.
[I-D.mattsson-core-security-overhead]
Mattsson, J., "Message Size Overhead of CoAP Security
Protocols", draft-mattsson-core-security-overhead-02 (work
in progress), November 2017.
[I-D.selander-ace-cose-ecdhe]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
cose-ecdhe-12 (work in progress), February 2019.
[LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine
Requirements", December 2017,
<http://www.openmobilealliance.org/>.
[Noise] Perrin, T., "Noise Protocol Framework", October 2017,
<http://noiseprotocol.org/>.
[Norrell] Norrell, ., "Use SSL/TLS within a different protocol with
BIO pairs", 2016,
<https://thekerneldiaries.com/2016/06/13/
openssl-ssltls-within-a-different-protocol/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
skipping to change at page 31, line 5 skipping to change at page 32, line 27
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925, Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016, DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
14.2. Informative References
[ALTS] Google, "Application Layer Transport Security", December
2017, <https://cloud.google.com/security/encryption-in-
transit/application-layer-transport-security/>.
[Bluetooth]
Bluetooth, "Bluetooth Core Specification v5.0", 2016,
<https://www.bluetooth.com/>.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-22 (work in progress), June 2019.
[I-D.ietf-httpbis-bcp56bis]
Nottingham, M., "Building Protocols with HTTP", draft-
ietf-httpbis-bcp56bis-08 (work in progress), November
2018.
[I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
id-05 (work in progress), May 2019.
[I-D.mattsson-lwig-security-protocol-comparison]
Mattsson, J. and F. Palombini, "Comparison of CoAP
Security Protocols", draft-mattsson-lwig-security-
protocol-comparison-01 (work in progress), March 2018.
[I-D.rescorla-tls-ctls]
Rescorla, E., "Compact TLS 1.3", draft-rescorla-tls-
ctls-01 (work in progress), March 2019.
[I-D.selander-ace-cose-ecdhe]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
cose-ecdhe-13 (work in progress), March 2019.
[LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine
Requirements", December 2017,
<http://www.openmobilealliance.org/>.
[Noise] Perrin, T., "Noise Protocol Framework", October 2017,
<http://noiseprotocol.org/>.
[Norrell] Norrell, ., "Use SSL/TLS within a different protocol with
BIO pairs", 2016,
<https://thekerneldiaries.com/2016/06/13/
openssl-ssltls-within-a-different-protocol/>.
[Signal] Open Whisper Systems, "Signal Protocol", 2016, [Signal] Open Whisper Systems, "Signal Protocol", 2016,
<https://signal.org/>. <https://signal.org/>.
[SSLEngine] [SSLEngine]
Oracle, "SSLEngineSimpleDemo.java", 2004, <https://docs.or Oracle, "SSLEngineSimpleDemo.java", 2004, <https://docs.or
acle.com/javase/7/docs/technotes/guides/security/jsse/samp acle.com/javase/7/docs/technotes/guides/security/jsse/samp
les/sslengine/SSLEngineSimpleDemo.java>. les/sslengine/SSLEngineSimpleDemo.java>.
[ZigBee] ZigBee Alliance, "ZigBee Specification", 2012, [ZigBee] ZigBee Alliance, "ZigBee Specification", 2012,
<http://www.zigbee.org>. <http://www.zigbee.org>.
skipping to change at page 35, line 12 skipping to change at page 38, line 12
// containing multiple TLS Records // containing multiple TLS Records
// Rinse and repeat! // Rinse and repeat!
Appendix B. Example ATLS Handshake Appendix B. Example ATLS Handshake
[[ EDITOR'S NOTE: For completeness, include a simple full TLS [[ EDITOR'S NOTE: For completeness, include a simple full TLS
handshake showing the raw binary flights, along with the HTTP handshake showing the raw binary flights, along with the HTTP
request/response/headers. And also the raw hex TLS records showing request/response/headers. And also the raw hex TLS records showing
protocol bits ]] protocol bits ]]
Appendix C. Alternative Approaches to Application Layer End-to-End
Security
End-to-end security at the application layer is increasing seen as a
key requirement across multiple applications and services. Some
examples of end-to-end security mechanisms are outlined here. All
the solutions outlined here have some common characteristics. The
solutions:
o do not rely on transport layer security
o define a new handshake protocol for establishment of a secure end-
to-end session
C.1. Noise
[Noise] is a framework for cryptographic protocols based on Elliptic
Curve Diffie-Hellman (ECDH) key agreement, AEAD encryption, and
BLAKE2 and SHA2 hash functions. Noise is currently used by WhatsApp,
WireGuard, and Lightning.
The current Noise protocol framework defines mechanisms for proving
possession of a private key, but does not define authentication
mechanisms. Section 14 "Security Considerations" of Noise states:
~~~ it's up to the application to determine whether the remote
party's static public key is acceptable ~~~
C.2. Signal
The [Signal] protocol provides end-to-end encryption and uses EdDSA
signatures, Triple Diffie-Hellman handshake for shared secret
establishment, and the Double Ratchet Algorithm for key management.
It is used by Open Whisper Systems, WhatsApp and Google.
Similar to Noise, Signal does not define an authentication mechanism.
The current [X3DH] specification states in Section 4.1
"Authentication":
Methods for doing this are outside the scope of this document
C.3. Google ALTS
Google's Application Layer Transport Security [ALTS] is a mutual
authentication and transport encryption system used for securing
Remote Procedure Call (RPC) communications within Google's
infrastructure. ALTS uses an ECDH handshake protocol and a record
protocol containing AES encrypted payloads.
C.4. Ephemeral Diffie-Hellman Over COSE (EDHOC)
There is ongoing work to standardise EDHOC
[I-D.selander-ace-cose-ecdhe], which defines a SIGMA-I based
authenticated key exchange protocol using COSE and CBOR.
Authors' Addresses Authors' Addresses
Owen Friel Owen Friel
Cisco Cisco
Email: ofriel@cisco.com Email: ofriel@cisco.com
Richard Barnes Richard Barnes
Cisco Cisco
Email: rlb@ipv.sx Email: rlb@ipv.sx
Max Pritikin Max Pritikin
Cisco Cisco
Email: pritikin@cisco.com Email: pritikin@cisco.com
Hannes Tschofenig Hannes Tschofenig
ARM Limited Arm Ltd.
Email: hannes.tschofenig@gmx.net Email: hannes.tschofenig@gmx.net
Mark Baugher Mark Baugher
Consultant Consultant
Email: mark@mbaugher.com Email: mark@mbaugher.com
 End of changes. 91 change blocks. 
355 lines changed or deleted 552 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/