[Atlas] Application Transport LAyer Security (ATLAS) Charter Text

[Hannes Tschofenig <[e-mail]>]

Hi all,

Below you can find a first strawman proposal for the charter text of the ATLAS group. Following the discussions around the Singapore IETF meeting the idea is to have time at the London IETF meeting to find out whether there is enough interest but also where this work should happen (i.e., new group or an existing group).

As you can see from the available drafts (see below) the use cases cover the Web as well as IoT environments.

Ciao
Hannes

-------

Application Transport LAyer Security (ATLAS)

Charter for Working Group

The Transport Layer Security (TLS) protocol has been huge successful protocol in the market place and it is used by developers to secure connection-oriented as well as connection-less transport protocols. Under the hood, both TLS and DTLS consist of sub-protocols, namely the handshaking protocols and the record protocol. The handshaking protocols offer an authenticated key exchange protocol that establishes the necessary keys and parameters for protecting application data via the record protocol. Years have been spent in improving both protocols and particularly the more sophisticated handshaking protocols. Through standardization in the IETF TLS working group many extensions and ciphersuites have been published and implemented that allow TLS to be customized for different environment. This flexibility and the availability of source code is appreciated by developers writing web applications, smart phone apps, and also for securing backend communication. With the need to secure embedded devices communicating with the cloud-based infrastructure TLS and DTLS has even found traction in the Internet of Things (IoT) community.

TLS and DTLS sit between the transport layer, such as TCP and UDP, and the applications. Hence, TLS and DTLS offer protection of application traffic exchanged between the endpoints of the transport layer. There are, however, deployments where security protection needs to be applied beyond these two transport layer endpoints. Use cases include deployments where proxies terminate connections along the path or where devices transmit data first over a non-IP transport, such as Bluetooth Smart, before IP communication starts at the smart phone towards a cloud-based infrastructure.

There is a need to offer application layer security for communication that is session based, i.e., where communication establishment is followed by an exchange of an arbitrary number of application data. Securing one-shot payloads, such as firmware updates in an IoT context, is outside the scope of this work. This application layer security mechanism requires authentication of the endpoints, and a modern a key exchange protocol. The result of a positive handshake will lead to the establishment of keying material and negotiated algorithms for confidentiality, integrity and replay protection of application data.

Instead of re-designing a key exchange protocol this group will re-use the TLS handshaking protocols at the application layer for establishing keying material to protect application data.

This group will maintain a close relationship with the TLS working group as well as with relevant application and IoT-relevant working groups in the IETF.

Milestones

May 2018    Adopt "Architecture and Use Case" document as WG item

Jun 2018    Adopt "Application Layer TLS" specification as WG item.
            Currently available proposals include:

-   draft-schmertmann-dice-codtls-00

-   draft-bhattacharyya-dice-less-on-coap-00

-   draft-garcia-core-app-layer-sec-with-dtls-record-00

-   draft-tschofenig-layered-tls-00

-   draft-friel-tls-over-http-00

-   and https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security

Oct 2018    Submit "Architecture and Use Case" document to the IESG for publication as an Informational Standard.

Nov 2018    Submit "Application Layer TLS" specification to the IESG for publication as an Proposed Standard.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.