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

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:atlas-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday 7 February 2018 12:12
To: Rafa Marin-Lopez <rafa@um.es>
Cc: atlas@ietf.org
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

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:rafa@um.es]
Sent: 07 February 2018 12:06
To: Hannes Tschofenig
Cc: Rafa Marin-Lopez; atlas@ietf.org<mailto:atlas@ietf.org>
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Hannes:

El 7 feb 2018, a las 12:35, Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>> escribió:

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.

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

Ciao
Hannes

From: Rafa Marin-Lopez [mailto:rafa@um.es]
Sent: 07 February 2018 11:26
To: Hannes Tschofenig
Cc: Rafa Marin-Lopez; atlas@ietf.org<mailto:atlas@ietf.org>
Subject: Re: [Atlas] Application Transport LAyer Security (ATLAS) Charter Text

Hi Hannes:

El 7 feb 2018, a las 12:19, Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>> escribió:

Hi Rafa,

[Rafa] Ok. But my question is: are we going to consider TLS record for application data protection?
[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?

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.

Ciao
Hannes

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

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.