[core] Tossing around URIs to use outside an application

[Christian Amsüss <[e-mail]>]

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.

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

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.

The best answer I remember there being was that it is up to the
application to provide an answer. If "the application" is implied to
mean the union of API, client and server software, then I'm not happy
with this answer, for it implies that a URI is designed for one
particular application -- whereas I see a crucial advantage of the web
architecture in the ability to access a resource independent of a full
API or full application.


As locks and light switches still seem to be the canonical use cases for
the IoT, let's think about a light configured to indicate the state of a
door state. (If this sounds odd, think of a darkroom or a "sorry we are
closed" sign in a shop).

I'll make a leap and assume that dynlinks will be used to configure that
light, and that a dynlink-editor application is used. (Any more bespoke
setup method will do just as well, but need the same information). I'm
assuming the `coap` scheme intended for use with EDHOC or similar, as
that's what provides the least information in the URI.

At some point, the URI of the lock (along with any metadata if so
required) will leave the "lock management" ecosystem and enter the
"dynlink" ecosystem (or a more specific light bulb ecosystem).


Some scenarios on what would happen then:

* Just the URI is copied into the dynlink target.

  The lamp obtains the resource in NoSec mode, because nobody told it
  otherwise and the lock is configured for public visibility (which does
  make sense in the "Sorry we're closed" case).

* Just the URI is copied into the dynlink target.

  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.

  As before, the lock is public-readable so the requests go through.

* Same scenario, but the setup tool wants to keep the lamp from ever
  leaking what it's taling about with the lamp (which would, in the last
  scenario, happen if an attacker withheld the DANE record or DNSSEC
  information in general).

  The setup tool annotates the link to the lock resource with an `;osc`
  attribute, so that if no security context can be established, the
  access is not even tried.

* Just the URI is copied into the dynlink target.

  The lamp starts in NoSec mode, but hits a 4.01; it enters an error
  mode storing the error response. The configuration tool, when
  verifying that the dynlink was registered, inspects the response, and
  sends the client's browser through an opaque redirect farm that
  eventually asks "Do you want to grant Some Lamp read access to Some
  Lock?".

  (Suspending the scenario as we continue the same way after the next
  one...)

* The dynlink setup tool obtains the URI from the lock management
  ecosystem, tries to dereference it as the to-be-configured lamp would,
  and finds the 4.01 dat as above.

  (Continuing for both...)

  Having obtained some clearance from what would probably be ACE, it
  passes the obtained token on to the device along with the link.

  I'm unsure how that would be indicated precisely; if ACE is involved,
  possibly the device would not receive metadata with the link but just
  succeed in its next attempt because the AS now does hand it a valid
  token.

* The dynlink setup obtains not only a URI but also some token (but it'd
  be a bearer token so yikes?) from the lock management.

  This would not be a simple matter of copy-pasting any more, but more
  like one of these new-fangled "share" buttons.

  I have little imagination of how this'd play out, but given that that
  "share" button is (at least on the web) just a link again, maybe
  that's a link that the dynlink tool could try to dereference, see that
  it's not yet something it could pass into the constrained device
  (because it starts with https and has unholy long query strings), and
  walks through the same "Do you want to grant..." screen again.

* By comparison: on the WWW being tossed a URI is commonplace; they are
  sent over all channels (text print, QR print, radio announcements
  etc), and usable by virtue of DNS+PKI.

  They are usable without metadata. If a browser was given a URI of a
  lock, it may ask the user to go through some login service but then
  serve from that URI alone.


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?

BR
Christian


-- 
You don't become great by trying to be great. You become great by
wanting to do something, and then doing it so hard that you become great
in the process.
  -- Marie Curie (as quoted by Randall Munroe)