Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Martin Thomson <mt@lowentropy.net> Tue, 23 June 2020 04:00 UTC

Return-Path: <mt@lowentropy.net>
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 DA1933A1727 for <lake@ietfa.amsl.com>; Mon, 22 Jun 2020 21:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=bw9Bmq9y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cpGdWtaA
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 8fA5rktSpAV9 for <lake@ietfa.amsl.com>; Mon, 22 Jun 2020 21:00:38 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D7F3A1722 for <lake@ietf.org>; Mon, 22 Jun 2020 21:00:38 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id B930F15E2 for <lake@ietf.org>; Tue, 23 Jun 2020 00:00:37 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 23 Jun 2020 00:00:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=ZfBm/ CfwQX0yR4pwUBR089CrzVTtpJVJDM0IpTElq+M=; b=bw9Bmq9y/a03G+viFU7+6 9vnViKNV2dSilhhPkhTrrUOY22Ri8p9292Ud6y2xuaFmLdfVs3Agt9IVzT/KhHOy RJzwAkkv+JBjWoHtSov6hltH7KAbcfuHvlLo7zYdyEil6WAGceecmUlP+CJ7MHt0 /MA3t8Dq8MXN++Mj5mxW85wfW7L4PzKtvfw9G5+fEdT3rowh2akpI/4DihC4DNQx WYMqtfgQ48CiB9nh1HQ3oEjunFdj7c4eImzCT32p6FGSkeXln83dzcrOCCKDuU0T 44baInMxWeY3U5xi9uZpINzTxGhyeKnfCH/Gm67UJDxgxvbdZxombHH/V2Y+wBY4 w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ZfBm/CfwQX0yR4pwUBR089CrzVTtpJVJDM0IpTElq +M=; b=cpGdWtaAkhuBOyG4Z3rD+4ZXLx+cE5TqRVAt4ku6dcvN1GiXTmOYvhF9l 1nPoyS5fKlNxmtN7lPDneMMqBpJR1brmhHAtTy3rD7eaDYNaAjYymuXi98/n7+Gj pKtw/VpYRigDa223R4RqRrlu5Uwd+HLZZzRTdh41cgfAqkosyIhslArI/wMvc38f kKmbfM2t3sCkqilyNNmnLVlCBqvxLMPCiweoEFKHOCACN2ojNV6FoId4YPh1mm2u QKAvRdWN33bxTsag9j6uKKf3pqSUsnUlFL+LRCH/TcP9IyZAegTYgfsAkWtyUugc 7lyYF3FU5ga+BRkFCYAd/p0Ss8FLw==
X-ME-Sender: <xms:ZX7xXusGLw34drWzeSCnbgTBKKic69D4KwvwzQY9weybPgaPF4dFkw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekfedgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepvdegieeffeegffduje euueffjedvgefhgefftdetueeuhfekledvjedvjeegudejnecuffhomhgrihhnpehivght fhdrohhrghdphhhtthhprdhithenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:ZX7xXjcw109_LVPhYtpf5fRnHVS1mB5_LJ8ZDAseF2Nung_bf1D04w> <xmx:ZX7xXpxJBXAvjS0kNYfCJBnc47UK00XSe3gERpMrSIPVYsiam7lfmA> <xmx:ZX7xXpPrFdsMowbZ0YG27cBx428E9ivlVL9ZWhm8FAJx1kvuy4Ch6g> <xmx:ZX7xXofcUIwvtE0JZMAbuzE7IeAxuCcFuKHM2OMD9jUQ_9xZ57YSLw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 08877E00A8; Tue, 23 Jun 2020 00:00:37 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-543-gda70334-fm-20200618.004-gda703345
Mime-Version: 1.0
Message-Id: <9a78436c-feb7-45a8-a9a5-31c169c649d5@www.fastmail.com>
In-Reply-To: <89EA6A63-AB99-4649-9F08-D6FBDE1DEF2F@inria.fr>
References: <89EA6A63-AB99-4649-9F08-D6FBDE1DEF2F@inria.fr>
Date: Tue, 23 Jun 2020 14:00:16 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: lake@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/yCl6U3WJR8o2Zd_UW8AeUpxLlUI>
Subject: Re: [Lake] =?utf-8?q?Call_for_adoption_for_draft-selander-lake-edhoc?= =?utf-8?q?_-_respond_by_June_22?=
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: Tue, 23 Jun 2020 04:00:40 -0000

On Mon, Jun 8, 2020, at 23:54, Mališa Vučinić wrote:
> we are now launching a call for adoption for 
> https://tools.ietf.org/html/draft-selander-lake-edhoc-01.

I was reluctant to respond to this thread, because it generally isn't worth stopping other people from doing something they want to do.  And I'm aware that the contract implied by the formation of this working group - at least in the minds of many - was the development of a new AKE.

The time that others spend isn't the only factor we should use to decide.  As others have noted, adoption of an entirely new AKE means more than just the time that those other people spend.  I have no skin in the maintenance of IoT products, but the concerns raised about fracturing and maintenance overheads there are serious.  My concern is for the split this creates between endpoints that choose option A and endpoints that choose option B.

When CoAP was proposed, I didn't have the same presence of mind as others [1] to recognize the harm inherent in defining something like HTTP that wasn't HTTP.  It's easy to point to adoption of CoAP and use that to claim success, but that misses the true costs.  The true failure is the creation of a set of endpoints that don't talk to other endpoints.  The IETF made the choice to actively help create a division in the market.  Maybe these endpoints might never have been able to communicate (MQTT is, after all, largely outside our control), but the choice by the IETF to XKCD 927 didn't really help.

For us, this failure manifests in a great deal of expenditure on parallel infrastructure and standards development.  For the market, who we leave to choose, the cost is in the creation of non-interoperable islands.  The market also pays through the dilution of resources that we dedicate to the improvement of the commons, of which protocols are some of the most valuable assets.

[1] https://tools.ietf.org/html/draft-montenegro-httpbis-h2ot-00