Cisco

ofriel@cisco.com

Cisco

rlb@ipv.sx

Cisco

pritikin@cisco.com

ARM Limited

hannes.tschofenig@gmx.net

Consultant

mark@mbaugher.com

This document specifies how TLS sessions can be established at the application layer over untrusted transport between clients and services for the purposes of establishing secure end-to-end encrypted communications channels. Transport layer encodings for application layer TLS records are specified for HTTP and CoAP transport. Explicit identification of application layer TLS packets enables middleboxes to provide transport services and enforce suitable transport policies for these payloads, without requiring access to the unencrypted payload content. Multiple scenarios are presented identifying the need for end-to-end application layer encryption 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 outlined.

There are multiple scenarios where there is a need for application layer end-to-end security between clients and application services. Two examples include: Bootstrapping devices that must connect to HTTP application services across untrusted TLS interception middleboxes Constrained devices connecting via gateways to application services, where different transport layer protocols may be in use on either side of the gateway, with the gateway transcoding between the different transport layer protocols. These two scenarios are described in more detail in . Related to this document, there is ongoing work across the industry to define requirements for end-to-end security. documents requirements for CoAP End-to-End Security. The Open Mobile Alliance (OMA) has published a candidate standard Lightweight Machine to Machine Requirements which defines multiple requirements for end-to-end security. This document describes how clients and applications can leverage standard TLS software stacks to establish secure end-to-end encrypted connections at the application layer. The connections may establish TLS or DTLS sessions. There are multiple advantages to reuse of existing TLS software stacks for establishment of application layer secure connections. These include: many clients and application services already include a TLS software stack, so there is no need to include yet another software stack in the software build no need to define a new cryptographic negotiation, authentication, and key exchange protocol between clients and services provides standards based PKI mutual authentication between clients and services no need to train software developers on how to use a new cryptographic protocols or libraries automatically benefit from new cipher suites by simply upgrading the TLS software stack automatically benefit from new features, bugfixes, etc. in TLS software stack upgrades This document also explicitly defines how application layer TLS connections can be established using HTTP or CoAP as transport layers. This document does not preclude the user of other transport layers, however defining how application layer TLS connections can be established over other transport layers such as or is beyond the scope of this document. Explicitly identifying application layer TLS packets enables transport layer middleboxes to provide transport capabilities and enforce suitable transport policies for these payloads, without requiring access to unencrypted application data.

Application layer TLS is referred to as ATLS throughout this document.

This section describes in more detail the bootstrapping and constrained device use cases mentioned in the introduction.

There are far more classes of clients being deployed on today’s networks than at any time previously. This poses challenges for network administrators who need to manage their network and the clients connecting to their network, and poses challenges for client vendors and client software developers who must ensure that their clients can connect to all required services. One common example is where a client is deployed on a local domain TCP/IP network that protects its perimeter using a TLS terminating middlebox, and the client needs to establish a secure connection to a service in a different network via the middlebox. This is illustrated in . Traditionally, this has been enabled by the network administrator deploying the necessary certificate authority trusted roots on the client. This can be achieved at scale using standard tools that enable the administrator to automatically push trusted roots out to all client machines in the network from a centralized domain controller. This works for personal computers, laptops and servers running standard Operating Systems that can be centrally managed. This client management process breaks for multiple classes of clients that are being deployed today, there is no standard mechanism for configuring trusted roots on these clients, and there is no standard mechanism for these clients to securely traverse middleboxes.

M TLS +-----------+ M->S TLS +---------+ | Client |--------------->| Middlebox |------------->| Service | +--------+ +-----------+ +---------+ ^ ^ | | +-----------Client to Service ATLS Connection---------+ ]]>

The ATLS mechanism defined in this document enables clients to traverse middleboxes and establish secure connections to services across network domain boundaries. The purpose of this connection may simply be to facilitate a bootstrapping process, for example , whereby the client securely discovers the local domain certificate authorities required to establish a trusted network layer TLS connection to the middlebox.

Two constrained device use cases are outlined here.

