Re: [Atlas] Charter Text

I think HTTP is not something to work on, as HTTPS exists and this will only cause confusion.  Something more applicable might be SNMP or CoAP.

From: Carsten Bormann <cabo@tzi.org>
Date: Tuesday, February 6, 2018 at 4:48 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "atlas@ietf.org" <atlas@ietf.org>
Subject: Re: [Atlas] Charter Text

I still believe Jun 2018 is an impossible target, more so for BLE work. (and it's not "smart" any more).
Sent from mobile

On 6. Feb 2018, at 10:08, Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>> wrote:
Application Transport LAyer Security (ATLAS)
============================================

# Charter for Working Group

## Background

The Transport Layer Security (TLS) protocol has been a hugely successful security protocol 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. The IETF TLS working group published many extensions and ciphersuites so that TLS can 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.

## Problem Statement

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.

While application layer security mechanisms already exist, such as CMS, JOSE, and COSE offering protection of application data those are focused on one-shot message exchanges.
Securing one-shot payloads, such as firmware updates in an IoT context (such as work done in the IETF SUIT working group), is therefore outside the scope of this work.

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

The TLS protocol has also been used in environments not initially anticipated by the TLS authors, such as in EAP-TLS/EAP-TTLS for network access authentication where the TLS handshake is carried over EAP payloads. Furthermore, with DTLS-SRTP the DTLS handshake has been used to establish security associations for protecting RTP. As such, there is also a precedence for embedding TLS in "applications" (whereby EAP would be here the network access authentication application).

## Goal of this Group

This group will develop specifications that define embeddings for different application protocols, such as CoAP, HTTP, and Bluetooth Smart. Such embeddings come with appropriate security considerations. The group will also work on specifications that describe how to deriving keying material for protecting application payloads using JOSE and COSE.

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 Embedding in HTTP" specification as WG item

Jun 2018    Adopt "Application Layer TLS Embedding in CoAP" specification as WG item

Jun 2018    Adopt "Application Layer TLS Embedding in Bluetooth Smart" specification as WG item

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

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

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

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

# References:

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-friel-tls-atls-00

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.
_______________________________________________
Atlas mailing list
Atlas@ietf.org<mailto:Atlas@ietf.org>
https://www.ietf.org/mailman/listinfo/atlas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_atlas&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=njNAxyrfzDwrzrtyETvuLKnCTuH_KmwAYxNHvQM_F68&s=fgZeowldfUecrs7gFM2PNjqexSlQKvtnJ2gHYZ8Hhhk&e=>