[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