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

Rafa Marin Lopez <rafa@um.es> Fri, 02 February 2018 09:59 UTC

Return-Path: <rafa@um.es>
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 9D534128961 for <atlas@ietfa.amsl.com>; Fri, 2 Feb 2018 01:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 r3Or2os4Kfr3 for <atlas@ietfa.amsl.com>; Fri, 2 Feb 2018 01:59:26 -0800 (PST)
Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 162C3127873 for <atlas@ietf.org>; Fri, 2 Feb 2018 01:59:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id CA294205A1; Fri, 2 Feb 2018 10:59:21 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon44.um.es
Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eyefH4hMyIfI; Fri, 2 Feb 2018 10:59:21 +0100 (CET)
Received: from quantum.inf.um.es (quantum.inf.um.es [155.54.204.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 24672204FA; Fri, 2 Feb 2018 10:59:19 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <AM4PR0801MB2706895905D2634096D4A11BFAEC0@AM4PR0801MB2706.eurprd08.prod.outlook.com>
Date: Fri, 02 Feb 2018 10:59:20 +0100
Cc: Rafa Marin Lopez <rafa@um.es>, "atlas@ietf.org" <atlas@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1351441E-26C6-4E16-AD62-B06C860AE97D@um.es>
References: <AM4PR0801MB2706895905D2634096D4A11BFAEC0@AM4PR0801MB2706.eurprd08.prod.outlook.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/9w1Tx7SbfuneKYx0IQwuYhOyLMY>
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: Fri, 02 Feb 2018 09:59:29 -0000

Dear Hannes, all:

I have been reading the text about the potential charter and I have a few comments/questions (my apologies if they have been already addressed in the mailing list).

First of all, it seems the idea is using TLS/DTLS handshake as key exchange protocol. Therefore, the level of optimization (reducing number of messages , message size) is limited to what we can do with TLS and DTLS (I am thinking specially in constrained devices). Nevertheless, the advantage is that we already have that source code in the device anyway.

However, it is not clear to me if TLS/DTLS record layer will be also used as mandatory to protect application or not. In other words, my question is whether the TLS/DTLS handshake will be used to generate key material but this key material will not be used by the record protocol but other mechanisms to protect application messages. Or, or the contrary, the record protocol will be also used to protect application protocol. As an analogy, AFAIK, IKEv2 is used in IEEE 802.15.9 to generate key material to IEEE 802.15.4 but not for IPsec. 

By the way, a potential reference of this kind of Application Transport LAyer Security: In IEEE 802.21a we worked in something where the TLS handshake was transported inside IEEE 802.21 (MIH) messages. As a consequence we used the TLS record to protect further MIH messages. The reason of using TLS was very similar to the one stated here.

Best Regards.

> El 22 ene 2018, a las 22:00, Hannes Tschofenig <Hannes.Tschofenig@arm.com> escribió:
> 
> 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. _______________________________________________
> Atlas mailing list
> Atlas@ietf.org
> https://www.ietf.org/mailman/listinfo/atlas

-----------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
----------------------------------------------------------