Re: [Atlas] Status Update

Benjamin Kaduk <kaduk@mit.edu> Tue, 26 June 2018 03:46 UTC

Return-Path: <kaduk@mit.edu>
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 2EAC4130F5C for <atlas@ietfa.amsl.com>; Mon, 25 Jun 2018 20:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 VZNelRfjZs4R for <atlas@ietfa.amsl.com>; Mon, 25 Jun 2018 20:46:30 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 50333130F55 for <atlas@ietf.org>; Mon, 25 Jun 2018 20:46:30 -0700 (PDT)
X-AuditID: 12074425-80bff70000000c3a-35-5b31b7150d2c
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 6D.52.03130.517B13B5; Mon, 25 Jun 2018 23:46:29 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w5Q3kSKF011364; Mon, 25 Jun 2018 23:46:28 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5Q3kNla002509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jun 2018 23:46:26 -0400
Date: Mon, 25 Jun 2018 22:46:23 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
Cc: DAN GARCIA CARRILLO <dan.garcia@um.es>, atlas@ietf.org, SARA NIEVES MATHEU GARCIA <saranieves.matheu@um.es>, RAFAEL MARIN <rafa@um.es>
Message-ID: <20180626034623.GA79565@kduck.kaduk.org>
References: <20180622194221.Horde.S372V87Px9x-QO2U9y-zhA7@webmail.um.es> <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> <OFC193300F.99706FBD-ON652582B4.006C82A6-652582B4.006CE18C@tcs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <OFC193300F.99706FBD-ON652582B4.006C82A6-652582B4.006CE18C@tcs.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixG6nriu63TDaYMF7GYsns/eyWSy5sovR 4vpLG4sNP36wWkz98J7VgdVjyZKfTB4z3k9l9Tj3so0lgDmKyyYlNSezLLVI3y6BK+P0rNKC t9wVu3r8Gxg/cnYxcnJICJhIHJnax9rFyMUhJLCYSWLPkn+MEM5GRonWlRfYIZyrTBLb1p9n B2lhEVCV2Dd1PhOIzSagItHQfZkZxBYRsJTY+nMyC0gDs8AcRonVU56xgiSEBZQkevu3soDY vED7lrztgFqxi1ni8/3HUAlBiZMzn4DZzAJaEjf+vQTawAFkS0ss/8cBEuYUCJBYt+AyWImo gLLE3r5D7BMYBWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuhZ6uZkleqkp pZsYwcHsorqDcc5fr0OMAhyMSjy8K14aRAuxJpYVV+YeYpTkYFIS5W2aYRgtxJeUn1KZkVic EV9UmpNafIhRgoNZSYTXbj9QOW9KYmVValE+TEqag0VJnDdnEWO0kEB6YklqdmpqQWoRTFaG g0NJgnfxVqChgkWp6akVaZk5JQhpJg5OkOE8QMPdQWp4iwsSc4sz0yHypxgVpcR5JUASAiCJ jNI8uF5QspHI3l/zilEc6BVh3k8gVTzARAXX/QpoMBPQ4LLHIFcXlyQipKQaGJN/7qtrbs+X v/hKLerPvlCG29oNnM/rCvm8qhs+H+vKsjvhULJLMuer0+kc5u0CrC2uGmVHe5zuXH+VMjf1 Z9ub7p93p8Zzcu3uctgf9Xiufa7GbYU7j25Nyltg/sxsotyaVbM+5M7Y7Dxr/zEDtR/NcnfO 912fv38Se+QT4U1h6Sw3i07t6VJiKc5INNRiLipOBADp6WpXEQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/atlas/rZfcsd84mPl1TpxVfGuP2l2Fn14>
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: Tue, 26 Jun 2018 03:46:33 -0000

On Sat, Jun 23, 2018 at 01:19:16AM +0530, Abhijan Bhattacharyya wrote:
> +1 Dan.
> The draft https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-01 also proposes how the session initiation part of DTLS can be switched to CoAP to optimise the resource usage during session establishment by leveraging the lightweight semantics of CoAP. Also, to accomplish the stated objective of establishing end-to-end security association in a secure manner and managed at the application itself. The draft also tries to be less disruptive to existing DTLS implementations by defining an adaptation layer that ensures channel security by allowing the reuse of the existing DTLS record-layer encryption through the session key tuple from the CoAP layer. Of course there can be several other ways to accomplish this than what has been described in the draft.

There seems to be some "novel crypto" in here; it would be good to build on
standard blocks like Needham-Schroeder (e.g., as realized in Kerberos), to
make sure all the needed key confirmation and freshness properties are
realized.  The best freshness properties tend to occur when one endpoint
proposes a subsession key that must be confirmed by the other, which then
produces its own sub-subsession key that is likewise confirmed by the
original party.  It's best if there is contributory behavior for the keys
as opposed to just encrypting sub-keys in the previous key, though that
does tend to involve more hashing which induces cost.

-Ben