Re: [core] Tossing around URIs to use outside an application

Christian Amsüss <> Tue, 18 May 2021 10:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E12323A16ED for <>; Tue, 18 May 2021 03:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BJH3rvTvivEF for <>; Tue, 18 May 2021 03:31:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CE5E3A16EA for <>; Tue, 18 May 2021 03:31:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id AFACE407F3; Tue, 18 May 2021 12:31:28 +0200 (CEST)
Received: from ( [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by (Postfix) with ESMTP id D51D8D3; Tue, 18 May 2021 12:31:27 +0200 (CEST)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a014:89c6:8ba:ba93]) by (Postfix) with ESMTPSA id 9D47C10A; Tue, 18 May 2021 12:31:27 +0200 (CEST)
Received: (nullmailer pid 941278 invoked by uid 1000); Tue, 18 May 2021 10:31:27 -0000
Date: Tue, 18 May 2021 12:31:27 +0200
From: Christian Amsüss <>
To: Michael Richardson <>
Message-ID: <>
References: <> <27386.1621332368@localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Sktn/9cP5xkEb8ot"
Content-Disposition: inline
In-Reply-To: <27386.1621332368@localhost>
Archived-At: <>
Subject: Re: [core] Tossing around URIs to use outside an application
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 May 2021 10:31:35 -0000


> I think that the discovery/dynlink process should create a channel
> towards the target.  The channel might include clues, like those returned by DANE.

Agreeing. The URI should suffice -- but if the linking page so happens
to send hints (be they DANE records volunteered over DoH, or something
COSEish in a more constrained-oriented data model), they allow saving
some round-trips.

(Same should, by the way, go for protocol negotiation).

> If we want to avoid disclosing the URL that we using and then get the 4.01,
> then we should doing an opportunistic EDHOC to get privacy.  How (and if)
> that is authenticated is something we should discuss.

*That* is maybe where "is application specific" comes in -- the client
application needs to know at some point whom it may disclose its
operation to:

* the public, doing an exploratory unprotected GET,
* only active attackers, when doing opportunistic EDHOC,
* or only the authenticated server that is authorized to see the
  request, in which case eligible trust roots and kinds of edges there
  have to be configured.


To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom