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

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 06 February 2018 10:02 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
X-Original-To: atlas@ietfa.amsl.com
Delivered-To: atlas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B531241F5 for <atlas@ietfa.amsl.com>; Tue, 6 Feb 2018 02:02:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiMOQer2TeMH for <atlas@ietfa.amsl.com>; Tue, 6 Feb 2018 02:02:17 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0057.outbound.protection.outlook.com [104.47.1.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FBE12DA49 for <atlas@ietf.org>; Tue, 6 Feb 2018 02:02:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mTOeEnPDyx9t6FzLJra4OCg6ozLT/v9t+s/UAkD/Kb8=; b=pSuV8HiIa0TLQu900d61iUztulFKHXbiNg2kXoVRzLSAJOtkbzU96s3NjCiKK1T/roqFLudoU8vOngX+pkucDhr5o6lTj3RchxuVOC8AXEf5Aj6ZlYGdPoLVLWoPQ3ZM/D0XNAMJu35foTRAuBbwDYNeI3O+GoP89APbwb4RiBQ=
Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB1442.eurprd08.prod.outlook.com (10.168.5.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Tue, 6 Feb 2018 10:02:13 +0000
Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b863:80d:692b:e64b]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b863:80d:692b:e64b%14]) with mapi id 15.20.0464.015; Tue, 6 Feb 2018 10:02:13 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
CC: "atlas@ietf.org" <atlas@ietf.org>
Thread-Topic: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text
Thread-Index: AdOTwyPirW/e5/LOQWOr6hMZrGuG4wIH6BIAAAfsLsAApRt2gAAmhWcQ
Date: Tue, 06 Feb 2018 10:02:13 +0000
Message-ID: <AM4PR0801MB27064A1FCFFA8C1D242C0307FAFD0@AM4PR0801MB2706.eurprd08.prod.outlook.com>
References: <AM4PR0801MB2706895905D2634096D4A11BFAEC0@AM4PR0801MB2706.eurprd08.prod.outlook.com> <548BB4CB-78F1-4CA8-92D6-E7174D8B1D8A@tzi.org> <AM4PR0801MB2706D8559615536F8F794F73FAF90@AM4PR0801MB2706.eurprd08.prod.outlook.com> <49daa0f072df4a0096a4ba44e0fc9dd6@XCH-ALN-010.cisco.com>
In-Reply-To: <49daa0f072df4a0096a4ba44e0fc9dd6@XCH-ALN-010.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [88.214.163.190]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR0801MB1442; 7:zh+BFgwf09mduA08Dc/ZhvwUYYqe9q+6dr5lIAVB11PJhclX2SS96zwrENT5kXUYgBeAHz0wJFdkUnnM1PwWgWdaV1O5Dp5M3OJTmYDf41JH2LJaK5jCKCAZlEjwowwsmwgpuNZi1/AaJMP9sg9UqpYkYs27DNCqxGvdefQqHbxCkg4fEC5sLU9FOyF1Ln/XSRIuy3QdKa6XJtZcbRD3b6USoeF6nXe0n58U9/aB8rlb+9KMZ/GwFxU8nmGL5Bd7
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: f68ae2a1-9a73-4429-7cdc-08d56d48b23c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:AM4PR0801MB1442;
x-ms-traffictypediagnostic: AM4PR0801MB1442:
x-microsoft-antispam-prvs: <AM4PR0801MB144219C5CF9263422C9AD25AFAFD0@AM4PR0801MB1442.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(6055026)(6041288)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR0801MB1442; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0801MB1442;
x-forefront-prvs: 0575F81B58
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39850400004)(376002)(39380400002)(396003)(366004)(199004)(189003)(13464003)(40434004)(86362001)(72206003)(14454004)(478600001)(6916009)(4326008)(33656002)(966005)(15650500001)(3280700002)(561944003)(229853002)(53936002)(74316002)(6246003)(6306002)(93886005)(55016002)(7736002)(2950100002)(97736004)(3660700001)(99286004)(6436002)(305945005)(9686003)(6116002)(316002)(5660300001)(59450400001)(5250100002)(105586002)(3846002)(68736007)(5890100001)(2906002)(6506007)(53546011)(102836004)(7696005)(66066001)(76176011)(8936002)(81156014)(2900100001)(81166006)(26005)(106356001)(8676002)(25786009)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB1442; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: bDPrcKa0tlb7ALqY1iUpTKz9wDXoWMsbEwdHWF6yqStiS6+pq2prVqh+pRZgKVEHmvNw2hycdLgKWNJ5ZNx76Q==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f68ae2a1-9a73-4429-7cdc-08d56d48b23c
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 10:02:13.6924 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB1442
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/ouXkblTtBz1QZBZU_7-JpnySqzM>
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text
X-BeenThere: atlas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Application Transport LAyer Security <atlas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/atlas>, <mailto:atlas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/atlas/>
List-Post: <mailto:atlas@ietf.org>
List-Help: <mailto:atlas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/atlas>, <mailto:atlas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Feb 2018 10:02:21 -0000

Hi Panos,

