Re: [Atlas] Charter Text

Phil Hunt <phil.hunt@oracle.com> Tue, 06 February 2018 17:12 UTC

Return-Path: <phil.hunt@oracle.com>
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 D1921129C6A for <atlas@ietfa.amsl.com>; Tue, 6 Feb 2018 09:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.04
X-Spam-Level:
X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 azc8m3aOwcrG for <atlas@ietfa.amsl.com>; Tue, 6 Feb 2018 09:12:23 -0800 (PST)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BEE126CF6 for <atlas@ietf.org>; Tue, 6 Feb 2018 09:12:23 -0800 (PST)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w16HBfck026039; Tue, 6 Feb 2018 17:12:15 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=invkpR0tJCyM/8+oMHEIdsu4MMDSk0ZzoCTx9ve+X3o=; b=ibdIWf4iEY/8NwXR4hHxntgzO8q9KJXjDx1cszJa7cWYDHTYYt73ksrhRD+m5Y45+eo7 QDW6w+9X3Hdso8kCJgonHvdh6VqrHz8MpZM7/QUHEAiKtw/7C0P4iNWylXeq9p54+nyA hE9K83iEYPuUssor7k7dnBQOxztfnYb2E1jLFAA7r0CpJn7j7gXTTbgafCubMUGge8UQ 2a6oCeiiZ+7C+L8UQZUbLMfo+SgKFiU/QmUV2NQKBPpBm8vrhm5U7ty2DHO8q4WALEsQ XytSAvzjlwJenlPGWYlPLIUCDTjsU5XTCxmP10mlg6PCJ1F4Ty6SmRLjBjXI2OpPahBG yQ==
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2fyg5f8525-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 06 Feb 2018 17:12:15 +0000
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w16HCDJf031314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 6 Feb 2018 17:12:14 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w16HCBZY013652; Tue, 6 Feb 2018 17:12:12 GMT
Received: from [192.168.1.25] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Feb 2018 09:12:11 -0800
From: Phil Hunt <phil.hunt@oracle.com>
Message-Id: <8A870748-7E84-4AE8-89CD-39825B986499@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_39F926B4-A9B7-4F0B-A011-9BE743D00E1E"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 06 Feb 2018 09:12:07 -0800
In-Reply-To: <7a3a5b7e0a5c4d788e3e5d6aaa4884b7@XCH-RCD-012.cisco.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, Carsten Bormann <cabo@tzi.org>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "atlas@ietf.org" <atlas@ietf.org>
To: "Owen Friel (ofriel)" <ofriel@cisco.com>
References: <AM4PR0801MB27068EB6FF489F4EE5A14040FAFD0@AM4PR0801MB2706.eurprd08.prod.outlook.com> <BB42A0A6-9491-4E53-928C-148D4B00D762@tzi.org> <0DE1D01D-EDD0-46CC-9545-F3D0D7CF16D5@akamai.com> <7a3a5b7e0a5c4d788e3e5d6aaa4884b7@XCH-RCD-012.cisco.com>
X-Mailer: Apple Mail (2.3445.5.20)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8796 signatures=668662
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802060217
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/cd2mmrv0QBg51xrxFCpOJvw5Hzo>
Subject: Re: [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: Tue, 06 Feb 2018 17:12:27 -0000

For good or bad, gatewaying (UDP-based to IP-based) seems to be a big part of IoT architecture. Having an end-to-end app-layer solution seems like a strong use case.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>

> On Feb 6, 2018, at 8:26 AM, Owen Friel (ofriel) <ofriel@cisco.com> wrote:
> 
> ATLS over HTTPS is one of the key use cases we are trying to address, specifically for bootstrapping trust in middleboxes, which is a problem we encounter today.
>  
> https://tools.ietf.org/html/draft-friel-tls-atls-00#section-3.1 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfriel-2Dtls-2Datls-2D00-23section-2D3.1&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=mNoVTryfwAw76glrLzdY2boQ-bCd4p9Wa8Udh57pm10&s=RWs5oDEW5er44FUuUXuenwCLEPu3VvTemssVLKLYxFw&e=>
>  
>  
> From: Atlas [mailto:atlas-bounces@ietf.org <mailto:atlas-bounces@ietf.org>] On Behalf Of Salz, Rich
> Sent: Tuesday 6 February 2018 15:43
> To: Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>>; Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>>
> Cc: atlas@ietf.org <mailto:atlas@ietf.org>
> Subject: Re: [Atlas] Charter Text
>  
> I think HTTP is not something to work on, as HTTPS exists and this will only cause confusion.  Something more applicable might be SNMP or CoAP.
>  
>  
> From: Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>>
> Date: Tuesday, February 6, 2018 at 4:48 AM
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>>
> Cc: "atlas@ietf.org <mailto:atlas@ietf.org>" <atlas@ietf.org <mailto:atlas@ietf.org>>
> Subject: Re: [Atlas] Charter Text
>  
> I still believe Jun 2018 is an impossible target, more so for BLE work. (and it's not "smart" any more). 
> 
> Sent from mobile
> 
> On 6. Feb 2018, at 10:08, Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>> wrote:
> 
> 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
>  
> 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.
>  
> 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.
>  
> 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 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
>  
> Oct 2018    Submit "Architecture and Use Case" document to the IESG for publication as an Informational Standard.
>  
> 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:
>  
> 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-friel-tls-atls-00
>  
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_atlas&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=njNAxyrfzDwrzrtyETvuLKnCTuH_KmwAYxNHvQM_F68&s=fgZeowldfUecrs7gFM2PNjqexSlQKvtnJ2gHYZ8Hhhk&e=>_______________________________________________
> Atlas mailing list
> Atlas@ietf.org <mailto:Atlas@ietf.org>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_atlas&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=mNoVTryfwAw76glrLzdY2boQ-bCd4p9Wa8Udh57pm10&s=r3eqU9_996MIVpWez-8B-KtrKPbqz1aIdlXB17zDYKw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_atlas&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=mNoVTryfwAw76glrLzdY2boQ-bCd4p9Wa8Udh57pm10&s=r3eqU9_996MIVpWez-8B-KtrKPbqz1aIdlXB17zDYKw&e=>