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

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Feb 2018 06:00:38 +0100

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 2 Feb 2018 10:59:20 +0100

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 <[email-masked]> 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
> [email-masked]
> 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: [email-masked]
----------------------------------------------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 2 Feb 2018 11:53:32 +0000

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

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.

# Milestones

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

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:

- draft-friel-tls-atls-00
---

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 02 February 2018 06:01
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hannes,

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.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Feb 2018 13:11:37 +0100

On Feb 2, 2018, at 12:53, Hannes Tschofenig <[email-masked]> wrote:
> 
> embeddings for different application protocols, such as CoAP, HTTP, and Bluetooth Smart

Hannes,

I’d sure like to complete CoDTLS, so that looks much better for me now.
I would expect we can define media types that work for both CoAP and HTTP, so that integration should probably be left open as something for the WG to decide.

Not so sure about “Bluetooth Smart” — are we optimistic with respect to attracting enough people that at least know that this is no longer the name of Bluetooth Low Energy :-)

I’m also not so sure about the Architecture and Use Case document as a separate item; we could simple add a page or two to the introduction of the media types document.

Finally, I’ll have to add the ceterum censeo that I don’t think the complex TLS should have a monopoly on key agreement protocols, and that I think we should also complete EDHOC.

Do we have a position on TLS/DTLS 1.3?  Or is that for the WG to decide?

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 2 Feb 2018 12:26:20 +0000

Hi Rafa,

Thanks for your feedback.

A few remarks below.

-----Original Message-----
From: Rafa Marin Lopez [mailto:[email-masked]]
Sent: 02 February 2018 10:59
To: Hannes Tschofenig
Cc: Rafa Marin Lopez; [email-masked]
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Dear Hannes, all:

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

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

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

> 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
> [email-masked]

-----------------------------------------------------------
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: [email-masked]
----------------------------------------------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 2 Feb 2018 12:34:59 +0000

Hi Carsten,

A few remarks below:

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 02 February 2018 13:12
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hannes,

[Hannes] That's also my thinking. Working on the ATLS draft(s) I had the impression that the differences between CoAP and HTTP are small enough to justify putting the functionality in one document.

[Hannes] A fair concern. I have just have seen repeatedly how people mess up Bluetooth Smart security. Hence, I wonder whether a standardized approach in the IETF (which is the home of TLS) would make sense, or is at least worthwhile to try.

[Hannes] I wasn't quite sure about this either. On one hand draft-friel-tls-atls-00, for example, contains use cases but on the other hand I also know that there are various use cases to describe (from my work in the OMA Device Management group). If there are different profiles for the various application layer protocols then you may not want to repeat the same content over and over again. Maybe this is something for the group or the ADs/IESG to decide.

[Hannes] I does not have a monopoly even today since we have the great IKE/IPsec stuff as well.

[Hannes] I believe we need a solution that works for TLS / DTLS 1.2 and 1.3. Deployment-wise I would favour 1.3 due to the better performance and improved security.

Ciao
Hannes

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Feb 2018 14:09:35 +0100

On Feb 2, 2018, at 13:34, Hannes Tschofenig <[email-masked]> wrote:
> [Hannes] A fair concern. I have just have seen repeatedly how people mess up Bluetooth Smart security. Hence, I wonder whether a standardized approach in the IETF (which is the home of TLS) would m…

Sure, but I don’t think that kind of work can be done on the same timelines as the work on protocols we control and understand deeply.

When we did RFC 7668, we were pretty much done and then Bluetooth SIG essentially reversed half of the decisions and put that into Bluetooth, forcing us to follow suit.  The whole process took 4.5 years.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 2 Feb 2018 13:18:09 +0000

> When we did RFC 7668, we were pretty much done and then Bluetooth SIG essentially reversed half of the decisions and put that into Bluetooth, forcing us to follow suit.  The whole process took 4.5…

Having participated in the Bluetooth SIG myself I don't think it was malice but rather a lack of understanding of IP (and networking in general). As one can imagine, there is a lot of expertise in the SIG for topics that concern radio technology. Maybe there is a way to improve the interaction between the IETF and Bluetooth SIG. This is, however, not only a relevant issue for this ATLAS effort.
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.

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Fri, 2 Feb 2018 17:51:01 +0100

Hi Hannes:

Thanks for your answer. See some comments inline.

> El 2 feb 2018, a las 13:26, Hannes Tschofenig <[email-masked]> escribió:
> 
> Hi Rafa,
> 

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

