Re: [Ace] EST over CoAP

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Mon, 14 May 2018 14:51 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C5E12D94C for <ace@ietfa.amsl.com>; Mon, 14 May 2018 07:51:40 -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 u6UNFEL_Qnti for <ace@ietfa.amsl.com>; Mon, 14 May 2018 07:51:37 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0601.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3975C12D87F for <ace@ietf.org>; Mon, 14 May 2018 07:51:36 -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; bh=xKAshjdtEW65awCF7bSIHk0/iXjIlm4zR+ZLzoO+lOY=; b=E9+uUYa3b0l5iM9Bl+ELqQ+C6cvUjUT22H0U1MiRyVmlYrpEJ2NnR8EYq0tIriVq57sKXqAUbiSAq5oVb7HTw9lOASTlTtvTULmwxwkW7A899eAP5fOG0F/g3j49zgZvSRLNkAul7CWXWAEqZRPq0vv2ehacIefLsZ54cArpi14=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1917.eurprd08.prod.outlook.com (10.173.73.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Mon, 14 May 2018 14:51:34 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Mon, 14 May 2018 14:51:34 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] EST over CoAP
Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAFfjAAAABx6qAABhSogAAAGbcA
Date: Mon, 14 May 2018 14:51:34 +0000
Message-ID: <VI1PR0801MB211268D68F96722274A6AF1FFA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <VI1PR0801MB21122D93F906F952E5E85C87FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <13072.1526297934@localhost> <VI1PR0801MB2112C2046C3E6EADDAB95B4EFA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <28208.1526309145@localhost>
In-Reply-To: <28208.1526309145@localhost>
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: [156.67.194.220]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1917; 7:JscHkcP00tCHONsZ2T9iaA0D2AWPx0uPTeaPwyCmHK+QylQbgsfrIUnA9p4Gm8EMv8bEDNF4+B81iWffqtiPUR1NRNhEUDYfdf3xDtbKEnhAQJr5lryGww9bq3JQ0ETtjFWEzsRZHUuypwgLYEZ3QebOKDvJGjnFvnRmu/MvhYl6nD43ANsI6js0kdBDJ+o9KPBqT6EqoPodPVJ1dqi3iJR+aGGyIj7H9MAPsPPkW7UW4Qf9VNFZDZ1PTVxO8nAk
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1917;
x-ms-traffictypediagnostic: VI1PR0801MB1917:
x-microsoft-antispam-prvs: <VI1PR0801MB19178BE678E0A74FD8751229FA9C0@VI1PR0801MB1917.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(180628864354917);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB1917; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1917;
x-forefront-prvs: 067270ECAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(396003)(346002)(376002)(13464003)(40434004)(199004)(189003)(51914003)(86362001)(7736002)(3280700002)(93886005)(105586002)(11346002)(53936002)(3846002)(6116002)(2906002)(6246003)(476003)(2900100001)(76176011)(53546011)(59450400001)(6436002)(72206003)(102836004)(106356001)(229853002)(6506007)(305945005)(3660700001)(7696005)(478600001)(5660300001)(26005)(97736004)(81166006)(8676002)(8936002)(25786009)(74316002)(316002)(81156014)(486006)(99286004)(5890100001)(5250100002)(186003)(446003)(66066001)(4326008)(14454004)(9686003)(33656002)(68736007)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1917; 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: iEfJo9ga5S+reALUM23N4wZSrKlWIX9NSYvjfDwrJ74jGhdpQxSaC+3p4alZ72oyuysOu+BifnSVStXU483pjGribHZ2feiafw5mO4/qyEIvHgnpVDNqpnNRq5KTCEfqzYojniQVBMpgYkQ02vpHabqXcYD5SEV6k1z5+4ozqmOzv7f1eUxmXORtOC+ap4b0
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: ddc95515-6662-4f75-4c57-08d5b9aa3017
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ddc95515-6662-4f75-4c57-08d5b9aa3017
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2018 14:51:34.3799 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1917
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/WWZxCtiprBscQg4YFLZqahSg-EM>
Subject: Re: [Ace] EST over CoAP
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 14:51:40 -0000

Hi Michael,


-----Original Message-----
From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]
Sent: 14 May 2018 16:46
To: Hannes Tschofenig
Cc: ace@ietf.org
Subject: Re: [Ace] EST over CoAP


Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
    > Thanks for the feedback.

    > Why do you think it takes so long to get this document finished? In the
    > end, you are just carrying EST over CoAP instead of conveying it over
    > HTTP.

It's not really just us, it's time to get people to do the reviews required :-) It's also constrained about getting other documents out.  RFC8366 spent 4 weeks in AUTH48 due to a small YANG correction discovered at the last minute.
(And we had to bikeshed the title)

[Hannes] Fully understand. I am just advocating that we keep things going at a reasonable pace. I have seen documents hanging around waiting for not further defined events.
Since we are implementing this functionality I want to make sure we don't see surprises last minute.

    > PS: Regarding the use of DTLS/TLS for the proxy. There are obviously
    > ways to get this accomplished but the question for me is whether this
    > functionality should go into this version of the spec or rather a
    > companion document.

I don't understand the use case.
EST requires a secure transport from requesting entity to Registrar.
A DTLS/TLS proxy represents a MITM, and I don't see a way for either party to
trust it.    I have been pushing to better detail how people want this to work.

[Hannes] I guess we will speculate about it when that work gets started in another document.

Ciao
Hannes


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -= IPv6 IoT consulting =-



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.