There are industry examples of home smart lighting systems where the smart light bulbs connect using ZigBee to a gateway device. A controller application running on a mobile device connects to the gateway using CoAP over DTLS. The controller can then control the light bulbs by sending messages and commands via the gateway. The gateway device has full access to all messages sent between the light bulbs and the controller application. A generic use case similar to the smart lighting system outlined above has an IoT device talking ZigBee to a gateway, with the gateway in turn talking CoAP over DTLS to a controller application running on a mobile device. This is illustrated in . There are scenarios where the messages sent between the IoT device and the controller application must not be exposed to the gateway function. Additionally, the end devices (the IoT device and the controller application service) have no visibility to and no guarantees about what transport layer security and encryption is enforced across all hops end-to-end as they only have visibility to their immediate next hop. ATLS addresses these concerns.

| Gateway |------------->| Mobile App | +--------+ +---------+ +------------+ ^ ^ | | +--------Device to Mobile App ATLS Connection-------+ ]]>

A somewhat similar example has an IoT device connecting to a gateway using a suitable transport mechanism such as ZigBee, CoAP, MQTT, etc. The gateway function in turn talks HTTP over TLS (or, for example, HTTP over QUIC) to an application service over the Internet. This is illustrated in . The gateway may not be trusted and all messages between the IoT device and the application service must be end-to-end encrypted. Similar to the previous use case, the endpoints have no guarantees about what level of transport layer security is enforced across all hops. Again, ATLS addresses these concerns.

| Internet Gateway |------------>| Service | +--------+ +------------------+ +---------+ ^ ^ | | +---------Device to Cloud Service ATLS Connection----------+ ]]>

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: do not rely on transport layer security define a new handshake protocol for establishment of a secure end-to-end session

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

The 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”:

Google’s Application Layer Transport Security 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.

There is ongoing work to standardise . This defines a ECDH SIGMA based authenticated key exchange algorithm using COSE and COBR objects.

The high level goals driving the design of this mechanism are: enable authenticated key exchange at the application layer by reusing existing technologies ensure that ATLS packets are explicitly identified thus ensuring that any middleboxes or gateways at the transport layer are content aware leverage existing TLS stacks and handshake protocols thus avoiding introducing new software or protocol dependencies in clients and applications reuse existing TLS and DTLS specifications as is without requiring any protocol changes or software stack changes do not mandate constraints on how the TLS stack is configured or used be forward compatible with future TLS versions avoid introducing TLS protocol handling logic or semantics into the application layer i.e. TLS protocol knowledge and logic is handled by the TLS stack, not the application ensure the client and server software implementations are as simple as possible

TLS software stacks allow application developers to ‘unplug’ the default network socket transport layer and read and write TLS records directly from byte buffers. This enables application developers to create application layer TLS sessions, extract the raw TLS record bytes from the bottom of the TLS stack, and transport these bytes over any suitable transport. The TLS software stacks can generate byte streams of full TLS flights which may include multiple TLS records. Additionally, TLS software stacks support Keying Material Exporters and allow applications to export keying material from established TLS sessions. This keying material can then be used by the application for encryption of data outside the context of the TLS session. This is illustrated in below.

| |------------------->| | | | | Byte | Unencrypted Data | TLS | Encrypted Data | | ------------------->| |------------------->| Buffers | | Software | | | Encrypted Data | | Unencrypted Data | | ------------------->| Stack |------------------->| | | | +---------+ Keying Material | | <-------------------| | + -----------+ ]]>

These TLS software stack APIs enable application developers to build the software architectures illustrated in and . In both architectures, the application creates and interacts with an application layer TLS session in order to generate and consume raw TLS records. The application transports these raw TLS records inside transport layer message bodies using whatever standard transport layer stack is suitable for the application or architecture. This document does not place any restrictions on the choice of transport layer and any suitable protocol such as HTTP, TCP, CoAP, ZigBee, Bluetooth, etc. could be used. The transport layer will typically encrypt data, and this encryption is completely independent from any application layer encryption. The transport stack may create a transport layer TLS session. The application layer TLS session and transport layer TLS session can both leverage a shared, common TLS software stack. This high level architecture is applicable to both clients and application services. The key differences between the architectures are as follows. In the model illustrated in , the application sends all sensitive data that needs to be securely exchanged with the peer application through the Application TLS session in order to be encrypted and decrypted. All sensitive application data is thus encoded within TLS records by the TLS stack, and these TLS records are transmitted over the transport layer.

| App | +---------+ | | TLS | TLS |----->| TLS | | | Records | Session | | Stack | | +--->|<---------->| | +---------+ | | | +---------+ ^ | | | |? | | | Transport +-----------+ +------------+ | | | Payload | Transport | | Transport | | +--->|<--------->| Stack |--->| Encryption |-->Packets +-------------+ +-----------+ +------------+ ]]>

