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

[Rafa Marin-Lopez <[e-mail]>]

Hi Hannes:

Thanks for your answer. See some comments inline.

> El 2 feb 2018, a las 13:26, Hannes Tschofenig <[e-mail]> escribió:
> 
> Hi Rafa,
> 
> Thanks for your feedback.
> 
> A few remarks below.
> 
> -----Original Message-----
> From: Rafa Marin Lopez [mailto:[e-mail]]
> Sent: 02 February 2018 10:59
> To: Hannes Tschofenig
> Cc: Rafa Marin Lopez; [e-mail]
> Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text
> 
> 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.
> 
> [Hannes] I agree that there are limits to the optimization one can make. On the other hand, this approach immediately re-uses all optimizations made for TLS/DTLS. For example, with the work on TLS 1.3 and DTLS 1.3 numerous optimizations have been made. I also have to say that this is foremost enable the functionality in the first place (and not just for IoT scenarios).
> 
> 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.
> 
> [Hannes] Very good question. I tried to make this more clear in my response to Carsten where I also provided an updated version of the charter text. At a minimum we should explore a solution that exports keying material for use with non-record layer protected application data.

[Rafa] I am not sure about the logic of this in the context of this effort. I believe one motivation of this proposal is to re-use TLS/DTLS implementation and associated source code, if I understood correctly. It seems that we will work with TLS/DTLS handshake as mandatory however it looks like TLS/DTLS record layer, despite it will be implemented in the device, may not be used and it may be “replaced" for other mechanism to protect application traffic. So the device would have TLS/DTLS handshake implementation + some kind of mechanism to protect application data + TLS record layer (which may not be used for application protection). Maybe the TLS/DTLS record layer is not so optimized than other alternatives but it will be implemented. But the same may be applicable to TLS/DTLS handshake: maybe it is not so optimized against other alternatives but it will be there and it will be used.

We may be opening the door to have a TLS/DTLS spec that omit the record layer in his specification. This would clearly separate the key management from the data protection mechanism in TLS/DTLS.

Best Regards.


> 
> 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.
> 
> [Hannes] Thanks for this example. I will add it to the charter text to illustrate prior work. I believe Thread also used a similar approach.
> 
> Ciao
> Hannes
> 
> Best Regards.
> 
>> El 22 ene 2018, a las 22:00, Hannes Tschofenig <[e-mail]> 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
>> [e-mail]
>> 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: [phone] Fax: [phone] e-mail: [e-mail]
> ----------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/atlas

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: [phone] Fax: [phone] e-mail: [e-mail]
-------------------------------------------------------