Re: [Lake] proposed scoping text

Göran Selander <goran.selander@ericsson.com> Wed, 29 April 2020 12:04 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 2961D3A0DB5 for <lake@ietfa.amsl.com>; Wed, 29 Apr 2020 05:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.92
X-Spam-Level:
X-Spam-Status: No, score=-2.92 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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 T3LOc_cfUZ15 for <lake@ietfa.amsl.com>; Wed, 29 Apr 2020 05:04:29 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40045.outbound.protection.outlook.com [40.107.4.45]) (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 B7BC43A0DB2 for <lake@ietf.org>; Wed, 29 Apr 2020 05:04:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mYpwMCCEcqyNsLz8fh5xlsMfAk+FtfZ/pQnYHUETiSROAg6qQkiO566NYnDgZ7csXYiGY0CX79CsHPYD/iipj/6JqjTrWh7JZgin6TtnEPlPMrrBEMAXGSg8acppVzGOVKtXWZOhZd8kOmuQBYdymTsm39hvkGYWm8q3qxc/DbIdmTDDNpqHEqqcQh/jNU2Qu7tni8O9PnIoWUhy7Nd4gHYZvJoSqg47JdJjs9wQH4qISMQTUEQr3UwtYthFnwRq/cXSTcJqojE92AMQVVtODcIfPZPSSu2x0QXugrGdg2f5ax09O5mQAWJaDzxrMbGW6xMhwJxFUGavQwySZEM8nA==
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=aBwfjza9JYMZKr0RPbEDkSdASuDFJpzxm4vWZq3DKiw=; b=WXKC+ahgvipffJYaWLq5fHdAth4F72fZCM8OZZ8msPttaMsPVM1tUyTIxnMwESZ/VVCGvt6qRRSwqsLR0FpVQUx9CcU+Gyz2vMdD3zuT+bFaxf6Xo96mvZppR/thIAqKOa467/+BBL9xETRxOefz/s+RAUcKPjPVHpmovBEH7dAMNzqTB1IDNXsw2vmR+y+Tfzt8CY8D6zXsfe/BcqZ8NPQHfM6SrtnhBaQoO/HJLsvl+HpE5BPhB4SsBS11iPhl0c8IdLz6w4xqrxuWwwxcnG/1FUR2BN93hKC5iU6/Tbur+5URxxZPQHuq/A1nkLMvxWhyDXZO2+ezayyEu6Ld/A==
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=aBwfjza9JYMZKr0RPbEDkSdASuDFJpzxm4vWZq3DKiw=; b=WQvTL2+EQ0skHwKgPNwDoYq1zNELJfD9BzMueC0tLtUn/nLQHgmeWHiuIn5AntionBRJCpLSqr2pyEGv0v6rJg3hCS9FoUfZ4aRItFPMuCxIMSzBNrGeXAHv5+EdyrjK90GTcIwOyCWqWglnh42aIlBHhPh/8N2ydklDbGTo47k=
Received: from VI1PR07MB5023.eurprd07.prod.outlook.com (2603:10a6:803:9e::13) by VI1PR07MB6495.eurprd07.prod.outlook.com (2603:10a6:800:181::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Wed, 29 Apr 2020 12:04:25 +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.2958.020; Wed, 29 Apr 2020 12:04:25 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: "lake@ietf.org" <lake@ietf.org>
Thread-Topic: [Lake] proposed scoping text
Thread-Index: AQHWDbwwxw6VdyVM3EK090880yrRXKhws8wAgAmSdICAB7vjgIAHECQAgAPetoCAAB23gIAARXiA///ifYCAArY4AIAALXyAgAAoWIA=
Date: Wed, 29 Apr 2020 12:04:25 +0000
Message-ID: <1B3EC8EE-FC9C-46FC-A402-B5E5E62B259F@ericsson.com>
References: <3780afd5-7012-d808-9584-07e04913cd19@cs.tcd.ie> <239BEC0D-240F-4830-A7A4-0172B62BD6AC@ericsson.com> <B620C5B0-8DE0-489F-B0B0-2548F3C83B49@ericsson.com> <F3B1DD90-2ACB-41FA-9A41-4ADE2D929A7A@inria.fr> <c1037af3-c48f-40fd-8fb3-5c7d4f549798@www.fastmail.com> <B0DD7218-A4C2-460A-9060-59EFEA1113F7@ericsson.com> <19199e5b-5372-4651-b90b-8a688fba9b19@www.fastmail.com> <89186C99-B479-4FFF-8C28-987EB00F8CC4@ericsson.com> <f6cd0bac-c66a-4bc3-91d2-da68d3833643@www.fastmail.com> <1A9902C8-EECC-4F6B-BE1B-063A247E45C1@ericsson.com> <A329B9F8-0A01-43A5-9BEC-5589D86D1D3C@inria.fr>
In-Reply-To: <A329B9F8-0A01-43A5-9BEC-5589D86D1D3C@inria.fr>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.85]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7d2080db-5654-4df5-6937-08d7ec35765f
x-ms-traffictypediagnostic: VI1PR07MB6495:
x-microsoft-antispam-prvs: <VI1PR07MB649557CF59F08F958F15067DF4AD0@VI1PR07MB6495.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03883BD916
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: fNda1o+jEIwKtm/ID1D5AO8ZKhm/ehVlgDEiQHL48TTXSqrCIoNsMn7Th9MmEj1W0qTRX9lRUih5GXFcWk68RQK/zQhej+NyaHnjBMDr6Nkni6uKmg8ylGJ6pPnlF114rpTVQfyrf7J3ySCqBNNgwKLgIw9LWznOVPR5jv2Wb0iXLO2G9baLR/1pe4k8idh8T+0+tZxqLZ7HCAfDshPsEff8yCnXvNfBgTVsUJNskbsBW0Is4lNiyAuxvE4lgG7ds6sWaBTeHGR+JBbEjVBPBH/3zZIl1h5HXjTjY5GW2BdLVXxD8dZDqfUFjvtetUXQjC4Hq+suVV8fz2Ip/DbWILIOhr8ANlpefGeOcdlXwmqD5hMZTwZsN9gKA8F8ZK3fMmdZELpE0X8Ktdn0pZMuOjG3uDGclsodgxReioO372C88Ijv3VNA15tiOFdh7QxrpkpXa9cMdAeMvrVrA/Mw9ofCXzXVzdcE/GEq5C8RSWSygdDCqix8CCaKomUYTyIk4pcc3xYyeekbzmkWOLSgRA==
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:(4636009)(396003)(39860400002)(376002)(366004)(346002)(136003)(966005)(26005)(6486002)(316002)(6506007)(33656002)(6512007)(8936002)(86362001)(186003)(85202003)(53546011)(91956017)(76116006)(66574012)(66446008)(71200400001)(8676002)(5660300002)(2906002)(66556008)(36756003)(66476007)(64756008)(478600001)(66946007)(6916009)(85182001)(2616005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: LynGmiKXqF6jt+EWt3wXXhzXQsOGz6HHaUNvnYMp+UOLo3uMsZg31NCjj+bjTvwO8LoBV0wxUmygsbHD1MKNY6N8S36LyY/AyGxX8QnW7kf594jGXjwBF4W5qqNN7WRnGsMUdQHUiWoUi5A8GVPKRJfSG1x7cDwnX3YCEX/yL83PzOda0xWnzo/kQ0f6Dl72xQqVfePfo2QuluTvFrxLrbvkfcjQ4iqjFHE3Z6cWQCz/T2OF4zv5f6HG1BEthoFluj3L7t3/t/sobzdKDumROmQKoE88xoqEcSoSEXx/FIJjfbOhn25NFr4IltFaHERDp6+FpnFV6m+F+gbdAs7MAUOW8Ihvo0roe2rWi/iWjP0LRIC3e0huEvpmDA56cIOwcGdm7fhaZEUOm7HmVThAHohVcoJL9RWgiUhyG/s65a2pLEfxqXYh8OJ20/rAhLTlFUzA4Sq3KQ0qLuZ5dJxWTjdervbFeXT32ezi1+FciTHzs7yBHcWzb0KzQdNFB+9EjkFtIxK24ub8/8J+Lfhb2KMrdjS9lKJu2SflTSdWa2fF/Ixa6JUhgXk7cBf8KfBHAZiKwsMgG7dtlxKAaH65tN0X70ET8hi7UtH+3/9NQzsXHHPCmn6IMCxm+KjoZox5D986Pv7OFn7y/UQfmjXnYY07phkGvS/VxquNMkdbgDEzQdhR9FxbSlDQs/wemV2V3bBXEyQ2DXHyfB2c2vwqnbpRFunKEMi8McIBryabvapOiC4iGrYwBMFf/gMZnDcRxgQba2Kxz76r+RIhwxA5CW89OC3MBWSzO9xkau69ZmY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_1B3EC8EEFC9C46FCA402B5E5E62B259Fericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d2080db-5654-4df5-6937-08d7ec35765f
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2020 12:04:25.9110 (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: shkEOGpbPD9EY4M+PkOWOip0Xlgj7YszDOkzZMgIuJb6CGnF27nfhBPE7QH9MyMjo3MUIrP6k9jPYag8dRYSbAI4QgUjKpbt8dV7hHynwEY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6495
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/bos1AsVToZoQ_HlitdL0LNa1YtE>
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, 29 Apr 2020 12:04:32 -0000

Hi all,

Version -03 submitted:
https://datatracker.ietf.org/doc/html/draft-ietf-lake-reqs-03

This version is intended to address the WGLC comments and the following discussion. One editorial comment by Stephen is not addressed yet:
https://github.com/lake-wg/reqs/issues/28
Please let us know if we missed some other comment.

Diff against -02 is here:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lake-reqs-03

Göran


From: Mališa Vučinić <malisa.vucinic@inria.fr>
Date: Wednesday, 29 April 2020 at 13:40
To: Göran Selander <goran.selander@ericsson.com>
Cc: Christopher Wood <caw@heapingbits.net>et>, "lake@ietf.org" <lake@ietf.org>
Subject: Re: [Lake] proposed scoping text

Hi all,

Göran will publish the next version of the requirements document, i.e. the authors’ best guess at resolving the issues based on the current state of discussion on the list and on github. The aim is to solicit comments on the diff and see if we can converge on this document.

Mališa


On 29 Apr 2020, at 08:57, Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org<mailto:goran.selander=40ericsson.com@dmarc.ietf.org>> wrote:

Hi Chris,

Please see response inline.

On 2020-04-27, 17:33, "Christopher Wood" <caw@heapingbits.net<mailto:caw@heapingbits.net>> wrote:


So, this is in fact good news for those who are concerned
about complications, since removing the PSK based authentication
protocol is a significant simplification of design, specification,
analysis, implementation and testing.

   Are you suggesting that the holistic design and implementation of
an AKE that uses certificates is less complicated than use of PSKs?

[GS] I was thinking about the part which we need to specify in LAKE,
not the use of existing protocols for outside the AKE. We could compare
the case of passing a reference to a device certificate to that of
passing a reference to a device public key. What does the receiver have
to do in the different cases? Both certificate and public key needs to
be "validated" by the receiver. If the public key is pre-provisioned
and never revoked that is of course a simpler case, but also has
management and security implications. For the certificate reference it
could be a simple validation request similar to or simultaneously with
the certificate retrieval. Although the security considerations of the
AKE need to prescribe validation, the validation step can be outside
the AKE (assuming case 1 in my previous email). I don't know how to
measure the difference but I was thinking that part to be not so
complicated in comparison to a separate PSK based protocol. For the
case of passing revocation information in the AKE (case 2 in my
previous email) that is of course an additional effort, but there may
be some low hanging fruit in that context.

   Surely if we're considering the cost of implementing the AKE, we ought to consider all its dependencies too, right? That is, if we support certificates, we should probably consider the cost in doing so, and that cost is a measure of the AKE and whatever else is needed to "validate" them.

[GS] Yes, there is a cost associated to a PKI. But there is an even higher cost associated to managing PSK, in terms of provisioning, managing secret keys, etc.  If we consider all dependencies we should also add the costs associated with a compromise, the damage to the asset which is intended to be protected, the loss of brand value, etc., and that the risks associated with PSK-based deployments are much higher. Total cost of ownership is in fact one of the reasons why companies want to move away from manual provisioning towards automated certificate based trust management.

I think it would be hard to prove that the total cost associated with PSK is lower than with certificates, which is the difference between your proposal and what is currently in the requirements draft.

Göran



But, again, I think we should
refrain from the "complication" argument and instead focus on
what we

need to solve (and to get started!).

In contrast to removing certificates from the AKE, removing PSK
seems

not to notably impact the desirable scenarios where this can be
applied, since RPK by reference can perform as good as PSK.
Furthermore, I interpreted Ben's mentioning of PSK and RPK as
just an

example, based on the discussion we had at the latest LAKE
virtual

interim about the cases where a candidate protocol can perform
optimally. Not that this subset necessarily was the subset we
should

restrict to.


it assumes some type of PKI in which these certificates exist
and through

which endpoints handle tasks such as revocation and
transparency.

That may impose requirements on the AKE. TLS had to carve out
extension support for CT and OCSP. Is that something we want to
take

on when starting down the path towards an efficient AKE?

The efficiency of the AKE need not be restricted by allowing
validation

of certificates. This discussion really belongs to the design
phase but

starting it anyway, there are two cases:

   I think the important bit here is that the AKE (TLS) had to be
extended to support these emerging technologies after-the-fact. This
suggests the AKE should minimally be extensible if things such as
revocation are not in scope for an initial certificate-focused design.

[GS] Good suggestion. I think allowing some simple mechanism for
verifying validity should be in the initial scope, but having it as an
extension would be the backup plan.

   That might work. I'd like to hear from others about what they think here.

   Best,
   Chris

--
Lake mailing list
Lake@ietf.org<mailto:Lake@ietf.org>
https://www.ietf.org/mailman/listinfo/lake