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

Michael Richardson <> Tue, 18 May 2021 10:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C008A3A15F1 for <>; Tue, 18 May 2021 03:06:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jqii0_9XKK-T for <>; Tue, 18 May 2021 03:06:12 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D9623A15EE for <>; Tue, 18 May 2021 03:06:11 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CE4C390F0; Tue, 18 May 2021 06:15:32 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id 2z6x4EjRtTKJ; Tue, 18 May 2021 06:15:31 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 8A222390EE; Tue, 18 May 2021 06:15:31 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 758151675; Tue, 18 May 2021 06:06:08 -0400 (EDT)
From: Michael Richardson <>
To: Christian =?iso-8859-1?Q?Ams=FCss?= <>,
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 18 May 2021 06:06:08 -0400
Message-ID: <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:06:18 -0000

Christian Amsüss <> wrote:
    > A thing that came up in last week's interim is the usability of URIs
    > that you are just "tossed", with respect to secure usage.

Yes, I agree that this is an issue.
I've been thinking about it all day yesterday.
(Since I was awake at 4am for RIPE82, and I passed out on the couch in the
mid-afternoon, I have to repoprt that I actually kinda dreamt about this.
This is a kinda of "day-mare" that I just don't recommend.)

    > (And apologies for the long mail; if I had the clarity of the problem
    > I'd like to have it would be shorter).

I always thought that Mark Twain first said this, but apparently he might
have been quoting, and it might have been Voltaire who first said this.
I've omitted your UI thoughts, because I think that they are mostly spot-on,
but may be distracting.

    > For reference, a question was whether EDHOC-authenticated CoAP would
    > use its own "coape" scheme, or if not how a user of "coaps" would know
    > whether it's DTLS or EDHOC+OSCORE secured, or (given coaps implies
    > DTLS) how a coap user would know whether to use plain CoAP or try
    > EDHOC, and if so at which authentication endpoint with which
    > credentials.

I think that we should just focus the discussion here.
I think we probably need a coape:// scheme, but coap->coape upgrade should be common.

EDHOC is unlike DTLS (or HTTPS before it), because doing EDHOC requires
transactions at the CoAP layer to resources other than the intended target
Given that we do all of this because we think that we might be proxying
through other transports (TCP X HTTP X BTLE) I think that any kind of DNS or
discovery ahead of time may be a irrelevant.
I think that the discovery/dynlink process should create a channel
towards the target.  The channel might include clues, like those returned by DANE.
But, I think that we must always be prepared to accept 4.01
(or maybe another new code) says to authenticate.  We might get this code
even though we already think we have an EDHOC session up, because maybe we
used the wrong credential.

    >   As it finds a DANE record with a public key along with the name it
    > resolves, it initiates EDHOC expecting that public key; for itself it
    > sets a key-by-value as it has no key it expects to be usable for that
    > server.

I can accept this as a hint process.

    > What I'm leaning towards taking from this is that we should be able to
    > support tossable URIs, but what they would look like in practice in a
    > CoREnvironment may need looking into.

    > Do you think that would work?

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.

Michael Richardson <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide