idnits 2.17.1 draft-friel-tls-atls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 31, 2018) is 2274 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'X3DH' is mentioned on line 326, but not defined == Missing Reference: 'MAX' is mentioned on line 1065, but not defined == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-09 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-08 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-00 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-22 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-23 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-07 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Friel 3 Internet-Draft R. Barnes 4 Intended status: Standards Track M. Pritikin 5 Expires: August 4, 2018 Cisco 6 H. Tschofenig 7 ARM Limited 8 M. Baugher 9 Consultant 10 January 31, 2018 12 Application-Layer TLS (ATLS) 13 draft-friel-tls-atls-00 15 Abstract 17 This document specifies how TLS sessions can be established at the 18 application layer over untrusted transport between clients and 19 services for the purposes of establishing secure end-to-end encrypted 20 communications channels. Transport layer encodings for application 21 layer TLS records are specified for HTTP and CoAP transport. 22 Explicit identification of application layer TLS packets enables 23 middleboxes to provide transport services and enforce suitable 24 transport policies for these payloads, without requiring access to 25 the unencrypted payload content. Multiple scenarios are presented 26 identifying the need for end-to-end application layer encryption 27 between clients and services, and the benefits of reusing the well- 28 defined TLS protocol, and a standard TLS stack, to accomplish this 29 are described. Application software architectures for building, and 30 network architectures for deploying application layer TLS are 31 outlined. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 4, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Application Layer End-to-End Security Use Cases . . . . . . . 4 70 3.1. Bootstrapping Devices . . . . . . . . . . . . . . . . . . 4 71 3.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 5 72 3.2.1. Constrained Device Connecting over a Closed Network . 5 73 3.2.2. Constrained Device Connecting over the Internet . . . 6 74 4. Current Approaches to Application Layer End-to-End Security 7 75 4.1. Noise . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.2. Signal . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.3. Google ALTS . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.4. Ephemeral Diffie-Hellman Over COSE . . . . . . . . . . . 8 79 5. ATLS Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 6. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 81 6.1. Application Architecture . . . . . . . . . . . . . . . . 9 82 6.1.1. Application Architecture Benefits . . . . . . . . . . 11 83 6.1.2. ATLS Packet Identification . . . . . . . . . . . . . 12 84 6.1.3. ATLS Session Tracking . . . . . . . . . . . . . . . . 12 85 6.1.4. ATLS Record Inspection . . . . . . . . . . . . . . . 12 86 6.1.5. Implementation . . . . . . . . . . . . . . . . . . . 12 87 6.2. Functional Design . . . . . . . . . . . . . . . . . . . . 13 88 6.3. Network Architecture . . . . . . . . . . . . . . . . . . 13 89 7. Key Exporting and Application Data Encryption . . . . . . . . 15 90 7.1. Key Exporter Label . . . . . . . . . . . . . . . . . . . 15 91 7.2. Cipher Suite Selection . . . . . . . . . . . . . . . . . 15 92 7.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 15 93 8. ATLS Session Establishment . . . . . . . . . . . . . . . . . 16 94 9. ATLS over HTTP Transport . . . . . . . . . . . . . . . . . . 18 95 9.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 18 96 9.2. Content-Type Header . . . . . . . . . . . . . . . . . . . 18 97 9.3. HTTP Status Codes . . . . . . . . . . . . . . . . . . . . 18 98 9.4. ATLS Session Tracking . . . . . . . . . . . . . . . . . . 18 99 9.5. Session Establishment and Key Exporting . . . . . . . . . 19 100 9.6. Application Data Encryption . . . . . . . . . . . . . . . 19 101 9.7. Illustrative ATLS over HTTP Session Establishment . . . . 19 102 9.8. ATLS and HTTP CONNECT . . . . . . . . . . . . . . . . . . 20 103 10. ATLS over CoAP Transport . . . . . . . . . . . . . . . . . . 23 104 11. RTT Considerations . . . . . . . . . . . . . . . . . . . . . 23 105 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 106 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 107 14. Appendix A. TLS Software Stack Configuration . . . . . . . . 24 108 15. Appendix B. Pseudo Code . . . . . . . . . . . . . . . . . . . 24 109 15.1. B.1 OpenSSL . . . . . . . . . . . . . . . . . . . . . . 24 110 15.2. B.2 Java JSSE . . . . . . . . . . . . . . . . . . . . . 26 111 16. Appendix C. Example ATLS Handshake . . . . . . . . . . . . . 28 112 17. Informative References . . . . . . . . . . . . . . . . . . . 28 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 115 1. Introduction 117 There are multiple scenarios where there is a need for application 118 layer end-to-end security between clients and application services. 119 Two examples include: 121 o Bootstrapping devices that must connect to HTTP application 122 services across untrusted TLS interception middleboxes 124 o Constrained devices connecting via gateways to application 125 services, where different transport layer protocols may be in use 126 on either side of the gateway, with the gateway transcoding 127 between the different transport layer protocols. 129 These two scenarios are described in more detail in Section 3. 131 Related to this document, there is ongoing work across the industry 132 to define requirements for end-to-end security. 133 [I-D.hartke-core-e2e-security-reqs] documents requirements for CoAP 134 [RFC7252] End-to-End Security. The Open Mobile Alliance (OMA) has 135 published a candidate standard Lightweight Machine to Machine 136 Requirements [LwM2M] which defines multiple requirements for end-to- 137 end security. 139 This document describes how clients and applications can leverage 140 standard TLS software stacks to establish secure end-to-end encrypted 141 connections at the application layer. The connections may establish 142 TLS [RFC5246] [I-D.ietf-tls-tls13] or DTLS [RFC6347] 143 [I-D.ietf-tls-dtls13] sessions. There are multiple advantages to 144 reuse of existing TLS software stacks for establishment of 145 application layer secure connections. These include: 147 o many clients and application services already include a TLS 148 software stack, so there is no need to include yet another 149 software stack in the software build 151 o no need to define a new cryptographic negotiation, authentication, 152 and key exchange protocol between clients and services 154 o provides standards based PKI mutual authentication between clients 155 and services 157 o no need to train software developers on how to use a new 158 cryptographic protocols or libraries 160 o automatically benefit from new cipher suites by simply upgrading 161 the TLS software stack 163 o automatically benefit from new features, bugfixes, etc. in TLS 164 software stack upgrades 166 This document also explicitly defines how application layer TLS 167 connections can be established using HTTP [RFC7230] [RFC7540] or CoAP 168 as transport layers. This document does not preclude the user of 169 other transport layers, however defining how application layer TLS 170 connections can be established over other transport layers such as 171 [ZigBee] or [Bluetooth] is beyond the scope of this document. 173 Explicitly identifying application layer TLS packets enables 174 transport layer middleboxes to provide transport capabilities and 175 enforce suitable transport policies for these payloads, without 176 requiring access to unencrypted application data. 178 2. Terminology 180 Application layer TLS is referred to as ATLS throughout this 181 document. 183 3. Application Layer End-to-End Security Use Cases 185 This section describes in more detail the bootstrapping and 186 constrained device use cases mentioned in the introduction. 188 3.1. Bootstrapping Devices 190 There are far more classes of clients being deployed on today's 191 networks than at any time previously. This poses challenges for 192 network administrators who need to mange their network and the 193 clients connecting to their network, and poses challenges for client 194 vendors and client software developers who must ensure that their 195 clients can connect to all required services. 197 One common example is where a client is deployed on a local domain 198 TCP/IP network that protects its perimeter using a TLS terminating 199 middlebox, and the client needs to establish a secure connection to a 200 service in a different network via the middlebox. This is 201 illustrated in Figure 1. 203 Traditionally, this has been enabled by the network administrator 204 deploying the necessary certificate authority trusted roots on the 205 client. This can be achieved at scale using standard tools that 206 enable the administrator to automatically push trusted roots out to 207 all client machines in the network from a centralized domain 208 controller. This works for for personal computers, laptops and 209 servers running standard Operating Systems that can be centrally 210 managed. This client management process breaks for multiple classes 211 of clients that are being deployed today, there is no standard 212 mechanism for configuring trusted roots on these clients, and there 213 is no standard mechanism for these clients to securely traverse 214 middleboxes. 216 +--------+ C->M TLS +-----------+ M->S TLS +---------+ 217 | Client |--------------->| Middlebox |------------->| Service | 218 +--------+ +-----------+ +---------+ 219 ^ ^ 220 | | 221 +-----------Client to Service ATLS Connection---------+ 223 Figure 1: Bootstrapping Devices 225 The ATLS mechanism defined in this document enables clients to 226 traverse middleboxes and establish secure connections to services 227 across network domain boundaries. The purpose of this connection may 228 simply be to facilitate a bootstrapping process, for example 229 [I-D.ietf-anima-bootstrapping-keyinfra], whereby the client securely 230 discovers the local domain certificate authorities required to 231 establish a trusted network layer TLS connection to the middlebox. 233 3.2. Constrained Devices 235 Two constrained device use cases are outlined here. 237 3.2.1. Constrained Device Connecting over a Closed Network 239 There are industry examples of home smart lighting systems where the 240 smart light bulbs connect using ZigBee to a gateway device. A 241 controller application running on a mobile device connects to the 242 gateway using CoAP over DTLS. The controller can then control the 243 light bulbs by sending messages and commands via the gateway. The 244 gateway device has full access to all messages sent between the light 245 bulbs and the controller application. 247 A generic use case similar to the smart lighting system outlined 248 above has an IoT device talking ZigBee to a gateway, with the gateway 249 in turn talking CoAP over DTLS to a controller application running on 250 a mobile device. This is illustrated in Figure 2. 252 There are scenarios where the messages sent between the IoT device 253 and the controller application must not be exposed to the gateway 254 function. Additionally, the end devices (the IoT device and the 255 controller application service) have no visibility to and no 256 guarantees about what transport layer security and encryption is 257 enforced across all hops end-to-end as they only have visibility to 258 their immediate next hop. ATLS addresses these concerns. 260 +--------+ ZigBee +---------+ CoAP/DTLS +------------+ 261 | Device |-------------->| Gateway |------------->| Mobile App | 262 +--------+ +---------+ +------------+ 263 ^ ^ 264 | | 265 +--------Device to Mobile App ATLS Connection-------+ 267 Figure 2: IoT Closed Network Gateway 269 3.2.2. Constrained Device Connecting over the Internet 271 A somewhat similar example has an IoT device connecting to a gateway 272 using a suitable transport mechanism such as ZigBee, CoAP, MQTT, etc. 273 The gateway function in turn talks HTTP over TLS (or, for example, 274 HTTP over QUIC) to an application service over the Internet. This is 275 illustrated in Figure 3. 277 The gateway may not be trusted and all messages between the IoT 278 device and the application service must be end-to-end encrypted. 279 Similar to the previous use case, the endpoints have no guarantees 280 about what level of transport layer security is enforced across all 281 hops. Again, ATLS addresses these concerns. 283 +--------+ CoAP/DTLS +------------------+ HTTP/TLS +---------+ 284 | Device |-------------->| Internet Gateway |------------>| Service | 285 +--------+ +------------------+ +---------+ 286 ^ ^ 287 | | 288 +---------Device to Cloud Service ATLS Connection----------+ 290 Figure 3: IoT Internet Gateway 292 4. Current Approaches to Application Layer End-to-End Security 294 End-to-end security at the application layer is increasing seen as a 295 key requirement across multiple applications and services. Some 296 examples of end-to-end security mechanisms are outlined here. All 297 the solutions outlined here have some common characteristics. The 298 solutions: 300 o do not rely on transport layer security 302 o define a new handshake protocol for establishment of a secure end- 303 to-end session 305 4.1. Noise 307 [Noise] is a framework for cryptographic protocols based on Elliptic 308 Curve Diffie-Hellman (ECDH) key agreement, AEAD encryption, and 309 BLAKE2 and SHA2 hash functions. Noise is currently used by WhatsApp, 310 WireGuard, and Lightning. 312 The current Noise protocol framework defines mechanisms for proving 313 possession of a private key, but does not define authentication 314 mechanisms. Section 14 "Security Considerations" of Noise states: 315 ~~~ it's up to the application to determine whether the remote 316 party's static public key is acceptable ~~~ 318 4.2. Signal 320 The [Signal] protocol provides end-to-end encryption and uses EdDSA 321 signatures, Triple Diffie-Hellman handshake for shared secret 322 establishment, and the Double Ratchet Algorithm for key management. 323 It is used by Open Whisper Systems, WhatsApp and Google. 325 Similar to Noise, Signal does not define an authentication mechanism. 326 The current [X3DH] specification states in section 4.1 327 "Authentication": 329 Methods for doing this are outside the scope of this document 331 4.3. Google ALTS 333 Google's Application Layer Transport Security [ALTS] is a mutual 334 authentication and transport encryption system used for securing 335 Remote Procedure Call (RPC) communications within Google's 336 infrastructure. ALTS uses an ECDH handshake protocol and a record 337 protocol containing AES encrypted payloads. 339 4.4. Ephemeral Diffie-Hellman Over COSE 341 There is ongoing work to standardise [I-D.selander-ace-cose-ecdhe]. 342 This defines a ECDH SIGMA based authenticated key exchange algorithm 343 using COSE and COBR objects. 345 5. ATLS Goals 347 The high level goals driving the design of this mechanism are: 349 o enable authenticated key exchange at the application layer by 350 reusing existing technologies 352 o ensure that ATLS packets are explicitly identified thus ensuring 353 that any middleboxes or gateways at the transport layer are 354 content aware 356 o leverage existing TLS stacks and handshake protocols thus avoiding 357 introducing new software or protocol dependencies in clients and 358 applications 360 o reuse existing TLS [RFC5246] [I-D.ietf-tls-tls13] and DTLS 361 [RFC6347] [I-D.ietf-tls-dtls13] specifications as is without 362 requiring any protocol changes or software stack changes 364 o do not mandate constraints on how the TLS stack is configured or 365 used 367 o be forward compatible with future TLS versions 369 o avoid introducing TLS protocol handling logic or semantics into 370 the application layer i.e. TLS protocol knowledge and logic is 371 handled by the TLS stack, not the application 373 o ensure the client and server software implementations are as 374 simple as possible 376 6. Architecture Overview 378 6.1. Application Architecture 380 TLS software stacks allow application developers to 'unplug' the 381 default network socket transport layer and read and write TLS records 382 directly from byte buffers. This enables application developers to 383 create application layer TLS sessions, extract the raw TLS record 384 bytes from the bottom of the TLS stack, and transport these bytes 385 over any suitable transport. The TLS software stacks can generate 386 byte streams of full TLS flights which may include multiple TLS 387 records. Additionally, TLS software stacks support Keying Material 388 Exporters [RFC5705] and allow applications to export keying material 389 from established TLS sessions. This keying material can then be used 390 by the application for encryption of data outside the context of the 391 TLS session. This is illustrated in Figure 4 below. 393 +------------+ +---------+ 394 Handshake Records | | Handshake Records | | 395 ------------------->| |------------------->| | 396 | | | Byte | 397 Unencrypted Data | TLS | Encrypted Data | | 398 ------------------->| |------------------->| Buffers | 399 | Software | | | 400 Encrypted Data | | Unencrypted Data | | 401 ------------------->| Stack |------------------->| | 402 | | +---------+ 403 Keying Material | | 404 <-------------------| | 405 + -----------+ 407 Figure 4: TLS Stack Interfaces 409 These TLS software stack APIs enable application developers to build 410 the software architectures illustrated in Figure 5 and Figure 6. 412 In both architectures, the application creates and interacts with an 413 application layer TLS session in order to generate and consume raw 414 TLS records. The application transports these raw TLS records inside 415 transport layer message bodies using whatever standard transport 416 layer stack is suitable for the application or architecture. This 417 document does not place any restrictions on the choice of transport 418 layer and any suitable protocol such as HTTP, TCP, CoAP, ZigBee, 419 Bluetooth, etc. could be used. 421 The transport layer will typically encrypt data, and this encryption 422 is completely independent from any application layer encryption. The 423 transport stack may create a transport layer TLS session. The 424 application layer TLS session and transport layer TLS session can 425 both leverage a shared, common TLS software stack. This high level 426 architecture is applicable to both clients and application services. 427 The key differences between the architectures are as follows. 429 In the model illustrated in Figure 5, the application sends all 430 sensitive data that needs to be securely exchanged with the peer 431 application through the Application TLS session in order to be 432 encrypted and decrypted. All sensitive application data is thus 433 encoded within TLS records by the TLS stack, and these TLS records 434 are transmitted over the transport layer. 436 +-------------+ 437 | | App 438 | | Data +---------+ 439 | Application |<---------->| App | +---------+ 440 | | TLS | TLS |----->| TLS | 441 | | Records | Session | | Stack | 442 | +--->|<---------->| | +---------+ 443 | | | +---------+ ^ 444 | | | |? 445 | | | Transport +-----------+ +------------+ 446 | | | Payload | Transport | | Transport | 447 | +--->|<--------->| Stack |--->| Encryption |-->Packets 448 +-------------+ +-----------+ +------------+ 450 Figure 5: TLS Stack used for all data encryption 452 In the model illustrated in Figure 6, the application establishes an 453 application layer TLS session purely for the purposes of key 454 exchange. Therefore, the only TLS records that are sent or received 455 by the application layer are TLS handshake records. Once the 456 application layer TLS session is established, the application uses 457 Keying Material Exporter [RFC5705] APIs to export keying material 458 from the TLS stack from this application layer TLS session. The 459 application can then use these exported keys to derive suitable 460 shared encryption keys with its peer for exchange of encrypted data. 461 The application encrypts and decrypts sensitive data using these 462 shared encryption keys using any suitable cryptographic library 463 (which may be part of the same library that provides the TLS stack), 464 and transports the encrypted data directly over the transport layer. 466 +--------------+ 467 | | 468 | Application | 469 | | 470 | +-------+ | +---------+ 471 | | App | | Key Export | | 472 | | Data |<---|<-----------| | 473 | | Crypto| | | App | 474 | +-------+ | TLS | TLS | +---------+ 475 | ^ | Handshake | Session |----->| TLS | 476 | | | Records | | | Stack | 477 | | +--->|<---------->| | +---------+ 478 | | | | +---------+ ^ 479 | | | | |? 480 | | | | Transport +-----------+ +------------+ 481 | | | | Payload | Transport | | Transport | 482 | +----+--->|<--------->| Stack |--->| Encryption |-->Packets 483 +--------------+ +-----------+ +------------+ 485 Figure 6: TLS stack used for key agreement and exporting 487 The choice of which application architecture to use will depend on 488 the overall solution architecture, and the underlying transport layer 489 or layers in use. While the choice of application architecture is 490 outside the scope of this document, some considerations are outlined 491 here. 493 o for constrained devices, every single byte of payload is 494 important. [I-D.mattsson-core-security-overhead] analyses the 495 overhead of TLS headers compared with OSCORE 496 [I-D.ietf-core-object-security] illustrating the additional 497 overhead associated with TLS headers. It may be more appropriate 498 to use the architecture defined in Figure 6 in order to establish 499 shared encryption keys, and then transport encrypted data directly 500 without the overhead of unwanted TLS record headers. 502 o when using HTTP as a transport layer, it may be more appropriate 503 to use the architecture defined in Figure 6 in order to avoid any 504 TLS session vs. HTTP session affinity issues. 506 6.1.1. Application Architecture Benefits 508 There are several benefits to using a standard TLS software stack to 509 establish an application layer secure communications channel between 510 a client and a service. These include: 512 o no need to define a new cryptographic negotiation and exchange 513 protocol between client and service 515 o automatically benefit from new cipher suites by simply upgrading 516 the TLS software stack 518 o automatically benefit from new features, bugfixes, etc. in TLS 519 software stack upgrades 521 6.1.2. ATLS Packet Identification 523 It is recommended that ATLS packets are explicitly identified by a 524 standardized, transport-specific identifier enabling any gateways and 525 middleboxes to identify ATLS packets. Middleboxes have to contend 526 with a vast number of applications and network operators have 527 difficulty configuring middleboxes to distinguish unencrypted but not 528 explicitly identified application data from end-to-end encrypted 529 data. This specification aims to assist network operators by 530 explicitly identifyng ATLS packets. The HTTP and CoAP encodings 531 documented in Section 9 and Section 10 explicitly identify ATLS 532 packets. 534 6.1.3. ATLS Session Tracking 536 The ATLS application service establishes multiple ATLS sessions with 537 multiple clients. As TLS sessions are stateful, the application 538 service must be able to correlate ATLS records from different clients 539 across the relevant ATLS sessions. The details of how session 540 tracking is implemented are outside the scope of this document. 541 Recommendations are given in Section 9 and Section 10, but session 542 tracking is application and implementation specific. 544 6.1.4. ATLS Record Inspection 546 It should not be necessary for the application layer to have to 547 inspect, parse or understand the contents of ATLS records. No 548 constraints are placed on the ContentType contained within the 549 transported TLS records. The TLS records may contain handshake, 550 application_data, alert or change_cipher_spec messages. If new 551 ContentType messages are defined in future TLS versions, these may 552 also be transported using this protocol. 554 6.1.5. Implementation 556 Pseudo code illustrating how to read and write TLS records directly 557 from byte buffers using both OpenSSL BIO functions and Java JSSE 558 SSLEngine is given in the appendices. A blog post by [Norrell] 559 outlines a similar approach to leveraging OpenSSL BIO functions, and 560 Oracle publish example code for leveraging [SSLEngine]. 562 6.2. Functional Design 564 [ todo: insert Hannes functional design section here including the 565 policy layers ] 567 Policy examples: 569 Mention that the app layer policy could be to not do ATLS if the 570 transport layer establishes an e2e session with the peer. e.g. for 571 HTTP use cases where there is no middlebox and cert validation 572 passes. 574 Mention that the client could report in the ATLS session any 575 middlebox cert seen at the transport layer. 577 6.3. Network Architecture 579 An example network deployment is illustrated in Figure 7. It shows a 580 constrained client connecting to an application service via an 581 internet gateway. The client uses CoAP over DTLS to communicate with 582 the gateway. The gateway extracts the messages the client sent over 583 CoAP and sends these messages inside HTTP message bodies to the 584 application service. It also shows a TLS terminator deployed in 585 front of the application service. The client establishes a transport 586 layer CoAP/DTLS connection with the gateway (C->G DTLS), the gateway 587 in turn opens a transport layer TLS connection with the TLS 588 terminator deployed in front of the service (G->T TLS). The client 589 can ignore any certificate validation errors when it connects to the 590 gateway. CoAP messages are transported between the client and the 591 gateway, and HTTP messages are transported between the client and the 592 service. Finally, application layer TLS messages are exchanged 593 inside the CoAP and HTTP message bodies in order to establish an end- 594 to-end TLS session between the client and the service (C->S TLS). 596 +----------+ +----------+ 597 | App Data | | App Data | 598 +----------+ +----------+ +----------+ 599 | C->S TLS | | C->S TLS | | App Data | 600 +----------+ +----------+ +----------+ 601 | CoAP | | HTTP | | C->S TLS | 602 +----------+ +----------+ +----------+ 603 | C->G DTLS| | M->T TLS | | HTTP | 604 +----------+ +----------+ +----------+ 605 | UDP | | TCP | | TCP | 606 +----------+ +----------+ +----------+ 608 +--------+ +-----------+ +----------------+ +---------+ 609 | Client |----->| Gateway |----->| TLS Terminator |---->| Service | 610 +--------+ +-----------+ +----------------+ +---------+ 611 ^ ^ 612 | | 613 +-------------Client to Service ATLS Connection-------------+ 615 Figure 7: Constrained Device Gateway Network Architecture 617 Another typical network deployment is illustrated in Figure 8. It 618 shows a client connecting to a service via a middlebox. It also 619 shows a TLS terminator deployed in front of the service. The client 620 establishes a transport layer TLS connection with the middlebox (C->M 621 TLS), the middlebox in turn opens a transport layer TLS connection 622 with the TLS terminator deployed in front of the service (M->T TLS). 623 The client can ignore any certificate validation errors when it 624 connects to the middlebox. HTTP messages are transported over this 625 layer between the client and the service. Finally, application layer 626 TLS messages are exchanged inside the HTTP message bodies in order to 627 establish an end-to-end TLS session between the client and the 628 service (C->S TLS). 630 +----------+ +----------+ 631 | App Data | | App Data | 632 +----------+ +----------+ +----------+ 633 | C->S TLS | | C->S TLS | | App Data | 634 +----------+ +----------+ +----------+ 635 | HTTP | | HTTP | | C->S TLS | 636 +----------+ +----------+ +----------+ 637 | C->M TLS | | M->T TLS | | HTTP | 638 +----------+ +----------+ +----------+ 639 | TCP | | TCP | | TCP | 640 +----------+ +----------+ +----------+ 642 +--------+ +-----------+ +----------------+ +---------+ 643 | Client |----->| Middlebox |----->| TLS Terminator |---->| Service | 644 +--------+ +-----------+ +----------------+ +---------+ 645 ^ ^ 646 | | 647 +-------------Client to Service ATLS Connection-------------+ 649 Figure 8: HTTP Middlebox Network Architecture 651 7. Key Exporting and Application Data Encryption 653 When solutions implement the architecture described in Figure 6, they 654 leverage [RFC5705] for key exporting from the ATLS session. The 655 client and service then use the exported keys to derive shared 656 encryption keys. The encryption keys are then used with a suitable 657 cipher suite to encrypt application data for exchange with the peer. 659 7.1. Key Exporter Label 661 A new TLS Exporter Label is defined for ATLS key exporting. Its 662 value is: 664 TLS Exporter Label: application-layer-tls 666 7.2. Cipher Suite Selection 668 Application layer encryption performed outside the context of the 669 ATLS session using exported keys should use the cipher suite 670 negotiated during ATLS session establishment. 672 7.3. Key Derivation 674 [RFC5705] key exporting functions allow specification of the number 675 of bytes of keying material that should be exported from the TLS 676 session. The application should export the exact number of bytes 677 required to generate the necessary client and server cipher suite 678 encryption key and IV values. 680 Maybe need to reference the relevant sections from 681 https://tools.ietf.org/html/draft-ietf-tls-tls13-23#section-7 and 682 https://tools.ietf.org/html/rfc5246#section-6.3. 684 8. ATLS Session Establishment 686 Figure 9 illustrates how an ATLS session is established using the key 687 exporting architectural model shown in Figure 6. The outline is as 688 follows: 690 o the client creates an ATLS session object 692 o the client initiates a TLS handshake on the session 694 o the client extracts the TLS records for the first TLS flight (the 695 first RTT) 697 o the client sends the TLS records over the transport layer to the 698 server 700 o on receipt of the TLS flight, the server creates an ATLS session 701 object 703 o the server injects the received TLS flight into the session 705 o the server extracts the TLS records for the first TLS flight 706 response 708 o the server sends the TLS response records over the transport layer 709 to the client 711 o the client injects the received TLS records into its TLS session 712 completing the first full RTT 714 o the client and server repeat the above process and complete the 715 second RTT 717 o once the ATLS session is up, both sides export keying material 719 o both sides now can exchange data encrypted using shared keys 720 derived from the keying material 722 +-------------------------------+ +-------------------------------+ 723 | Client | | ATLS Server | 724 +---------+---+-----+---+-------+ +-------+---+-----+---+---------+ 725 | ATLS | | App | |Transport| |Transport| | App | | ATLS | 726 | Session | +-----+ | Stack | | Stack | +-----+ | Session | 727 +---------+ | +---------+ +---------+ | +---------+ 728 | | | | | | 729 | | | | | | 730 | | | | | | 731 | Create | | | | | 732 | Session | | | | | 733 + |<---------| | | | | 734 | | Start | | | | | 735 | | Handshake| | | | | 736 | |<---------| | | | | 737 | | TLS | | | | | 738 | | Records | Pack | | | | 739 | |--------->| Records | | | | 740 | |-------->| send packet | Unpack | | 741 R | | |------------>| Records | Create | 742 T | | | |--------->| Session | 743 T | | | | |--------->| 744 | | | | | TLS | 745 1 | | | | | Records | 746 | | | | |--------->| 747 | | | | | | TLS | 748 | | | | | Pack | Records | 749 | | | | | Records |<---------| 750 | | | Unpack |send response|<---------| | 751 | | TLS | Records |<------------| | | 752 | | Records |<--------| | | | 753 + |<---------| | | | | 754 | TLS | | | | | 755 | Records | | | | | 756 + |--------->|-------->|------------>|--------->|--------->| 757 | | | | | | | 758 | | | | | Session | 759 R | | | | | Up | 760 T | | | | |<---------| 761 T | | | | | TLS | 762 | | | | | Records | 763 2 |<---------|<--------|<------------|<---------|<---------| 764 | Session | | | | | 765 | | Up | | | | | 766 + |--------->| | | | | 767 | Export | | | | Export | 768 | Keys | | | | Keys | 769 |--------->| | E2E Session | |<---------| 770 | |<--------|-------------|--------->| | 772 Figure 9: ATLS Session Establishment 774 9. ATLS over HTTP Transport 776 The assumption is that the client will establish a transport layer 777 connection to the server for exchange of HTTP messages. The 778 underlying transport layer connection could be over TCP or TLS. The 779 client will then establish an application layer TLS connection with 780 the server by exchanging TLS records with the server inside HTTP 781 message request and response bodies. 783 9.1. Protocol Summary 785 All ATLS records are transported unmodified as binary data within 786 HTTP message bodies. The application simply extracts the TLS records 787 from the TLS stack and inserts them directly into HTTP message 788 bodies. Each message body contains a full TLS flight, which may 789 contain multiple TLS records. 791 The client sends all ATLS records to the server in the bodies of POST 792 requests. 794 The server sends all ATLS records to the client in the bodies of 200 795 OK responses to the POST requests. 797 9.2. Content-Type Header 799 A new Content-Type header value is defined: 801 Content-type: application/atls+octet-stream 803 All message bodies containing ATLS records must set this Content- 804 Type. This enables middleboxes to readily identify ATLS payloads. 806 9.3. HTTP Status Codes 808 Thsi document does not define any new HTTP status codes, and does not 809 specify additional semantics or refine existing semantics for status 810 codes. This is the best current practice as outlined in 811 [I-D.ietf-httpbis-bcp56bis]. 813 9.4. ATLS Session Tracking 815 The application service needs to track multiple client application 816 layer TLS sessions so that it can collerate TLS records received in 817 HTTP message bodies with the appropriate TLS session. The 818 application service should use stateful cookies [RFC6265] in order to 819 achieve this as recommended in [I-D.ietf-httpbis-bcp56bis]. 821 9.5. Session Establishment and Key Exporting 823 It is recommended that applications using ATLS over HTTP transport 824 only use ATLS for session establishment and key exchange, resulting 825 in only 2 ATLS RTTs between the client and the application service. 827 Key exporting must be carried out as described in Section 7.3. 829 9.6. Application Data Encryption 831 [editors note: I am on the fence about using [RFC8188] as this 832 hardcodes the ciphersuite to aes128gcm. It would be nice to use the 833 cipher suite negotiated as part of ATLS session establishment. ] 835 9.7. Illustrative ATLS over HTTP Session Establishment 837 A client initiates an ATLS session by sending the first TLS flight in 838 a POST request message body to the ATLS server. 840 POST /atls 841 Content-Type: application/atls+octet-stream 843 845 The server handles the request, creates an ATLS session object, and 846 replies by including its first TLS flight in a 200 OK message body. 847 The server also sets a suitable cookie for session tracking purposes. 849 200 OK 850 Content-Type: application/atls+octet-stream 851 Set-Cookie: my-atls-cookie=my-cookie-value 853 855 The client handles the server first flight TLS records and replies 856 with its second flight. 858 POST /atls 859 Content-Type: application/atls+octet-stream 860 Cookie: my-atls-cookie=my-cookie-value 862 864 The server handles the second flight, establishes the ATLS session, 865 and replies with its second flight. 867 200 OK 868 Content-Type: application/atls+octet-stream 870 872 9.8. ATLS and HTTP CONNECT 874 It is worthwhile comparing and contrasting ATLS with HTTP CONNECT 875 tunneling. 877 First, let us introduce some terminology: 879 o HTTP Proxy: A HTTP Proxy operates at the application layer, 880 handles HTTP CONNECT messages from clients, and opens tunnels to 881 remote origin servers on behalf of clients. If a client 882 establishes a tunneled TLS connection to the origin server, the 883 HTTP Proxy does not attempt to intercept or inspect the HTTP 884 messages exchanged between the client and the server 886 o middlebox: A middlebox operates at the transport layer, terminates 887 TLS connections from clients, and originates new TLS connections 888 to services. A middlebox inspects all messages sent between 889 clients and services. Middleboxes are generally completely 890 transparent to applications, provided that the necessary PKI root 891 Certificate Authority is installed in the client's trust store. 893 HTTP Proxies and middleboxes are logically separate entities and one 894 or both of these may be deployed in a network. 896 HTTP CONNECT is used by clients to instruct a HTTP Forward Proxy 897 deployed in the local domain to open up a tunnel to a remote origin 898 server that is typically deployed in a different domain. Assuming 899 that TLS transport is used between both client and proxy, and proxy 900 and origin server, the network architecture is as illustrated in 901 Figure 10. Once the proxy opens the transport tunnel to the service, 902 the client establishes an end-to-end TLS session with the service, 903 and the proxy is blindly transporting TLS records (the C->S TLS 904 session records) between the client and the service. From the client 905 perspective, it is tunneling a TLS session to the service inside the 906 TLS session it has established to the proxy (the C->P TLS session). 907 No middlebox is attempting to intercept or inspect the HTTP messages 908 between the client and the service. 910 +----------+ +----------+ 911 | C->S HTTP| | C->S HTTP| 912 +----------+ +----------+ 913 | C->S TLS | | C->S TLS | 914 +----------+ +----------+ 915 | C->P TLS | | P->S TCP | 916 +----------+ +----------+ 917 | C->P TCP | 918 +----------+ 920 +--------+ +------------+ +---------+ 921 | Client |----->| HTTP Proxy |----->| Service | 922 +--------+ +------------+ +---------+ 924 Figure 10: HTTP Proxy transport layers 926 A more complex network topology where the network operator has both a 927 HTTP Proxy and a middlebox deployed is illustrated in Figure 11. In 928 this scenario, the proxy has tunneled the TLS session from the client 929 towards the origin server, however the middlebox is intercepting and 930 terminating this TLS session. A TLS session is established between 931 the client and the middlebox (C->M TLS), and not end-to-end between 932 the client and the server. It can clearly be seen that HTTP CONNECT 933 and HTTP Proxies serve completely different functions than 934 middleboxes. 936 Additionally, the fact that the TLS session is established between 937 the client and the middlebox can be problematic for two reasons: 939 o the middle box is inspecting traffic that is sent between the 940 client and the service 942 o the client may not have the necessary PKI root Certificate 943 Authority installed that would enable it to validate the TLS 944 connection to the middlebox. This is the scenario outlined in 945 Section 3.1. 947 +----------+ +----------+ +----------+ 948 | C->S HTTP| | C->S HTTP| | C->S HTTP| 949 +----------+ +----------+ +----------+ 950 | C->M TLS | | C->M TLS | | M->S TLS | 951 +----------+ +----------+ +----------+ 952 | C->P TLS | | P->M TCP | | M->S TCP | 953 +----------+ +----------+ +----------+ 954 | C->P TCP | 955 +----------+ 957 +--------+ +------------+ +-----------+ +---------+ 958 | Client |----->| HTTP Proxy |----->| Middlebox |----->| Service | 959 +--------+ +------------+ +-----------+ +---------+ 961 Figure 11: HTTP Proxy and middlebox transport layers 963 As HTTP CONNECT can be used to establish a tunneled TLS connection, 964 one hypothetical solution to this middlebox issue is for the client 965 to issue a HTTP CONNECT command to a HTTP Reverse Proxy deployed in 966 front of the origin server. This solution is not practical for 967 several reasons: 969 o if there is a local domain HTTP Forward Proxy deployed, this would 970 result in the client doing a first HTTP CONNECT to get past the 971 Forward Proxy, and then a second HTTP CONNECT to get past the 972 Reverse Proxy. No client or client library supports the concept 973 of HTTP CONNECT inside HTTP CONNECT. 975 o if there is no local domain HTTP Proxy deployed, the client still 976 has to do a HTTP CONNECT to the HTTP Reverse Proxy. This breaks 977 with standard and expected HTTP CONNECT operation, as HTTP CONNECT 978 is only ever called if there is a local domain proxy. 980 o clients cannot generate CONNECT from XHR in web applications. 982 o this would require the deployment of a Reverse Proxy in front of 983 the origin server, or else support of the HTTP CONNECT method in 984 standard web frameworks. This is not an elegant design. 986 o using HTTP CONNECT with HTTP 1.1 to a Reverse Proxy will break 987 middleboxes inspecting HTTP traffic, as the middlebox would see 988 TLS records when it expects to see HTTP payloads. 990 In contrast to trying to force HTTP CONNECT to address a problem for 991 which it was not designed to address, and having to address all the 992 issues just outlined; ATLS is specifically designed to address the 993 middlebox issue in a simple, easy to develop, and easy to deploy 994 fashion. 996 o ATLS works seamlessly with HTTP Proxy deployments 998 o no changes are required to HTTP CONNECT semantics 1000 o no changes are required to HTTP libraries or stacks 1002 o no additional Reverse Proxy is required to be deployed in front of 1003 origin servers 1005 It is also worth noting that if HTTP CONNECT to a Reverse Proxy were 1006 a conceptually sound solution, the solution still ultimately results 1007 in encrypted traffic traversing the middlebox that the middlebox 1008 cannot intercept and inspect. That is ultimately what ATLS results 1009 in - traffic traversing the middle box that the middlebox cannot 1010 intercept and inspect. Therefore, from a middlebox perspective, the 1011 differences between the two solutions are in the areas of solution 1012 complexity and protocol semantics. It is clear that ATLS is a 1013 simpler, more elegant solution that HTTP CONNECT. 1015 10. ATLS over CoAP Transport 1017 [ todo: Help needed Hannes ] 1019 11. RTT Considerations 1021 The number of RTTs that take place when establishing a TLS session 1022 depends on the version of TLS and what capabilities are enabled on 1023 the TLS software stack. For example, a 0-RTT exchange is possible 1024 with TLS1.3. 1026 If applications wish to ensure a predictable number of RTTs when 1027 establishing an application layer TLS connection, this may be 1028 achieved by configuring the TLS software stack appropriately. 1029 Relevant configuration parameters for OpenSSL and Java SunJSSE stacks 1030 are outlined in the appendix. 1032 12. IANA Considerations 1034 [[ TODO - New Content-Type and TLS Exporter Label must be registered. 1035 ]] 1037 13. Security Considerations 1039 [[ TODO ]] 1041 14. Appendix A. TLS Software Stack Configuration 1043 [[ EDITOR'S NOTE: We could include details here on how TLS stack 1044 configuration items control the number of round trips between the 1045 client and server. 1046 And just give two examples: OpenSSL and Java SunJSSE]] 1048 15. Appendix B. Pseudo Code 1050 This appendix gives both C and Java pseudo code illustrating how to 1051 inject and extract raw TLS records from a TLS software stack. Please 1052 not that this is illustrative, non-functional pseudo code that does 1053 not compile. Functioning proof-of-concept code is available on the 1054 following public repository [[ EDITOR'S NOTE: Add the URL here ]]. 1056 15.1. B.1 OpenSSL 1058 OpenSSL provides a set of Basic Input/Output (BIO) APIs that can be 1059 used to build a custom transport layer for TLS connections. This 1060 appendix gives pseudo code on how BIO APIs could be used to build a 1061 client application that completes a TLS handshake and exchanges 1062 application data with a service. 1064 char inbound[MAX]; 1065 char outbound[MAX]; 1066 int rx_bytes; 1067 SSL_CTX *ctx = SSL_CTX_new(); 1068 SSL *ssl = SSL_new(ctx); 1070 // Create in-memory BIOs and plug in to the SSL session 1071 BOI* bio_in = BIO_new(BIO_s_mem()); 1072 BOI* bio_out = BIO_new(BIO_s_mem()); 1073 SSL_set_bio(ssl, bio_in, bio_out); 1075 // We are a client 1076 SSL_set_connect_state(ssl); 1078 // Loop through TLS flights until we are done 1079 do { 1080 // Calling SSL_do_handshake() will result in a full 1081 // TLS flight being written to the BIO buffer 1082 SSL_do_handshake(ssl); 1084 // Read the client flight that the TLS session 1085 // has written to memory 1086 BIO_read(bio_out, outbound, MAX); 1088 // POST the outbound bytes to the server using a suitable 1089 // function. Lets assume that the server response will be 1090 // written to the 'inbound' buffer 1091 num_bytes = postTlsRecords(outbound, inbound); 1093 // Write the server flight to the memory BIO so the TLS session 1094 // can read it. The next call to SSL_do_handshake() will handle 1095 // this received server flight 1096 BIO_write(bio_in, inbound, num_bytes); 1098 } while (!SSL_is_init_finished(ssl)); 1100 // Send a message to the server. Calling SSL_write() will run the 1101 // plaintext through the TLS session and write the encrypted TLS 1102 // records to the BIO buffer 1103 SSL_write(ssl, "Hello World", strlen("Hello World")); 1105 // Read the TLS records from the BIO buffer and 1106 // POST them to the server 1107 BIO_read(bio_out, outbound, MAX); 1108 num_bytes = postTlsRecords(outbound, inbound); 1110 15.2. B.2 Java JSSE 1112 The Java SSLEngine class "enables secure communications using 1113 protocols such as the Secure Sockets Layer (SSL) or IETF RFC 2246 1114 "Transport Layer Security" (TLS) protocols, but is transport 1115 independent". This pseudo code illustrates how a server could use 1116 the SSLEngine class to handle an inbound client TLS flight and 1117 generate an outbound server TLS flight response. 1119 SSLEngine sslEngine = SSLContext.getDefault().createSSLEngine(); 1120 sslEngine.setUseClientMode(false); 1121 sslEngine.beginHandshake(); 1123 // Lets assume 'inbound' has been populated with 1124 // the Client 1st Flight 1125 ByteBuffer inbound; 1127 // 'outbound' will be populated with the 1128 // Server 1st Flight response 1129 ByteBuffer outbound; 1131 // SSLEngine handles one TLS Record per call to unwrap(). 1132 // Loop until the engine is finished unwrapping. 1133 while (sslEngine.getHandshakeStatus() == 1134 HandshakeStatus.NEED_UNWRAP) { 1135 SSLEngineResult res = sslEngine.unwrap(inbound, outbound); 1137 // SSLEngine may need additional tasks run 1138 if (res.getHandshakeStatus() == NEED_TASK) { 1139 Runnable run = sslEngine.getDelegatedTask(); 1140 run.run(); 1141 } 1142 } 1144 // The SSLEngine has now finished handling all inbound TLS Records. 1145 // Check if it wants to generate outbound TLS Records. SSLEngine 1146 // generates one TLS Record per call to wrap(). 1147 // Loop until the engine is finished wrapping. 1148 while (sslEngine.getHandshakeStatus() == 1149 HandshakeStatus.NEED_WRAP) { 1150 SSLEngineResult res = sslEngine.wrap(inbound, outbound); 1152 // SSLEngine may need additional tasks run 1153 if (res.getHandshakeStatus() == NEED_TASK) { 1154 Runnable run = sslEngine.getDelegatedTask(); 1155 run.run(); 1156 } 1157 } 1159 // outbound ByteBuffer now contains a complete server flight 1160 // containing multiple TLS Records 1161 // Rinse and repeat! 1163 16. Appendix C. Example ATLS Handshake 1165 [[ EDITOR'S NOTE: For completeness, include a simple full TLS 1166 handshake showing the B64 encoded flights in JSON, along with the 1167 HTTP request/response/headers. And also the raw hex TLS records 1168 showing protocol bits ]] 1170 17. Informative References 1172 [ALTS] Google, "Application Layer Transport Security", December 1173 2017, . 1176 [Bluetooth] 1177 Bluetooth, "Bluetooth Core Specification v5.0", 2016, 1178 . 1180 [I-D.hartke-core-e2e-security-reqs] 1181 Selander, G., Palombini, F., and K. Hartke, "Requirements 1182 for CoAP End-To-End Security", draft-hartke-core-e2e- 1183 security-reqs-03 (work in progress), July 2017. 1185 [I-D.ietf-anima-bootstrapping-keyinfra] 1186 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1187 S., and K. Watsen, "Bootstrapping Remote Secure Key 1188 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1189 keyinfra-09 (work in progress), October 2017. 1191 [I-D.ietf-core-object-security] 1192 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1193 "Object Security for Constrained RESTful Environments 1194 (OSCORE)", draft-ietf-core-object-security-08 (work in 1195 progress), January 2018. 1197 [I-D.ietf-httpbis-bcp56bis] 1198 Nottingham, M., "On the use of HTTP as a Substrate", 1199 draft-ietf-httpbis-bcp56bis-00 (work in progress), 1200 December 2017. 1202 [I-D.ietf-tls-dtls13] 1203 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1204 Datagram Transport Layer Security (DTLS) Protocol Version 1205 1.3", draft-ietf-tls-dtls13-22 (work in progress), 1206 November 2017. 1208 [I-D.ietf-tls-tls13] 1209 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1210 Version 1.3", draft-ietf-tls-tls13-23 (work in progress), 1211 January 2018. 1213 [I-D.mattsson-core-security-overhead] 1214 Mattsson, J., "Message Size Overhead of CoAP Security 1215 Protocols", draft-mattsson-core-security-overhead-02 (work 1216 in progress), November 2017. 1218 [I-D.selander-ace-cose-ecdhe] 1219 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 1220 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 1221 cose-ecdhe-07 (work in progress), July 2017. 1223 [LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine 1224 Requirements", December 2017, 1225 . 1227 [Noise] Perrin, T., "Noise Protocol Framework", October 2017, 1228 . 1230 [Norrell] Norrell, ., "Use SSL/TLS within a different protocol with 1231 BIO pairs", 2016, 1232 . 1235 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1236 (TLS) Protocol Version 1.2", RFC 5246, 1237 DOI 10.17487/RFC5246, August 2008, . 1240 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1241 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1242 March 2010, . 1244 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1245 DOI 10.17487/RFC6265, April 2011, . 1248 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1249 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1250 January 2012, . 1252 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1253 Protocol (HTTP/1.1): Message Syntax and Routing", 1254 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1255 . 1257 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1258 Application Protocol (CoAP)", RFC 7252, 1259 DOI 10.17487/RFC7252, June 2014, . 1262 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1263 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1264 DOI 10.17487/RFC7540, May 2015, . 1267 [RFC8188] Thomson, M., "Encrypted Content-Encoding for HTTP", 1268 RFC 8188, DOI 10.17487/RFC8188, June 2017, 1269 . 1271 [Signal] Open Whisper Systems, "Signal Protocol", 2016, 1272 . 1274 [SSLEngine] 1275 Oracle, "SSLEngineSimpleDemo.java", 2004, . 1279 [ZigBee] ZigBee Alliance, "ZigBee Specification", 2012, 1280 . 1282 Authors' Addresses 1284 Owen Friel 1285 Cisco 1287 Email: ofriel@cisco.com 1289 Richard Barnes 1290 Cisco 1292 Email: rlb@ipv.sx 1294 Max Pritikin 1295 Cisco 1297 Email: pritikin@cisco.com 1298 Hannes Tschofenig 1299 ARM Limited 1301 Email: hannes.tschofenig@gmx.net 1303 Mark Baugher 1304 Consultant 1306 Email: mark@mbaugher.com