There are clearly differences in terms of market demand for the different protocols. The Bluetooth Smart topic emerged in our discussions in the area of healthcare applications that happen to use devices supporting this technology. If I have to rank it according to importance then I would argue that the importance of Bluetooth Smart is lower than other protocols.

Regarding the question concerning draft-garcia-core-app-layer-sec-with-dtls-record you need to ask the authors of the document.

Your question regarding EDHOC: we are interested to do the work on application layer TLS particularly to solve a wider range of use cases than EDHOC/OSCORE without having to re-write a TLS-alike protocol from scratch, which is a huge effort.

Ciao
Hannes

-----Original Message-----
From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]
Sent: 05 February 2018 16:35
To: Hannes Tschofenig
Cc: atlas@ietf.org
Subject: RE: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Hannes,

Sorry, responding to this late.

The new draft chapter looks better.

I would be curious if there are enough real-world problems to be solved in the charter. Part of this work can happen in other WGs, for example for (D)TLS embeddings for COAP in ACE or CORE. I know the friel draft is trying to solve a real problem with proxies. Is TLS Embedding in Bluetooth Smart something that really needs a solution, excuse my ignorance. And (D)TLS embeddings for COAP + COSE, are COAPS and EDHOC not enough for these usecases? Is there any real usecase expressed in the industry for something like draft-garcia-core-app-layer-sec-with-dtls-record?

Rgs,
Panos



-----Original Message-----
From: Atlas [mailto:atlas-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Friday, February 02, 2018 6:54 AM
To: Carsten Bormann <cabo@tzi.org>
Cc: atlas@ietf.org
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Carsten,

Thanks for taking a closer look at the charter text and for your feedback.

I agree with you that TLS has been conveyed over transports other than the classical transport layer protocol. You raised the example of EAP-TLS/EAP-TTLS. From that point of view the idea of using TLS / DTLS over other transport shouldn't be too radical.

DTLS has also be used to established security associations for other protocols, as outlined in the DTLS-SRTP framework where DTLS was used to establish security associations for protection of RTP. So that shouldn't be earth-shaking either.

We are essentially saying that we would like to embed TLS/DTLS in HTTP, CoAP and maybe other protocols. Of course, we have to define the details of this "embedding". Of course, each embedding needs to come with some security considerations.

We just think that this is a better route than re-designing the TLS handshake for IoT, and for other environments. It turns out that implementation-wise we could re-use existing code and the additional complexity was minimal.

I agree with you that the standardization effort is rather small. For this reason we have been asked whether it makes sense to even ask for a BOF since this could easily be done in an existing working group. I do, however, believe that it makes sense to bring this topic in front of the community and have some agenda time to discuss it with those interested in this e2e security debate.

Your feedback does, however, make me believe that an update to the charter text is needed. Below is an updated proposal. Is this any better?
(Below I have indicate separate documents for the different "embeddings" even though I am not entirely convinced whether separate documents are needed or whether the content should rather be placed into a single document instead.)

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

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]
Sent: 02 February 2018 06:01
To: Hannes Tschofenig
Cc: atlas@ietf.org
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hannes,

I have read the charter and I must admit that I have no idea what this WG would actually do.

TLS has been used in applications for a long time.  Let me take EAP-TTLS (and EAP-TLS) as an example for that to make my point more concrete.

With EAP-TTLS, one problem to be solved was the embedding of TLS in the specific application protocol (here, the application is network access control, but it is still an application).  Each such embedding will be specific to the application protocol; I have no idea what a generic embedding would look like.  This can be done only per embedding.  In any case, the charter does not discuss this, or which embeddings would be done.

The other aspect is that the application will need specific semantics from the security protocol.  For EAP-TTLS, the semantics was about secure (protected) access to a server.  The existing PKI worked reasonably well for this.  Ditto for EAP-TLS, with the addition of client certificates (which never were picked up very much in practice, something we maybe can learn from).

Other applications won't be about protected access to servers.  PKI won't do it.  I don't understand the optimism that believes that, since TLS is a fine security protocol, it will adapt to new security objectives without a hitch.  Actually, in practice, this is where security protocols fail quite often, and we will get a lot of insecure "application security" protocols on top of a "secure" TLS kernel.  The charter does not mention applications, and it does not say how an application would obtain the TLS extensions or other mechanisms to address its security objectives.  This can be done only per application.  The charter does not discuss this, or which applications would be done.  In any case, that work should include domain experts for the specific applications, so a TLS-minded WG may not be the best place to do it.

So, in summary, while TLS is a fine hammer, we won't be able to declare success by simply assuming the rest of the world to be nails.
Google's ALTS is a nice example of what you can achieve when you have a good set of building blocks to build specific signed claims that are actually reflecting the application security semantics.  Of course, the specific ALTS protocol is tailored to Google’s application environment; what we need to do first in the IETF is focus on how to offer these building blocks.  The reuse of TLS may or may not in the end help here, but pretty much is a diversion from solving the real problems.

Grüße, Carsten

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
https://www.ietf.org/mailman/listinfo/atlas
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.