>> copy the information in any medium. Thank you.

-------------------------------------------------------
Rafa 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: [email-masked]
-------------------------------------------------------

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 5 Feb 2018 15:35:01 +0000

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:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, February 02, 2018 6:54 AM
To: Carsten Bormann <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Carsten,

---
Application Transport LAyer Security (ATLAS) ============================================

## Background

## Problem Statement

## Goal of this Group

# Milestones

# References:

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 02 February 2018 06:01
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hannes,

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 6 Feb 2018 09:55:41 +0000

Hi Rafa,

You raise a good point. A TLS / DTLS implementation requires the record layer for protection of the handshake messages not just for the protection of the application layer messages. So, when I talk about deriving keys to protect application layer traffic using a different protocol, such as COSE or JOSE, I was only referring to the application data protection.

Could this be done differently? Yes, it could. But that’s something for the group to analyse and to determine whether replacing the entire record layer (also for the handshake message) makes sense.

Does this make sense to you?

Ciao
Hannes

From: Rafa Marin-Lopez [mailto:[email-masked]]
Sent: 02 February 2018 17:51
To: Hannes Tschofenig
Cc: Rafa Marin-Lopez; [email-masked]
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Hannes:

El 2 feb 2018, a las 13:26, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> escribió:

Hi Rafa,

A few remarks below.

-----Original Message-----
From: Rafa Marin Lopez [mailto:[email-masked]]
Sent: 02 February 2018 10:59
To: Hannes Tschofenig
Cc: Rafa Marin Lopez; [email-masked]<mailto:[email-masked]>
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Dear Hannes, all:

Best Regards.

Ciao
Hannes

Best Regards.

El 22 ene 2018, a las 22:00, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> escribió:

Hi all,

Ciao
Hannes

-------

Milestones

[email-masked]<mailto:[email-masked]>

-----------------------------------------------------------
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: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------

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
[email-masked]<mailto:[email-masked]>
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: +34868888501 Fax: +34868884151 e-mail: [email-masked]<mailto:[email-masked]>
-------------------------------------------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 6 Feb 2018 10:02:13 +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:[email-masked]]
Sent: 05 February 2018 16:35
To: Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Hannes,

Rgs,
Panos

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

Hi Carsten,

---

## Background

## Problem Statement

## Goal of this Group

# Milestones

# References:

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 02 February 2018 06:01
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hannes,

Grüße, Carsten

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Wed, 7 Feb 2018 12:13:08 +0100

Hi Hannes:

Please see my comments inline.

> El 6 feb 2018, a las 10:55, Hannes Tschofenig <[email-masked]> escribió:
> 
> Hi Rafa,
>  
> You raise a good point. A TLS / DTLS implementation requires the record layer for protection of the handshake messages not just for the protection of the application layer messages.

[Rafa] Correct. 

> So, when I talk about deriving keys to protect application layer traffic using a different protocol, such as COSE or JOSE, I was only referring to the application data protection.

[Rafa] Ok. But my question is: are we going to consider TLS record for application data protection?

> Does this make sense to you?

[Rafa] Since the TLS record is used for the handshake anyway, the (constrained) device, in case of the IoT, will have the record layer implemented. Why don’t  we can re-use it for the application data protection?