In the model illustrated in , the application establishes an application layer TLS session purely for the purposes of key exchange. Therefore, the only TLS records that are sent or received by the application layer are TLS handshake records. Once the application layer TLS session is established, the application uses Keying Material Exporter APIs to export keying material from the TLS stack from this application layer TLS session. The application can then use these exported keys to derive suitable shared encryption keys with its peer for exchange of encrypted data. The application encrypts and decrypts sensitive data using these shared encryption keys using any suitable cryptographic library (which may be part of the same library that provides the TLS stack), and transports the encrypted data directly over the transport layer.

| TLS | | | | Records | | | Stack | | | +--->|<---------->| | +---------+ | | | | +---------+ ^ | | | | |? | | | | Transport +-----------+ +------------+ | | | | Payload | Transport | | Transport | | +----+--->|<--------->| Stack |--->| Encryption |-->Packets +--------------+ +-----------+ +------------+ ]]>

The choice of which application architecture to use will depend on the overall solution architecture, and the underlying transport layer or layers in use. While the choice of application architecture is outside the scope of this document, some considerations are outlined here. for constrained devices, every single byte of payload is important. analyses the overhead of TLS headers compared with OSCORE illustrating the additional overhead associated with TLS headers. It may be more appropriate to use the architecture defined in in order to establish shared encryption keys, and then transport encrypted data directly without the overhead of unwanted TLS record headers. when using HTTP as a transport layer, it may be more appropriate to use the architecture defined in in order to avoid any TLS session vs. HTTP session affinity issues.

There are several benefits to using a standard TLS software stack to establish an application layer secure communications channel between a client and a service. These include: no need to define a new cryptographic negotiation and exchange protocol between client and service automatically benefit from new cipher suites by simply upgrading the TLS software stack automatically benefit from new features, bugfixes, etc. in TLS software stack upgrades

It is recommended that ATLS packets are explicitly identified by a standardized, transport-specific identifier enabling any gateways and middleboxes to identify ATLS packets. Middleboxes have to contend with a vast number of applications and network operators have difficulty configuring middleboxes to distinguish unencrypted but not explicitly identified application data from end-to-end encrypted data. This specification aims to assist network operators by explicitly identifying ATLS packets. The HTTP and CoAP encodings documented in and explicitly identify ATLS packets.

The ATLS application service establishes multiple ATLS sessions with multiple clients. As TLS sessions are stateful, the application service must be able to correlate ATLS records from different clients across the relevant ATLS sessions. The details of how session tracking is implemented are outside the scope of this document. Recommendations are given in and , but session tracking is application and implementation specific.

It should not be necessary for the application layer to have to 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, application_data, alert or change_cipher_spec messages. If new ContentType messages are defined in future TLS versions, these may also be transported using this protocol.

Pseudo code illustrating how to read and write TLS records directly from byte buffers using both OpenSSL BIO functions and Java JSSE SSLEngine is given in the appendices. A blog post by outlines a similar approach to leveraging OpenSSL BIO functions, and Oracle publish example code for leveraging .

[ todo: insert Hannes functional design section here including the policy layers ] Policy examples: Mention that the app layer policy could be to not do ATLS if the transport layer establishes an e2e session with the peer. e.g. for HTTP use cases where there is no middlebox and cert validation passes. Mention that the client could report in the ATLS session any middlebox cert seen at the transport layer.

An example network deployment is illustrated in . It shows a constrained client connecting to an application service via an internet gateway. The client uses CoAP over DTLS to communicate with the gateway. The gateway extracts the messages the client sent over CoAP and sends these messages inside HTTP message bodies to the application service. It also shows a TLS terminator deployed in front of the application service. The client establishes a transport layer CoAP/DTLS connection with the gateway (C->G DTLS), the gateway in turn opens a transport layer TLS connection with the TLS terminator deployed in front of the service (G->T TLS). The client can ignore any certificate validation errors when it connects to the gateway. CoAP messages are transported between the client and the gateway, and HTTP messages are transported between the client and the service. Finally, application layer TLS messages are exchanged inside the CoAP and HTTP message bodies in order to establish an end-to-end TLS session between the client and the service (C->S TLS).

