Re: [Lake] proposed scoping text

Göran Selander <goran.selander@ericsson.com> Wed, 15 April 2020 12:19 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 BD1B23A0DBB for <lake@ietfa.amsl.com>; Wed, 15 Apr 2020 05:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.268
X-Spam-Level:
X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 m3RIZa8rZUad for <lake@ietfa.amsl.com>; Wed, 15 Apr 2020 05:19:27 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80080.outbound.protection.outlook.com [40.107.8.80]) (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 AEB7B3A0DB9 for <lake@ietf.org>; Wed, 15 Apr 2020 05:19:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hd0BLARB/a+qSnjsyN4xm2XdKGLSXUUtvlUgUE0uYIn6sf6GlfwsJxU7E5FXr0duQvyZk6jofjXUWw+6i+qvTqm1uFAipT6wA6IjPUigHtLloOiUY/e5HLMvWiIjOGPmkTkd0xx1eQgcW6vJX557XWlu9qEPIPN8TGA9A6wd5u+NaLvIYn53+IJri/I0GDNAl2C7WNZj5pcsdX4qfm5mEgFIazVoWfv9W7W89KfJVDVCL7STw4bXyaQTf6EEAYU2iCKiuISX4J3y4m09PgQdPezsi382GfvjK/MDl1awoZgUSUdwkct2F3UwuLPG7sW3XRZJLe6GZT2AAtPkd8A5Qw==
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=QnKZ0TRmV1DM2/y47bdh/VIOovYzKFiZOrRVTJYe+YY=; b=IkkopBb60JWiVGCjwDNfxeQk1pfNjb5qUPSUqB1u/ePdxjEeaFo0I/VlPzRE2rn0PvvC7yJFudVwONS/7SdEwJauIXTB47tX0iNR8RDpBcKiAXMH9EF5Ml68VOXEIx8xhsVZfeIpC13wIScx77g4XvkQZzML5YtLkTkkQvY3/vjoKzXYB0j3wLDv67XjN/1nzZpTuiu09mnPY5dxNfQT48Uh/0lAI3WE7UCDqU5o8D2wiIFMUfl7aPRfefaH5odC1Y8fjUGpi7T/WdoKpJFnr5/rqFmNB2akOeyyVfgqpgs9RGTQDwWqaTEMHdXT5wK5b7WxfiC4XYuHURCWaRFvlg==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QnKZ0TRmV1DM2/y47bdh/VIOovYzKFiZOrRVTJYe+YY=; b=j8gWs/qjF+3/K9b/KeMQwV5OOQkp3SJiub6sMyZ2VNtfnHwmSUFYU93M5BUgrN1L/7cq0nVzVpCKpRq7ISvCNW1dfZn4jF93Mq4/3KtCYT/Lv/wn3v6pze67Ud7EgihBWHAbifgPU6X9vGSO70+TbOMpd3KMjSde1dRgYnkZ080=
Received: from VI1PR07MB5023.eurprd07.prod.outlook.com (2603:10a6:803:9e::13) by VI1PR07MB4206.eurprd07.prod.outlook.com (2603:10a6:802:5b::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.23; Wed, 15 Apr 2020 12:19:24 +0000
Received: from VI1PR07MB5023.eurprd07.prod.outlook.com ([fe80::7c90:eb1a:e7da:2321]) by VI1PR07MB5023.eurprd07.prod.outlook.com ([fe80::7c90:eb1a:e7da:2321%7]) with mapi id 15.20.2921.024; Wed, 15 Apr 2020 12:19:24 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>, "lake@ietf.org" <lake@ietf.org>
Thread-Topic: [Lake] proposed scoping text
Thread-Index: AQHWDbwwxw6VdyVM3EK090880yrRXKhws8wAgAmSdIA=
Date: Wed, 15 Apr 2020 12:19:23 +0000
Message-ID: <B620C5B0-8DE0-489F-B0B0-2548F3C83B49@ericsson.com>
References: <3780afd5-7012-d808-9584-07e04913cd19@cs.tcd.ie> <239BEC0D-240F-4830-A7A4-0172B62BD6AC@ericsson.com>
In-Reply-To: <239BEC0D-240F-4830-A7A4-0172B62BD6AC@ericsson.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.35.20030802
authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com;
x-originating-ip: [192.176.1.85]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0208949c-cf2b-4d16-2032-08d7e1373be2
x-ms-traffictypediagnostic: VI1PR07MB4206:
x-microsoft-antispam-prvs: <VI1PR07MB4206356AFE104593A370F3DFF4DB0@VI1PR07MB4206.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB5023.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(346002)(396003)(376002)(53546011)(2906002)(85202003)(26005)(66574012)(6506007)(478600001)(33656002)(71200400001)(8676002)(2616005)(81156014)(186003)(316002)(5660300002)(110136005)(8936002)(966005)(86362001)(66556008)(66446008)(85182001)(6486002)(36756003)(76116006)(64756008)(66476007)(91956017)(6512007)(66946007); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PXpJ96q2rUhfV4vnIvDtBhykAQXXAV/maSywEHZR0GTEOfA9hStZomrlyC4eLhbDvi/f/KnwpDJNRc5yey+o7gX6dL2mNNAmR8lQSl4nbvWRvo05MHt3ACN41ZAe4OhcwC3UgyiNbOaTLbJNy6jkwgZIzfjK4XlYNT12G89XZRzrtcHg0Tm5/noZ902dwEffhyxYXwpBvGOYfsfwtV6Qmm5oz1KEf1C9moZ8fD7OXrCbYhlu0DXsA0eZw4pAigtmQjHnFIdXA27ISrNCfbjQMldmVRd3u9LxinyblSmgii/57FirTJC7GN2m4lLK1diiklnJ9CRz6IIa08gXOQPmANsiM9GISdxuom9qCRn3OBBOj0xTrkMMXUf9fS3X3bwec3Iy7sGgpFz3lGLOU+Z1aQsPig9mOrILlviqYwpWiwastAJkLK/ops8+FwoGgBb5mWAPJaFZ0kw0hR8YTDOJ0dzu/htgA+wu0IRWJvf04sfPWMLLgxU6AH4pkdjt5zYGvWtvhvhskkYJuCZenUvhFA==
x-ms-exchange-antispam-messagedata: COlZnzheO4bM5rXvnC9Lx9JhYfrsXzGkReb7WVAmQQoxk3UCxRN24S8Kzvhri1IsbBB9QhEGtqKVM6HiN98WEm9tBlMRmWIlnP5kvnA0s6GFeaft7Fpcp1Rn9SocIYQvlcs0bHaUR3j/QHNGFhRNsg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <659B8702B976854D86F297B5652AF35E@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0208949c-cf2b-4d16-2032-08d7e1373be2
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 12:19:23.9550 (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: lORDZUA+w+fl0UbyJHW4uvU4wD59Yb7qJyE3oDcpMOPfp5PksWSxoTy7ut35PJEDqZ0elnc/wmvnj8CuOCelcwpnv0RGJYxhImkoFPHk55c=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4206
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/5BsQgb9gQ5sgFzVwBvqa5qmTnVE>
Subject: Re: [Lake] proposed scoping text
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: Wed, 15 Apr 2020 12:19:29 -0000

Hi,

Here is a proposal how to formulate the scoping in the requirements draft:
https://github.com/lake-wg/reqs/pull/26

Göran


On 2020-04-09, 12:09, "Lake on behalf of Göran Selander" <lake-bounces@ietf.org on behalf of goran.selander=40ericsson.com@dmarc.ietf.org> wrote:

    All,
    
    TL;DR: I propose LAKE to initially focus on RPK, and certificate by reference.
    
    =========
    
    Apologies for a long mail. Comments on Ben's proposal for a way forward at the end, but first we need to take a step back and try to understand what we are discussing.
    
    We are working on requirements for an AKE for OSCORE. We require a lightweight AKE, since OSCORE may be applied in constrained IoT applications. Now there is a discussion about restricting the functionality of LAKE to address only the most lightweight scenarios, so that another AKE should be used in non-lightweight settings. While this may be an economy of standardization, this does not make sense for many reasons.
    
    * Note that OSCORE is expected to be applied in both in constrained and non-constrained environments. OSCORE works whereever CoAP does, and CoAP is expected to be applied in PSK, RPK and certificate settings.
    
    * Implementation-wise OSCORE is more or less integrated with CoAP, because it reuses CoAP processing. A combined OSCORE/AKE implementation will thus be more or less integrated in CoAP. So how should a developer handle the situation that there is a specification of AKE1 addressing part of the credential space and another completely incompatible specification AKE2 addressing another part? 
    
    * OSCORE is designed for end-to-end security from constrained device to cloud. To be sure to support OSCORE based security you need to implement both AKE1 and AKE2.
    
    * How could it be better security-wise to have two different AKEs for one security protocol? Twice the number of security analyses, etc. are needed. 
    
    * Many companies want to move away from symmetric-key based IoT deployments to public key based, ideally to device certificates. If their current technology does not support transport of certificates, but maybe will later,  should they implement AKE1 or AKE2?
    
    * etc.
    
    Summarizing: At some point in time there needs to be one single AKE for OSCORE that is sufficiently lightweight to perform well in the most constrained settings but also has the functionality to protect CoAP for whatever settings it is expected to be deployed in, and that involves PSK, RPK and certificates.
    
    =======================================
    
    Having said this, it may still be relevant to discuss which cases are most important right now, bearing in mind that this scoping should not prevent later adding the remaining components.  
    
    One way to prioritize the scope of the first work on the AKE is to address a) the needs from current use cases, and b) the potential to provide something useful that is not already available:
    
    a) There is a general request to deploy a lightweight AKE with OSCORE targeting general CoAP use cases 
    i.e. based on PSK, RPK as well as certificates. More specific work items I'm aware of include RPK-based solutions (e.g. LoRa Alliance) and mixed RPK/certificate based solution (e.g. draft-selander-ace-ake-authz). As mentioned in my previous email, a PKI-based solution is necessary to handle IoT deployments with a large number of devices and many manufacturers, but the certificate does not necessarily have to be transported.
    
    b) It is possible to do PSK and RPK by reference for the most constrained benchmark (1,1,1). RPK by value and certificate by reference can also be very lightweight, but may require more than one fragment per message. However, in case of transporting a chain of X.509 certificates, or even a single X.509 certificate, it is not clear that a lightweight AKE performs significantly better. 
    
    The intersection of a) and b) correspond to where there is an active interest in a solution and where the solution can be made lightweight: RPK (by reference and value) and certificate by reference. 
    
    This restricted scope leaves out the most lightweight and the least lightweight options. Removing symmetric key based authentication from first scope is a significant simplification since this is a different protocol in many respects compared to the asymmetric version. Moreover, since PSK and RPK by reference can be handled with the same transmission cost, there is less motivation for using PSK ECDHE as an intermediate deployment step.
    
    Now for Ben's proposal:
    
    On 2020-04-08, 17:41, "Lake on behalf of Stephen Farrell" <lake-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:
    
        Ben's proposal is:
        
        "
        Strip down the requirements document a lot, to have a
        qualitative sense of "these are the combinations of crypto
        primitives that we consider important *right now*" (e.g.,
        PSK and RPK). Have an acknowledgment that extensibility is
        inevitable, but disclaim that we are focusing on getting it
        right for these narrow cases right now, and if someone
        wants to do a broader case in the future, then more
        analysis will need to be done at that time.  
    
        But for now,
        we focus on getting RPK and PSK into:
        
         3 flights, 51-byte messages, and do that well.
        
    [GS] Focus on RPK (by value and by reference) and certificate by reference, and do that well. For RPK by reference: 3 flights in (1,1,1) fragments. For RPK by value and certificate by reference the number of fragments should be kept at a minimum.
    
    
        If we end up with protocol X that does RPK well and
        someone has it deployed but wants to expand their
        deployment to also use certificates, they can extend
        protocol X to do that and have a fairly homogeneous
        deployment, vs. having to have a mix of protocol X
        and TLS.  It may well be that TLS would do fine for
        their extended use case, but not the original use
        case, and having a homogeneous deployment is valuable."
    
    [GS] Agree.
    
    Göran 
    
    
    
    -- 
    Lake mailing list
    Lake@ietf.org
    https://www.ietf.org/mailman/listinfo/lake