Re: [Lake] LAKE next steps
Göran Selander <goran.selander@ericsson.com> Thu, 22 August 2019 13:27 UTC
Return-Path: <goran.selander@ericsson.com>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1E9120103; Thu, 22 Aug 2019 06:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ktFBi37nTwa2; Thu, 22 Aug 2019 06:27:51 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60051.outbound.protection.outlook.com [40.107.6.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7FD1200F8; Thu, 22 Aug 2019 06:27:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jVFiPQMHPtmZAke93XPQJRdZL+h6YghZHNmYg3NYR+hrSlbH8iFthqMGyixeIbBZ3bjc6yOH89FC9ZnH067EPERXScV18ltdh/eATprf192f9qxnTAhKiWqG4S0NfAaFt3R70i33wLorFMsRd9JpdwAtE5rvwu+pEoGrRkIUtBYDTEvK+THEu/7QVPIeifum//baubJSB5juuCTRyGExs6BqQzQvzCwy9o4+MpqkY6ysI0qW40p8A01rTTjTyzcwYTC8bWV8lfPXUHSwRntB4Y3AH7KeXpTZ4poiGDDo9nxBTMGGVbJLCwmm7/XRThmyLrCJfYQ631KQH+L0ogAYVw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dZQQsTpRTtgo4p1d7/P6MHF1wtgYlwC6sM+mCOBrD7c=; b=jhMlqaaGJ2CFdCvEDJ/l1NmkQNZKBfDin7Yj3JdriFJzJDGarl6KxoX0d5/WXxBm45RYG2DjyAxpHFjkAAYt9+gdm9B4PI2PS1aruERrKY07LF9hn7TIa5w1IwIkRkaufHS085uFbVIlmZFeiBrlLoDmEBrgraL8em6MJxp+ZJIF+qcmmN6GhrudNj+u0BJyEW5bGGORQ6OCucfHCVPncx0awiPHPbGaftfLrMds962tXZLM1AsKswiGkaIkS9LG7B/EjUo43ZUyc18qwkDw/EvLapUgblWMRbYqjp6kEKPyBaDYYTk8GFTQcq7ULlTcVY3cENcPGHiJWwf3ApRUFg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dZQQsTpRTtgo4p1d7/P6MHF1wtgYlwC6sM+mCOBrD7c=; b=KdzRDMb7g6tXn7ieVfkkisyMghOQkyucSDDj8GNGqKSHyDVeGQEqy437mdjDR1s8cSAQIZEjtCACNjrzzGwCWmTK6QJE1CkuyHx0juMKXblCZyO069L26eyp+BuWCiCO7EwZfw0m7uKOx7W75uSfsZr3KSSfcX4gZJ7uhJKCpgM=
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3177.eurprd07.prod.outlook.com (10.170.245.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.11; Thu, 22 Aug 2019 13:27:49 +0000
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::d4e8:423d:955c:6a5e]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::d4e8:423d:955c:6a5e%5]) with mapi id 15.20.2199.015; Thu, 22 Aug 2019 13:27:49 +0000
From: Göran Selander <goran.selander@ericsson.com>
To: "lake@ietf.org" <lake@ietf.org>
CC: "secdispatch@ietf.org" <secdispatch@ietf.org>
Thread-Topic: [Lake] LAKE next steps
Thread-Index: AQHVV27+G+o9nwDa0kKha2dOdkjTaKcHTXAA
Date: Thu, 22 Aug 2019 13:27:49 +0000
Message-ID: <DED9B6C1-2E61-4C20-822D-4F22C848EC1E@ericsson.com>
References: <20190820155006.GE60855@kduck.mit.edu>
In-Reply-To: <20190820155006.GE60855@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com;
x-originating-ip: [192.176.1.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 59e9009f-fe85-4fbe-7fd3-08d7270486e8
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3177;
x-ms-traffictypediagnostic: HE1PR07MB3177:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <HE1PR07MB3177E053AAD678E673B22403F4A50@HE1PR07MB3177.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01371B902F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(346002)(39860400002)(376002)(189003)(199004)(14444005)(76176011)(316002)(33656002)(256004)(486006)(7736002)(305945005)(11346002)(446003)(71200400001)(85202003)(71190400001)(2351001)(5640700003)(6436002)(36756003)(4326008)(86362001)(2616005)(14454004)(450100002)(8936002)(85182001)(53936002)(6246003)(99286004)(25786009)(6306002)(6512007)(6486002)(6506007)(26005)(2501003)(66066001)(81156014)(81166006)(186003)(1730700003)(478600001)(8676002)(229853002)(6116002)(966005)(3846002)(2906002)(6916009)(64756008)(561944003)(66946007)(76116006)(66574012)(5660300002)(102836004)(66446008)(66556008)(476003)(58126008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3177; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DioXY6Eiq5otAnGBOjawkMIMVfeLDMEjCTNBpkeVeXDWExgFarp7iJDoJV7ZMVgnVpTjY++8Pouu0UQ9xmUZNJ/zZ2J4a88GNotqDtiGIwVkX/wMktDb0O/iDqNk9BCg9fu83sm9f7aON1ZvvEkFCJMtjys+fX6WCUA32VuNkiNJZ0VZXW6PupiWfn6o+Qpe5Cu1XyDo36ozEX7J8jcA8oH9Mb+fhknGZELpzxVHpIwCDIH6asE97pJqEx/9bIYxYGWTQw4yKcqKhn6ncXB93mshR4wpxJVu1eNIWldLaUmoa5eGE/NnU2t1MHZfZJl5nJtJsfezl2xcw/jrg0lVZ5nlsQ9/Li+fv0EsI9ACzmLZ5FcNz89F0/6xyrc4FZuStlgT6xN5mHkANjiJWMqV5igril4bl4RTKBn3dgsAqMo=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <2A123D0241221C4684D328395FB9326B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 59e9009f-fe85-4fbe-7fd3-08d7270486e8
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2019 13:27:49.1863 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GY5toQUj2dp/x8NDHUyZUO8I+KPvgV5iwzza2xVUpmS1ddGDzGkR9GhTO1OtQIx017uzrYoRToM63V4lTT0N9zPNh4A8c+Jwh7fAxXGG+c4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3177
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/OupmIV74eHqBcb-X0lsIB4q41pM>
Subject: Re: [Lake] LAKE next steps
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2019 13:27:55 -0000
Hi Ben and Roman, If I understand right, the proposal is - in one sentence - to work both on a lightweight authenticated key exchange for OSCORE in the LAKE WG, and on a compact variant of TLS in the TLS WG. This sounds like a good way forward, since an optimal solution to one of the problems is most likely not optimal (or even suitable) for the other, and optimization is one of the reasons for doing this work in the first place. The proposed charter looks fine, I only have one comment on the text, see below. In particular I don't think there is any need to further detail requirements in the charter since those can be agreed with the listed stakeholders as part of the work. Excerpt from proposed charter: 'The working group will collaborate and coordinate with other IETF WGs such as ACE, CORE, 6TISCH, and LPWAN to understand and validate the requirements and solution. The WG will also evaluate work from the TLS WG and derivatives thereof, and draft-selander-ace-cose-ecdhe.' My comment is on the last sentence above. I already commented on this sentence in a previous draft of the charter: https://mailarchive.ietf.org/arch/msg/secdispatch/xJTkOA6zfU0TcQPMYevg8IBUSVk Additionally, I don't think this sentence well reflects the text in your mail: 'From we’ve seen so far, EDHOC seems like the leading contender, especially with respect to the “reuse of COSE algorithms” proposed requirement, but we of course welcome further data (such as on the relative code footprint of core cryptographic primitives vs. protocol integration for COSE/cTLS/etc.).' Detailed comments: 1. It is fine that the WG also evaluates work from the TLS WG, with the obvious restriction that only solutions that are ready and complies with the requirements need to be evaluated. As long as we agree on that, there is no need to change the charter on this point. 2. Please move ", and draft-selander-ace-cose-ecdhe" from this sentence and include it in a sentence before this one indicating that it is currently the only specified AKE for OSCORE. Thanks Göran On 2019-08-20, 17:50, "Lake on behalf of Benjamin Kaduk" <lake-bounces@ietf.org on behalf of kaduk@mit.edu> wrote: Thank you to everyone who attended the LAKE BoF session! It was a productive meeting that highlighted the community’s needs for work in this space. A key insight that emerged during the session was that there is a fairly clear split between the “AKE for OSCORE” case and “general purpose lightweight AKE” in terms of the set of requirements. We are happy to note a strong level of interest in a TLS-based solution that removes unnecessary protocol fields and encoding redundancy, which has significant potential for use in protocols that do not require traditional TLS cross-version compatibility, in constrained and full-featured environments alike. Likewise, we saw that the additional community engagement of a BoF was able to provide new insights into the use cases and requirements for a LAKE [0], both in the OSCORE and the more general case -- this is a great indication of the value provided by the broad and cross-area IETF review process. Based on the input received and energy in the room, we feel that it’s appropriate to charter a WG to finish coalescing the requirements for the OSCORE use case and evaluate solutions. From we’ve seen so far, EDHOC seems like the leading contender, especially with respect to the “reuse of COSE algorithms” proposed requirement, but we of course welcome further data (such as on the relative code footprint of core cryptographic primitives vs. protocol integration for COSE/cTLS/etc.). We also feel that it’s appropriate to find a home for work on cTLS to come to fruition. As noted during the BoF, this presents a multifaceted problem, with input needed from TLS experts as to which parts of the protocol are legacy artifacts vs. cryptographically necessary, and also with input needed from domain experts on constrained devices as to which protocol features are necessary and where to fall on the spectrum of tradeoffs between fully general/full-featured and a stripped-down, bare-bones feature set. On the balance, though, it seems that discussion of a general-purpose-but-compact TLS would be most effectively done in the TLS WG with additional input and collaboration as needed. We plan to ask the TLS WG if there is interest in rechartering to take on this “constrained TLS” work item (and we note that this includes thinking about whether it is best done as a standalone specification or a “patch” or “filter” to stock TLS that could apply to multiple TLS versions). For the sake of facilitating discussion, we include draft charter text for the OSCORE case, modified based on input from the BoF from the version that was previously sent to secdispatch@ietf: ==[ CHARTER ]== Problem Constrained environments using OSCORE in network environments such as NB-IoT, 6TiSCH, and LoRaWAN need a ‘lightweight’ authenticated key exchange (LAKE) that enables forward security. 'Lightweight' refers to: * resource consumption, measured by bytes on the wire, wall-clock time to complete, or power consumption * the amount of new code required on end systems which already have an OSCORE stack Goals This working group is intended to be a narrowly focused activity intended to produce at most one LAKE for OSCORE usage and close. The working group will collaborate and coordinate with other IETF WGs such as ACE, CORE, 6TISCH, and LPWAN to understand and validate the requirements and solution. The WG will also evaluate work from the TLS WG and derivatives thereof, and draft-selander-ace-cose-ecdhe. Program of Work The deliverables of this WG are: 1. Design requirements of the lightweight authenticated key exchange protocol for OSCORE (this draft will not be published as an RFC but will be used to drive WG consensus on the deliverable (2) 2. Specify a lightweight authenticated key exchange protocol suitable for use in constrained environments using OSCORE ==[ CHARTER ]== Thanks, Ben and Roman [0] For example, the total number of key exchange operations expected to be performed over the lifetime of the device, as might be compared against the total lifetime energy budget; and a request to make explicit what had previously been implicit assumptions about the cost of various operations (on various axes). -- Lake mailing list Lake@ietf.org https://www.ietf.org/mailman/listinfo/lake
- [Lake] LAKE chartering discussion Michael Richardson
- [Lake] LAKE next steps Benjamin Kaduk
- Re: [Lake] LAKE next steps Rene Struik
- Re: [Lake] LAKE next steps Martin Thomson
- Re: [Lake] LAKE chartering discussion Benjamin Kaduk
- Re: [Lake] LAKE next steps Göran Selander
- Re: [Lake] LAKE next steps Benjamin Kaduk
- Re: [Lake] LAKE next steps Benjamin Kaduk
- Re: [Lake] [Secdispatch] LAKE next steps Benjamin Kaduk
- Re: [Lake] [Secdispatch] LAKE next steps Eric Rescorla
- Re: [Lake] LAKE next steps Rene Struik
- Re: [Lake] [Secdispatch] LAKE next steps Göran Selander
- Re: [Lake] LAKE next steps Yoav Nir
- Re: [Lake] [Secdispatch] LAKE next steps Phillip Hallam-Baker
- Re: [Lake] LAKE next steps Rene Struik
- Re: [Lake] [Secdispatch] LAKE next steps Benjamin Kaduk
- Re: [Lake] LAKE next steps Benjamin Kaduk
- Re: [Lake] [Secdispatch] LAKE next steps Benjamin Kaduk
- Re: [Lake] [Secdispatch] LAKE next steps Göran Selander
- Re: [Lake] [Secdispatch] LAKE next steps Michael Richardson