Re: [Atlas] Status Update

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Mon, 25 June 2018 10:46 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 E60D712D949 for <atlas@ietfa.amsl.com>; Mon, 25 Jun 2018 03:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 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] 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 g0qKPDK7XKh1 for <atlas@ietfa.amsl.com>; Mon, 25 Jun 2018 03:46:40 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0057.outbound.protection.outlook.com [104.47.1.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D87126CC7 for <atlas@ietf.org>; Mon, 25 Jun 2018 03:46:39 -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=BZtTbEHpH1g8ynU+GC5UlAHyyZBTW7uJ1epGMy1Xh/8=; b=OEm/0o81l/ZRicYHomsGg4eXpbsRkJwmNRXweet/g4F2zN9UpgyrkUQbF+5Yi3ApGtsoSkAtjK4RZZ3N9S/nIwDmwYQ6kg7WB9XZGrSMFH1Qd7UXeEsLk4c3WXmHcZnA92qrynQAx1fQ+VChxNfVVESerMb/jm6yUHPsmJeIQAQ=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1887.eurprd08.prod.outlook.com (10.173.73.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.20; Mon, 25 Jun 2018 10:46:36 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%9]) with mapi id 15.20.0884.024; Mon, 25 Jun 2018 10:46:36 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
CC: "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+jifg2gIst8QAAAlpqoAAUZN0cACojraAACSEBxA=
Date: Mon, 25 Jun 2018 10:46:36 +0000
Message-ID: <VI1PR0801MB2112DF1BAAF803F774F7FA06FA4A0@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> <VI1PR0801MB211255800C10B61A4830FD57FA760@VI1PR0801MB2112.eurprd08.prod.outlook.com> <601B8455-B784-4004-A6FF-0FA715A229BE@tik.ee.ethz.ch>
In-Reply-To: <601B8455-B784-4004-A6FF-0FA715A229BE@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: [80.92.118.234]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1887; 7:JbAbgNwZ1Fy7BiHScT6ioE3yFzGrrSvAjRz4vKjY5PKJd1fzTD7NQM2PYQoIhrTJvhUuDNBM2sqUUXJL8FgAJ2iV/gzB7n/ldv8AFmtdOu/rBhznQiDSkvCFT3wC5IERTQy3wNMkz2Z3CZ98R3re/2tWI5UtqogwSx46a8hnLsUzbDbIOGhnB4WXFRXjex2msA6j0FPEoqDfU/TwsUtuh/w5gQYj5lUqwlJntC+QIX04TRWgM87XR1suyUkz8IML
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 61bff886-d215-4412-bbbc-08d5da88ecd9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1887;
x-ms-traffictypediagnostic: VI1PR0801MB1887:
x-microsoft-antispam-prvs: <VI1PR0801MB188772286F79BB4CECE47DFAFA4A0@VI1PR0801MB1887.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(223705240517415);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1887; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1887;
x-forefront-prvs: 0714841678
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(39380400002)(376002)(346002)(199004)(40434004)(189003)(5250100002)(9686003)(102836004)(3280700002)(14454004)(2906002)(26005)(229853002)(93886005)(55016002)(6246003)(6436002)(105586002)(106356001)(3660700001)(6506007)(59450400001)(97736004)(2900100001)(316002)(53936002)(33656002)(54906003)(25786009)(4326008)(3846002)(6916009)(15650500001)(6116002)(99286004)(7736002)(305945005)(86362001)(476003)(486006)(68736007)(76176011)(8936002)(81166006)(66066001)(8676002)(81156014)(478600001)(72206003)(186003)(7696005)(446003)(5660300001)(11346002)(5890100001)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1887; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: YSQZxrK4rz/3DmoTUXr5bDN89oqJ0HPCSYlEKVtUJBfD31/WWBXkEtHO/gf1uB0zQlPYbRmi8EjeU5PAFGnBsha9XueJupJswMRYg6piL5H8aRakrsB9jUrw+aau3MlI71gazKsrC443lvqhkv6BUKcq0zmvcCybNpUu7O/0FMJaBx6LEZfGD2zSshN7jro1pTKadztCoip3aydS4YpzyvfA+yaDPMMOSx9x3YQn6Zd1bG5zR6FGFxNpuzE1YFuU1e4C3HjEuo63BXfr9Isky084J/STRD8VQWFlg9rje9fiQhih07QVSmjJVjc2NRKXus2n8soW0XrVa931xV6y3zMQWNSnYDWDPhU0rObvKT0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 61bff886-d215-4412-bbbc-08d5da88ecd9
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2018 10:46:36.5642 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1887
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/APcIuWmdfol1s-uFiSjKc8z2jbA>
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: Mon, 25 Jun 2018 10:46:43 -0000

Hi Mirja,

~snip~

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

It’s not only the protection but also other transport features, such as reliability. DTLS has its own little transport in that sense. The other option can you use one transport for the handshake and another to actually uses the encryption… from my understanding there are still two problems where things are not as separable as it would nice to have: a) the handshake itself uses the TLS record layer (which is not necessarily a problem but also is not necessary), and b) it’s not only the handshake but also later control messages that would need to be separated (eventually).

[Hannes] In DTLS the handshake contains reliability and fragmentation support. Is this necessary? Per definition of where DTLS is supposed to be used, it is necessary. If you don't need it then you also better use TLS instead.

So, in essence with the work in ATLAS we have been thinking about running TLS/DTLS on higher layers and also about separating the handshake from the application data protection. Going back to your initial question: Is there so much standardization that needs to be done? Based on our implementation experience with Mbed TLS and OpenSSL (by Owen, Mark and myself) the answer is clearly "no, there is not that much". Is there nothing to be done? I still think that there is a small amount of standardization work in addition to the description of the actual idea.

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.