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

Rafa Marin-Lopez <rafa@um.es> Wed, 07 February 2018 12:06 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 96A54129516 for <atlas@ietfa.amsl.com>; Wed, 7 Feb 2018 04:06:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.93
X-Spam-Level:
X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 UBJOFEjxiu-l for <atlas@ietfa.amsl.com>; Wed, 7 Feb 2018 04:06:15 -0800 (PST)
Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 19547124205 for <atlas@ietf.org>; Wed, 7 Feb 2018 04:06:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id A040F200EA; Wed, 7 Feb 2018 13:06:13 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon42.um.es
Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5-uI31ZgGB2E; Wed, 7 Feb 2018 13:06:13 +0100 (CET)
Received: from eduroam_um-7-30.inf.um.es (eduroam_um-7-30.inf.um.es [155.54.7.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon42.um.es (Postfix) with ESMTPSA id 1D9571FFE8; Wed, 7 Feb 2018 13:06:12 +0100 (CET)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <62CCF4BC-6377-45FD-8943-5580B33AC1C1@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_72335350-EC92-43D2-B99A-1297F6873C2C"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 07 Feb 2018 13:06:12 +0100
In-Reply-To: <AM4PR0801MB2706E1BB54E7CC1E8EB8D43AFAFC0@AM4PR0801MB2706.eurprd08.prod.outlook.com>
Cc: Rafa Marin-Lopez <rafa@um.es>, "atlas@ietf.org" <atlas@ietf.org>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
References: <AM4PR0801MB2706895905D2634096D4A11BFAEC0@AM4PR0801MB2706.eurprd08.prod.outlook.com> <1351441E-26C6-4E16-AD62-B06C860AE97D@um.es> <AM4PR0801MB270672FDA690903CA86EFB3FFAF90@AM4PR0801MB2706.eurprd08.prod.outlook.com> <94E9FD8C-1889-4376-B0F9-13B2E44BBA96@um.es> <AM4PR0801MB270665259B97D62CE3B56ACFFAFD0@AM4PR0801MB2706.eurprd08.prod.outlook.com> <D93CAAA0-7416-4662-807F-1AABBCC835C9@um.es> <AM4PR0801MB2706894677C27D81B16FD295FAFC0@AM4PR0801MB2706.eurprd08.prod.outlook.com> <EB877997-5CB0-4FCD-A7A4-D49CE00CA63F@um.es> <AM4PR0801MB2706E1BB54E7CC1E8EB8D43AFAFC0@AM4PR0801MB2706.eurprd08.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/6-BLpMvOsO5zqaGif-YTq_wV-SE>
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: Wed, 07 Feb 2018 12:06:17 -0000

Hi Hannes:

> El 7 feb 2018, a las 12:35, Hannes Tschofenig <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
> 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 <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. _______________________________________________
> Atlas mailing list
> Atlas@ietf.org <mailto:Atlas@ietf.org>
> https://www.ietf.org/mailman/listinfo/atlas <https://www.ietf.org/mailman/listinfo/atlas>