[core] CoAP-over-WebRTC: Continued interest and use case
Christian Amsüss <christian@amsuess.com> Wed, 05 August 2020 09:52 UTC
Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3E43A13CE for <core@ietfa.amsl.com>; Wed, 5 Aug 2020 02:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qp34vO3qisLE for <core@ietfa.amsl.com>; Wed, 5 Aug 2020 02:52:16 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C6B3A0C9C for <core@ietf.org>; Wed, 5 Aug 2020 02:52:15 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8069640760; Wed, 5 Aug 2020 11:52:12 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 548F6AB; Wed, 5 Aug 2020 11:52:11 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:947b:e942:281b:482c]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 712A6180; Wed, 5 Aug 2020 11:52:10 +0200 (CEST)
Received: (nullmailer pid 3470819 invoked by uid 1000); Wed, 05 Aug 2020 09:52:10 -0000
Date: Wed, 05 Aug 2020 11:52:10 +0200
From: Christian Amsüss <christian@amsuess.com>
To: draft-groves-coap-webrtcdc@ietf.org, core@ietf.org
Message-ID: <20200805095210.GA3251625@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/MDz-ybgjdutlbfswZrLFRVBrqao>
Subject: [core] CoAP-over-WebRTC: Continued interest and use case
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 09:52:19 -0000
Hello coap-webrtcdc authors, hello CoRE group, I think that in addition to the described use cases, CoAP-over-WebRTC can become relevant as a bridging tool for local environments where browser policies make the use of CoAP-over-WS impractical: Browsers are unwillingn to open unsecured CoAP-over-WS connections from HTTPS secured sites. Yet, web applications to control local devices will want to ship via HTTPS to get access to all of the browser's functionality and for general safety reasons. Until someone comes up with[1] and browsers adopt[2] a way to get valid HTTPS certificates for devices without an Internet uplink (or at least without any practical way of regularly obtaining valid PKI certificates), that means that a local gateway (say, something opening a WiFi access point without Internet connectivity, or a local router) is unreachable using CoAP-over-WS from a shipped application. CoAP-over-WebRTC between the browser and the gateway device should, as far as I can tell, be an option there, as the required DTLS session does not rely on PKI certificates but just on out-of-band exchanged fingerprints, which could be transported over XMLHttpRequests to an HTTP server. (That sounds terribly insecure, but a) those exchanges can be OSCORE-protected, and b) it's not like the proxy will be in any way trusted). There has not been any activity around CoAP-over-WebRTC that I could see after the release of the 2017 -02 draft. Christian and Weiwei, are you interested in continuing it, or have any pointers in case I'd like to continue from there? Kind Regards Christian [1]: https://www.w3.org/community/httpslocal/ [2]: I don't have high hopes for the next years -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [core] CoAP-over-WebRTC: Continued interest and u… Christian Amsüss