Re: [Atlas] Status Update

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Thu, 21 June 2018 09:00 UTC

Return-Path: <Hannes.Tschofenig@arm.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 89730128CF3 for <atlas@ietfa.amsl.com>; Thu, 21 Jun 2018 02:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 LNKTZz2-VJja for <atlas@ietfa.amsl.com>; Thu, 21 Jun 2018 02:00:40 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0061.outbound.protection.outlook.com [104.47.1.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B5D1274D0 for <atlas@ietf.org>; Thu, 21 Jun 2018 02:00:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XMXC0daHlqDr1dkzPzBYliN21+apfmTcuGA3eTlRBLg=; b=LPspEJP2Swy7j34M4zcW0FdQEWeOlPlrJlc2Zge3jkpmMfTU9YL1cOQEJvatwa1upVjxmiB9q9fNF5fJFOjpr2VN4GkDEJ/jpvexEDtxmnxvxoXQ43epMsY3Gr7QXdZkRYKTaNb389ae1AxLQTs6PtQUd+juEBrvIGnhDnQza+U=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1325.eurprd08.prod.outlook.com (10.167.197.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Thu, 21 Jun 2018 09:00:36 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Thu, 21 Jun 2018 09:00:36 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, "atlas@ietf.org" <atlas@ietf.org>, Tommy Pauly <tpauly@apple.com>, Chris Wood <cawood@apple.com>
Thread-Topic: [Atlas] Status Update
Thread-Index: AdP/HdU64ZzegsYNSRueEze+jifg2gIst8QAAAlpqoAAUZN0cA==
Date: Thu, 21 Jun 2018 09:00:36 +0000
Message-ID: <VI1PR0801MB211255800C10B61A4830FD57FA760@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <VI1PR0801MB2112385E74223CC722B0E2A1FA7B0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <OF2AB8BDA9.34065D36-ON652582B1.00498E9D-652582B1.00498EA3@tcs.com> <ee2be3a1-77ba-f471-a7a4-cecff6472d65@tik.ee.ethz.ch>
In-Reply-To: <ee2be3a1-77ba-f471-a7a4-cecff6472d65@tik.ee.ethz.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [135.196.99.211]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1325; 7:qDRSB6YQHDc7P/T32m3GJ0ijLPiglQAckzRQovxCfLHyetV4D0MqewO16zznC7ka+HbdsA2PfNlG0v24EM4mo/+XW/7hnpeQwMrzoqZ1THfOhWnQAQIoAjMHdW/A5Y7M0Y53ANRZx28PD26hg5Uckt4XKGGubzXPyD/TOMXZrlR0C9Nq8SCnc8icoTu8X7B+RGOPzOsElU4kR/CE3Pw6jlezrcXxoEXwjKoCSEgDhTgm7DjDim76Pknc/iKuSfCC
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: ee8a3909-d997-451b-488a-08d5d7557457
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1325;
x-ms-traffictypediagnostic: VI1PR0801MB1325:
x-microsoft-antispam-prvs: <VI1PR0801MB13259B64DDD84792459A1E29FA760@VI1PR0801MB1325.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(80129823123378)(114017886912203);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1325; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1325;
x-forefront-prvs: 07106EF9B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(396003)(39860400002)(376002)(366004)(51914003)(53754006)(13464003)(40434004)(189003)(199004)(446003)(229853002)(99286004)(966005)(25786009)(9686003)(5890100001)(6306002)(2501003)(561944003)(5250100002)(7736002)(26005)(11346002)(476003)(33656002)(486006)(102836004)(81156014)(5660300001)(59450400001)(8676002)(81166006)(53386004)(8936002)(6246003)(186003)(305945005)(6436002)(14454004)(76176011)(72206003)(7696005)(6506007)(53546011)(86362001)(6116002)(3846002)(97736004)(68736007)(478600001)(15650500001)(2906002)(3280700002)(66066001)(7110500001)(110136005)(8666007)(55016002)(74316002)(53936002)(106356001)(3660700001)(2420400007)(105586002)(316002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1325; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: mXPEig+2VWk0Yw7dicQztAhdtumEnQZ8OHSX4QeedvoRo5QCmRQgwxw70XjxIjo5b/I5zB9qa+GdAXMcqpz2JiXLsOs3TmvN5XrehF3KI38ELSdozcggDPT73IVJlXjDyPqQlMZO+Hx5S3eJVxkfdaaWHZGZ/hR4FX5Mda6dnBKByyHKTWaI1xnsh0NWM0CFIoAG2t8sK1pk6bCItfYHA50mPm8ydudfX7mywZCoGc61r/CKuTU9dyavqkpG4PnEejze09dlBgXIGdB24E5/rWEuUmKJLoIZfAV4HuIvocHdnbTVNCUMOo0cy0x3VoxRPf3NpMen6BqIfHgxHQ6B/w==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ee8a3909-d997-451b-488a-08d5d7557457
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 09:00:36.5501 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1325
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/CzGuN6fpSqsryR14QrzToepKKnI>
Subject: Re: [Atlas] Status Update
X-BeenThere: atlas@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 21 Jun 2018 09:00:45 -0000

I did a quick read of draft-kuehlewind-taps-crypto-sep-02

I agree that providing flexibility by separating the transport protocol, record  protocol and control protocol makes sense.
If you look at the TLS / DTLS protocol you can see that there is much of this already realized today. For example,
  * Transport: support for various underlying protocols, even non-IP.
  * Record: DTLS has been used to establish keying material for SRTP and, if you look at network access authentication, also for use with WiFi security. The same is true for some other radio technologies, such as IEEE 802.15.4 in Thread.

Where the nice separation falls apart a bit (which is not appropriately reflected in the figures) is the unfortunate fact that the handshake protocol itself may need to use some security protection for its own use. In TLS the design just happens in such a way that the record layer is re-used for protecting handshake messages itself (once keys become available). In other protocols, like IKEv2/IPsec there are two separate mechanisms used.

I believe the core message in your document and the message in our document is the same. I have to check how close our Mbed TLS API is to the requirements you outline in your document.

An area where more work is needed IMHO is in the policy context since the developer has to determine which layer has to be protected with what mechanism. This is particularly important when the same protocol can in a flexible way be used at different layers. When you use totally different protocols, as it is often done today then this policy is hardwired.

Ciao
Hannes

-----Original Message-----
From: Atlas [mailto:atlas-bounces@ietf.org] On Behalf Of Mirja Kühlewind
Sent: 19 June 2018 18:53
To: atlas@ietf.org; Tommy Pauly; Chris Wood
Subject: Re: [Atlas] Status Update

Hi all,

writing as an individual contributor, not an IESG member.

I just briefly looked at draft-friel-tls-atls-00 and when I saw Figure 6, I have to say that I do wonder a bit what additional standardization is needed here. The new parts are the key export and the App Data Crypto box. However, the key export is mainly an interface question and to my understanding there are by now already libraries that provide the needed interface for quic. And the actual app data crypto should be rather straight forward and probably does not need that much standardization...?

In the context of taps, however, we've been thinking about how to even more generalize this approach (in figure 6). The two points I think could be generalized here even more are

1) The TLS handshake should be completely separated from the crypto and could be run directly by the TLS stack without "tunneling" it through the application. Effectively, in theory the handshake would not even need to use the same transport connection or transport protocol than the application (also it probably could).

This also something we discuss/propose in this draft as input for taps:
https://tools.ietf.org/html/draft-kuehlewind-taps-crypto-sep-02

2) The TLS handshake could negotiate within one handhshake multiple key shares that can be used on different layers for different protocols and algorithms. I guess that is more a question/request for the TLS working group but goes into the same direction of separating handshake/control and the actual crypto more.

Mirja



On 19.06.2018 15:23, Abhijan Bhattacharyya wrote:
> Hello Hannes,
> Thanks for the update. The revise charter looks good. So what can we
> expect in Montral? Do we expect another attempt towards a BoF?
> I have a view against the particular observation of low activities in
> the mailing list. I think what ATLAS is trying to do is to collect and
> coordinate between different relevant stray proposals (which may have
> already been worked out) under a single consolidated standardization
> effort. So, the activities are waiting at a threshold of a coordinated
> future progress. But, more activities in this list is definitely a
> proposition to establish the point of interest for the IETF community.
>
> With Best Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, TCS Research
> Tata Consultancy Services
> Building 1B,Ecospace
> Plot -  IIF/12 ,New Town, Rajarhat,
> Kolkata - 700160,West Bengal
> India
> Ph:- 033 66884691
> Cell:- +919830468972
> Mailto: abhijan.bhattacharyya@tcs.com
> <mailto:abhijan.bhattacharyya@tcs..com>
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Consulting
> ____________________________________________
>
>
> -----"Atlas" <atlas-bounces@ietf.org <mailto:atlas-bounces@ietf.org>>
> wrote: -----
> To: "atlas@ietf..org <mailto:atlas@ietf.org>" <atlas@ietf.org
> <mailto:atlas@ietf.org>>
> From: Hannes Tschofenig
> Sent by: "Atlas"
> Date: 06/08/2018 05:14PM
> Subject: [Atlas] Status Update
>
> Hi all,
>
> Owen and I submitted another BoF proposal to the IESG based on the
> feedback from the last IETF meeting.
>
> Here is the most recent charter text we came up with:
>
> ---
>
> There are multiple scenarios where clients and servers need to
> negotiate shared encryption keys and establish secure, authenticated,
> integrity-protected, end-to-end encrypted sessions at the application
> layer over untrusted transport. There are a proliferation of transport
> protocols and mechanisms in use today across web and IoT use cases
> including, but not limited to, TCP, UDP, IP, Bluetooth and Zigbee.
> Additionally, network topologies often include middleboxes and proxies
> that terminate transport layer connections from clients and
> re-originate new transport layer connections towards the servers. From
> the clients and servers perspective, these transport layer proxy
> functions are untrusted and application data must be protected and
> encrypted, and not exposed to these proxies. There are multiple
> potential mechanisms that could be considered for negotiation of
> encryption keys, and establishment of end-to-end encrypted sessions at
> the application layer between clients and servers, and this working
> group proposes use of existing (D)TLS protocols and stacks.
>
> This working group proposes reuse of (D)TLS at the application layer
> as a simple and straightforward means of achieving the security and
> implementation goals. The primary purpose of the working group is to
> develop specifications defining how (D)TLS can be leveraged at the
> application layer (i.e. Application Layer TLS or ATLS) to establish
> end-to-end encrypted sessions over a multitude of different transports.
>
> Additionally, during development of ATLS specifications, the working
> group will consider and address concerns such as:
>
> o complex, multi-hop and lossy transport topologies
>
> o (D)TLS record fragmentation at the transport layer
>
> o middlebox operators whose goals include interception of application
> layer data
>
> The working group will engage with other relevant working groups
> across the Applications and Real-Time Area (art), Security Area (sec)
> and Transport Area (tsv), and one of the goals of this working group
> is to explicitly identity all related working groups that must be
> consulted during ATLS specifications development.
>
> ---
>
> There do not seem to be minutes available from the IESG/IAB BoF
> discussions and how they reached their conclusions. So, we can only
> report what has been told to us by proxy.
>
> In any case, the IESG rejected the BoF proposal.
>
> The impression from the IESG was that the Bar BOF in London produced
> mixed feelings and that there was no activity on the list afterwards.
>
> Another comment was that the required standardization effort is too
> small to justify the setup of an entire working group.
>
> At first, this sounds a bit negative. On the other hand, we have two
> implementations right now. While they need to be polished I believe
> this is something we could go forward with.
>
> 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
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail message and/or
> attachments to it may contain confidential or privileged information.
> If you are not the intended recipient, any dissemination, use, review,
> distribution, printing or copying of the information contained in this
> e-mail message and/or attachments to it are strictly prohibited. If
> you have received this communication in error, please notify us by
> reply e-mail or telephone and immediately and permanently delete the
> message and any attachments. Thank you
>
>
>
> _______________________________________________
> Atlas mailing list
> 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.