S TLS | | C->S TLS | | App Data | +----------+ +----------+ +----------+ | CoAP | | HTTP | | C->S TLS | +----------+ +----------+ +----------+ | C->G DTLS| | M->T TLS | | HTTP | +----------+ +----------+ +----------+ | UDP | | TCP | | TCP | +----------+ +----------+ +----------+ +--------+ +-----------+ +----------------+ +---------+ | Client |----->| Gateway |----->| TLS Terminator |---->| Service | +--------+ +-----------+ +----------------+ +---------+ ^ ^ | | +-------------Client to Service ATLS Connection-------------+ ]]>

Another typical network deployment is illustrated in . It shows a client connecting to a service via a middlebox. It also shows a TLS terminator deployed in front of the service. The client establishes a transport layer TLS connection with the middlebox (C->M TLS), the middlebox in turn opens a transport layer TLS connection with the TLS terminator deployed in front of the service (M->T TLS). The client can ignore any certificate validation errors when it connects to the middlebox. HTTP messages are transported over this layer between the client and the service. Finally, application layer TLS messages are exchanged inside the HTTP message bodies in order to establish an end-to-end TLS session between the client and the service (C->S TLS).

S TLS | | C->S TLS | | App Data | +----------+ +----------+ +----------+ | HTTP | | HTTP | | C->S TLS | +----------+ +----------+ +----------+ | C->M TLS | | M->T TLS | | HTTP | +----------+ +----------+ +----------+ | TCP | | TCP | | TCP | +----------+ +----------+ +----------+ +--------+ +-----------+ +----------------+ +---------+ | Client |----->| Middlebox |----->| TLS Terminator |---->| Service | +--------+ +-----------+ +----------------+ +---------+ ^ ^ | | +-------------Client to Service ATLS Connection-------------+ ]]>

When solutions implement the architecture described in , they leverage for key exporting from the ATLS session. The client and service then use the exported keys to derive shared encryption keys. The encryption keys are then used with a suitable cipher suite to encrypt application data for exchange with the peer.

A new TLS Exporter Label is defined for ATLS key exporting. Its value is:

Application layer encryption performed outside the context of the ATLS session using exported keys should use the cipher suite negotiated during ATLS session establishment.

key exporting functions allow specification of the number of bytes of keying material that should be exported from the TLS session. The application should export the exact number of bytes required to generate the necessary client and server cipher suite encryption key and IV values. [[TODO]] Maybe need to reference the relevant sections from https://tools.ietf.org/html/draft-ietf-tls-tls13-23#section-7 and https://tools.ietf.org/html/rfc5246#section-6.3.

illustrates how an ATLS session is established using the key exporting architectural model shown in . The outline is as follows: the client creates an ATLS session object the client initiates a TLS handshake on the session the client extracts the TLS records for the first TLS flight (the first RTT) the client sends the TLS records over the transport layer to the server on receipt of the TLS flight, the server creates an ATLS session object the server injects the received TLS flight into the session the server extracts the TLS records for the first TLS flight response the server sends the TLS response records over the transport layer to the client the client injects the received TLS records into its TLS session completing the first full RTT the client and server repeat the above process and complete the second RTT once the ATLS session is up, both sides export keying material both sides now can exchange data encrypted using shared keys derived from the keying material

| Records | | | | | |-------->| send packet | Unpack | | R | | |------------>| Records | Create | T | | | |--------->| Session | T | | | | |--------->| | | | | | TLS | 1 | | | | | Records | | | | | |--------->| | | | | | | TLS | | | | | | Pack | Records | | | | | | Records |<---------| | | | Unpack |send response|<---------| | | | TLS | Records |<------------| | | | | Records |<--------| | | | + |<---------| | | | | | TLS | | | | | | Records | | | | | + |--------->|-------->|------------>|--------->|--------->| | | | | | | | | | | | | Session | R | | | | | Up | T | | | | |<---------| T | | | | | TLS | | | | | | Records | 2 |<---------|<--------|<------------|<---------|<---------| | Session | | | | | | | Up | | | | | + |--------->| | | | | | Export | | | | Export | | Keys | | | | Keys | |--------->| | E2E Session | |<---------| | |<--------|-------------|--------->| | ]]>

The assumption is that the client will establish a transport layer connection to the server for exchange of HTTP messages. The underlying transport layer connection could be over TCP or TLS. The client will then establish an application layer TLS connection with the server by exchanging TLS records with the server inside HTTP message request and response bodies.

