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

Rafa Marin-Lopez <rafa@um.es> Wed, 07 February 2018 11:26 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 13451126C0F for <atlas@ietfa.amsl.com>; Wed, 7 Feb 2018 03:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 2oYDlLbkcSYO for <atlas@ietfa.amsl.com>; Wed, 7 Feb 2018 03:26:28 -0800 (PST)
Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7DF124235 for <atlas@ietf.org>; Wed, 7 Feb 2018 03:26:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id CB1582017E; Wed, 7 Feb 2018 12:26:26 +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 nXDRTURLEGxr; Wed, 7 Feb 2018 12:26:26 +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 xenon44.um.es (Postfix) with ESMTPSA id 4A0E51FE5D; Wed, 7 Feb 2018 12:26:26 +0100 (CET)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <EB877997-5CB0-4FCD-A7A4-D49CE00CA63F@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EEC74BE8-46B1-48D5-9617-000A8E521141"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 07 Feb 2018 12:26:25 +0100
In-Reply-To: <AM4PR0801MB2706894677C27D81B16FD295FAFC0@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>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/wVAdF2mYbCvdY_vdOAyn2j7yHwo>
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 11:26:31 -0000

Hi Hannes:

> El 7 feb 2018, a las 12:19, Hannes Tschofenig <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>