Best Regards.
>  
> Ciao
> Hannes
>   <>
> From: Rafa Marin-Lopez [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Rafa Marin-Lopez; [email-masked] <mailto:[email-masked]>
> El 2 feb 2018, a las 13:26, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> escribió:
>  
> Hi Rafa,
> 
> From: Rafa Marin Lopez [mailto:[email-masked] <mailto:[email-masked]>]
> Cc: Rafa Marin Lopez; [email-masked] <mailto:[email-masked]>
> El 22 ene 2018, a las 22:00, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> escribió:
> 
> Hi all,
> 
> -   and https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security <https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/atlas <https://www.ietf.org/mailman/listinfo/atlas>
> 
> Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/atlas <https://www.ietf.org/mailman/listinfo/atlas>
>  
> Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 7 Feb 2018 11:19:07 +0000

Hi Rafa,

It might depend on the use case what approach is better. In DTLS-SRTP, for example, it was considered better to re-use SRTP instead of the DTLS record layer due to existing hardware. Another example: For EAP-TLS used in network access the TLS record layer is only used during the handshake between the EAP peer and the EAP server but for the link layer security a different security mechanism is used instead since the endpoints are different.

Ciao
Hannes

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Wed, 7 Feb 2018 12:26:25 +0100

Hi Hannes:

> El 7 feb 2018, a las 12:19, Hannes Tschofenig <[email-masked]> escribió:
> 
> Hi Rafa,
>  
> It might depend on the use case what approach is better.
> In DTLS-SRTP, for example, it was considered better to re-use SRTP instead of the DTLS record layer due to existing hardware. Another example: For EAP-TLS used in network access the TLS record layer is only used during the handshake between the EAP peer and the EAP server but for the link layer security a different security mechanism is used instead since the endpoints are different. 

[Rafa] I do not know the case of DTLS-SRTP but, in my opinion, the case of EAP-TLS is different since between TLS and the link layer you have EAP and the goal of the TLS is the authentication and key generation for EAP to generate the MSK and not for the link layer itself. In other words, the link layer is agnostic about the use of TLS or not. Moreover, in EAP tunneled methods you use TLS record to protect further information between EAP peer and EAP server not only the handshake.  

Best Regards.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 7 Feb 2018 11:35:03 +0000

Hi Rafa,

It is hard to anticipate future discussions on the pros and cons of re-using the TLS/DTLS record layer for protection of application data but in the past we have seen John Mattsson arguing that the DTLS record layer is too inefficient for IoT devices, which is why he and his co-worker have worked on OSCORE.

I prefer to leave this design decision open and then evaluate and discuss it in the group. For that reason I thought your proposal is relevant to the discussion.

Ciao
Hannes

From: Rafa Marin-Lopez [mailto:[email-masked]]
Sent: 07 February 2018 11:26
To: Hannes Tschofenig
Cc: Rafa Marin-Lopez; [email-masked]
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Hannes:

El 7 feb 2018, a las 12:19, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> escribió:

Hi Rafa,

Best Regards.

Ciao
Hannes

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Wed, 7 Feb 2018 13:06:12 +0100

Hi Hannes:

> El 7 feb 2018, a las 12:35, Hannes Tschofenig <[email-masked]> escribió:
> 
> Hi Rafa,
>  

[Rafa] Yes, we have read the document though the analysis only focuses in the message size but not in other factors (e.g. the advantage/disadvantages of re-using existing source code). I think a complete analysis should also include those factors. 

In summary, under my point of view, using the TLS record represents a tradeoff between message size and re-using something that will already be in the device. 

> I prefer to leave this design decision open and then evaluate and discuss it in the group. For that reason I thought your proposal is relevant to the discussion.

[Rafa] I fully agree.

Best Regards.

> El 7 feb 2018, a las 12:19, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> escribió:
>  
> Hi Rafa,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 7 Feb 2018 12:12:09 +0000

Rafa, I believe we are on the same page on this topic. I hope that the charter text covers the intention correctly. If you have suggestions for improving the text nevertheless please let us know.

Ciao
Hannes

From: Rafa Marin-Lopez [mailto:[email-masked]]
Sent: 07 February 2018 12:06
To: Hannes Tschofenig
Cc: Rafa Marin-Lopez; [email-masked]
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Hannes:

El 7 feb 2018, a las 12:35, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> escribió:

Hi Rafa,

[Rafa] I fully agree.

Best Regards.

Ciao
Hannes

From: Rafa Marin-Lopez [mailto:[email-masked]]
Sent: 07 February 2018 11:26
To: Hannes Tschofenig
Cc: Rafa Marin-Lopez; [email-masked]<mailto:[email-masked]>
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Hannes:

Hi Rafa,

Best Regards.

Ciao
Hannes

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 7 Feb 2018 12:30:09 +0000

The draft charter states “The group will also work on specifications that describe how to deriving keying material for protecting application payloads using JOSE and COSE.”. You could possibly be more explicit Hannes and add a statement about evaluating use TLS records to protect application data vs. using key exporting, etc.

The latest consolidated draft we submitted describes both potential architectures: https://tools.ietf.org/html/draft-friel-tls-atls-00#section-6.1 with some initial comments on recommendations. This could certainly be expanded upon.

Owen

From: Atlas [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday 7 February 2018 12:12
To: Rafa Marin-Lopez <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Ciao
Hannes

Hi Hannes:

Hi Rafa,

[Rafa] I fully agree.

Best Regards.

Ciao
Hannes

Hi Hannes:

Hi Rafa,

Best Regards.

Ciao
Hannes