All ATLS records are transported unmodified as binary data within HTTP message bodies. The application simply extracts the TLS records from the TLS stack and inserts them directly into HTTP message bodies. Each message body contains a full TLS flight, which may contain multiple TLS records. The client sends all ATLS records to the server in the bodies of POST requests. The server sends all ATLS records to the client in the bodies of 200 OK responses to the POST requests.

A new Content-Type header value is defined:

All message bodies containing ATLS records must set this Content-Type. This enables middleboxes to readily identify ATLS payloads.

This document does not define any new HTTP status codes, and does not specify additional semantics or refine existing semantics for status codes. This is the best current practice as outlined in .

The application service needs to track multiple client application layer TLS sessions so that it can correlate TLS records received in HTTP message bodies with the appropriate TLS session. The application service should use stateful cookies in order to achieve this as recommended in .

It is recommended that applications using ATLS over HTTP transport only use ATLS for session establishment and key exchange, resulting in only 2 ATLS RTTs between the client and the application service. Key exporting must be carried out as described in .

[editors note: I am on the fence about using as this hardcodes the ciphersuite to aes128gcm. It would be nice to use the cipher suite negotiated as part of ATLS session establishment. ]

A client initiates an ATLS session by sending the first TLS flight in a POST request message body to the ATLS server.

]]>

The server handles the request, creates an ATLS session object, and replies by including its first TLS flight in a 200 OK message body. The server also sets a suitable cookie for session tracking purposes.

]]>

The client handles the server first flight TLS records and replies with its second flight.

]]>

The server handles the second flight, establishes the ATLS session, and replies with its second flight.

]]>

It is worthwhile comparing and contrasting ATLS with HTTP CONNECT tunneling. First, let us introduce some terminology: HTTP Proxy: A HTTP Proxy operates at the application layer, handles HTTP CONNECT messages from clients, and opens tunnels to remote origin servers on behalf of clients. If a client establishes a tunneled TLS connection to the origin server, the HTTP Proxy does not attempt to intercept or inspect the HTTP messages exchanged between the client and the server middlebox: A middlebox operates at the transport layer, terminates TLS connections from clients, and originates new TLS connections to services. A middlebox inspects all messages sent between clients and services. Middleboxes are generally completely transparent to applications, provided that the necessary PKI root Certificate Authority is installed in the client’s trust store. HTTP Proxies and middleboxes are logically separate entities and one or both of these may be deployed in a network. 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 server that is typically deployed in a different domain. Assuming that TLS transport is used between both client and proxy, and proxy and origin server, the network architecture is as illustrated in . Once the proxy opens the transport tunnel to 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 session records) between the client and the service. From the client 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). No middlebox is attempting to intercept or inspect the HTTP messages between the client and the service.

S HTTP| | C->S HTTP| +----------+ +----------+ | C->S TLS | | C->S TLS | +----------+ +----------+ | C->P TLS | | P->S TCP | +----------+ +----------+ | C->P TCP | +----------+ +--------+ +------------+ +---------+ | Client |----->| HTTP Proxy |----->| Service | +--------+ +------------+ +---------+ ]]>

A more complex network topology where the network operator has both a HTTP Proxy and a middlebox deployed is illustrated in . In this scenario, the proxy has tunneled the TLS session from the client towards the origin server, however the middlebox is intercepting and 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 server. It can clearly be seen that HTTP CONNECT and HTTP Proxies serve completely different functions than middleboxes. Additionally, the fact that the TLS session is established between the client and the middlebox can be problematic for two reasons: the middle box is inspecting traffic that is sent between the client and the service the client may not have the necessary PKI root Certificate Authority installed that would enable it to validate the TLS connection to the middlebox. This is the scenario outlined in .

S HTTP| | C->S HTTP| | C->S HTTP| +----------+ +----------+ +----------+ | C->M TLS | | C->M TLS | | M->S TLS | +----------+ +----------+ +----------+ | C->P TLS | | P->M TCP | | M->S TCP | +----------+ +----------+ +----------+ | C->P TCP | +----------+ +--------+ +------------+ +-----------+ +---------+ | Client |----->| HTTP Proxy |----->| Middlebox |----->| Service | +--------+ +------------+ +-----------+ +---------+ ]]>

As HTTP CONNECT can be used to establish a tunneled TLS connection, one hypothetical solution to this middlebox issue is for the client to issue a HTTP CONNECT command to a HTTP Reverse Proxy deployed in front of the origin server. This solution is not practical for several reasons: 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 Forward Proxy, and then a second HTTP CONNECT to get past the Reverse Proxy. No client or client library supports the concept of HTTP CONNECT inside HTTP CONNECT. if there is no local domain HTTP Proxy deployed, the client still has to do a HTTP CONNECT to the HTTP Reverse Proxy. This breaks with standard and expected HTTP CONNECT operation, as HTTP CONNECT is only ever called if there is a local domain proxy. clients cannot generate CONNECT from XHR in web applications. this would require the deployment of a Reverse Proxy in front of the origin server, or else support of the HTTP CONNECT method in standard web frameworks. This is not an elegant design. using HTTP CONNECT with HTTP 1.1 to a Reverse Proxy will break middleboxes inspecting HTTP traffic, as the middlebox would see TLS records when it expects to see HTTP payloads. In contrast to trying to force HTTP CONNECT to address a problem for which it was not designed to address, and having to address all the issues just outlined; ATLS is specifically designed to address the middlebox issue in a simple, easy to develop, and easy to deploy fashion. ATLS works seamlessly with HTTP Proxy deployments no changes are required to HTTP CONNECT semantics no changes are required to HTTP libraries or stacks no additional Reverse Proxy is required to be deployed in front of origin servers It is also worth noting that if HTTP CONNECT to a Reverse Proxy were a conceptually sound solution, the solution still ultimately results in encrypted traffic traversing the middlebox that the middlebox cannot intercept and inspect. That is ultimately what ATLS results in - traffic traversing the middle box that the middlebox cannot intercept and inspect. Therefore, from a middlebox perspective, the differences between the two solutions are in the areas of solution complexity and protocol semantics. It is clear that ATLS is a simpler, more elegant solution that HTTP CONNECT.

[ todo: Help needed Hannes ]

The number of RTTs that take place when establishing a TLS session depends on the version of TLS and what capabilities are enabled on the TLS software stack. For example, a 0-RTT exchange is possible with TLS1.3. If applications wish to ensure a predictable number of RTTs when establishing an application layer TLS connection, this may be achieved by configuring the TLS software stack appropriately. Relevant configuration parameters for OpenSSL and Java SunJSSE stacks are outlined in the appendix.

[[ TODO - New Content-Type and TLS Exporter Label must be registered. ]]

[[ TODO ]]

noiseprotocol.org Open Mobile Alliance Open Whisper Systems Google ZigBee Alliance Bluetooth Oracle This document analyses threats to CoAP message exchanges traversing proxies and derives security requirements for mitigating those threats. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 4492, 5705, and 6066 and it obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a compact, and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys that can be used over any layer. EDHOC messages are encoded with CBOR and COSE, allowing reuse of existing libraries. A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] This document analyzes and compares per-packet message size overheads when using different security protocols to secure CoAP. The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, and OSCORE. DTLS and TLS are analyzed with and without compression. DTLS are analyzed with two different alternatives for header compression as well as with and without Connection ID. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. HTTP is often used as a substrate for other application protocols (a.k.a. HTTP-based APIs). This document specifies best practices for these protocols' use of HTTP. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at http://httpwg.github.io/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/bcp56bis [3]. This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK] This memo introduces a content coding for HTTP that allows message payloads to be encrypted.

[[ EDITOR’S NOTE: We could include details here on how TLS stack configuration items control the number of round trips between the client and server. And just give two examples: OpenSSL and Java SunJSSE]]

This appendix gives both C and Java pseudo code illustrating how to inject and extract raw TLS records from a TLS software stack. Please not that this is illustrative, non-functional pseudo code that does not compile. Functioning proof-of-concept code is available on the following public repository [[ EDITOR’S NOTE: Add the URL here ]].

OpenSSL provides a set of Basic Input/Output (BIO) APIs that can be used to build a custom transport layer for TLS connections. This appendix gives pseudo code on how BIO APIs could be used to build a client application that completes a TLS handshake and exchanges application data with a service.

The Java SSLEngine class “enables secure communications using protocols such as the Secure Sockets Layer (SSL) or IETF RFC 2246 “Transport Layer Security” (TLS) protocols, but is transport independent”. This pseudo code illustrates how a server could use the SSLEngine class to handle an inbound client TLS flight and generate an outbound server TLS flight response.

[[ EDITOR’S NOTE: For completeness, include a simple full TLS handshake showing the raw binary flights, along with the HTTP request/response/headers. And also the raw hex TLS records showing protocol bits ]]