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

From: Christian Amsüss <[email-masked]>
Date: Mon, 17 May 2021 14:46:46 +0200

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)

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 17 May 2021 13:37:34 +0000

Hi Chris,

On 17/05/2021, 13:47, "Christian Amsüss" <[email-masked]> wrote:
> * 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.
>

This was probably true before QUIC and ECH.  Now an HTTPS URI needs more
context to be successfully dereferenced.

> CoREnvironment may need looking into.

For deployments with DNS, an SVCB [1] profiled for the needs of CoAP and
its secure substrates may be an efficient way to handle these "tossable"
URIs.

cheers!

[1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 May 2021 16:37:57 +0200

> [1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https

… and we should define an information model for this so we aren’t stuck with DNS for providing that information.

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 17 May 2021 14:58:00 +0000

On 17/05/2021, 15:38, "Carsten Bormann" <[email-masked]> wrote:
> > For deployments with DNS, an SVCB [1] profiled for the needs of CoAP
> > and its secure substrates may be an efficient way to handle these
> > "tossable" URIs.
> >
> > cheers!
> >
> ...and we should define an information model for this so we aren't
> stuck with DNS for providing that information.

Emphatic +1

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 May 2021 11:09:59 -0400

Thomas Fossati <[email-masked]> wrote:
    >> are sent over all channels (text print, QR print, radio announcements

    > This was probably true before QUIC and ECH.  Now an HTTPS URI needs
    > more context to be successfully dereferenced.

Uhm, that's not my understanding.
If both ends support QUIC, then the HTTPS is replaced with QUIC, otherwise it
continues with HTTPS.

    > and its secure substrates may be an efficient way to handle these

Yes, so SVCB seems to be just more data like AAAA.

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

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 17 May 2021 16:05:30 +0000

On 17/05/2021, 16:10, "Michael Richardson" <[email-masked]> wrote:
> > > * By comparison: on the WWW being tossed a URI is commonplace;
> > >   they are sent over all channels (text print, QR print, radio
> > > 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.
>
> If both ends support QUIC, then the HTTPS is replaced with QUIC,
> otherwise it continues with HTTPS.

Even if you support QUIC, the trouble with an HTTPS URI (i.e., one with
the 'https' scheme) that has been given to you is you can't know in
general whether the other end will successfully negotiate QUIC with you
or not before you actually try, which is inefficient.  The problem with
an HTTPS URI where the server endpoint is ECH capable is probably more
compelling.  In that case the client doesn't have the luxury of an
inefficient discovery that wastes a few round-trips to get the server's
public key via Alt-Svc or ALPN, it only has one shot :-)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 May 2021 06:06:08 -0400

> 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.)

    > 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
resource.
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.

    > sets a key-by-value as it has no key it expects to be usable for that

I can accept this as a hint process.

    > 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.

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 18 May 2021 12:17:33 +0200

> … and we should define an information model for this so we aren’t

Whatever comes out of the EDHOC discussion about transferring public
keys by value could also serve this purpose. In [82] and [88],
contenders for that seem to be stripped-down `COSE_Key`s, C509
"certificates" (AIU they're not necessarily certificates but can be RPKs
just as well) and CWTs.

This has some overlap with what can currently be expressed in DNS
(public-by-value would relate to SubjectPublicKeyInfo).

BR
c

[82]: https://github.com/lake-wg/edhoc/issues/82
[82]: https://github.com/lake-wg/edhoc/issues/88

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

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 18 May 2021 12:31:27 +0200

Hi,

> 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).

> 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.

Thanks
c

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 22 May 2021 14:44:32 +0200

> that you are just "tossed", with respect to secure usage.

In addition to secure usage, this came also up with respect to the
vocabularies used e.g. in CoRAL documents. I.e., if we need to pass
more than just a URI, such as security-related information, could we
also pass vocabulary-related information in the same way?

> CoREnvironment may need looking into.

That might be closely related to the question what a tossable URI in a
CoREnvironment is precisely... When a Web browser is tossed a URI,
it's preconfigured with a set of root certificates and a single
purpose: Make a GET request to that URI and render the resulting HTML
document. In a CoREnvironment, there are probably no root certificates
and no predefined purpose. At a minimum, you probably always toss a
URI together with something like "Your resource directory is at this
URI" or "Please POST your sensor data to this URI". Additionally, you
probably also need to configure some certificate/PSK and the
intents/wills of the stakeholders/principals involved. Maybe some of
that needs to be set directly, maybe some could be discovered through
a layer of indirection. Is there something we could standardize here?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 22 May 2021 22:09:04 +0200

I think we are reinventing link relationships, just better.

You can’t really “toss” a URI, you are tossing a document (that contains the URI).
If that document does not specify a link relationship (a purpose), you need application state going along with that or you don’t know what to do with the URI.
If that document does contain a link relationship (and possibly further parameters), these become part of the application state, hopefully together with the provenance of that tossed document.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 23 May 2021 12:17:07 +0200

> If that document does contain a link relationship (and possibly further parameters), these become part of the application state, hopefully together with the provenance of that tossed document.

That's an interesting thought. I guess, a fully self-contained
document could then look a bit like this:

    Please register your resources with the resource
    directory at <coap://example.org/rd>
    * But I don't fully trust it, so better only
      register your public resources
      (will of the device owner)
    * Also, the resource directory allows you to
      register only resources related to
      YetAnotherEcosystem
      (will of the RD owner)
    * To access the URI, you'll need to have an
      OSCORE security association with example.org
        * example.org has the RPK certificate h'...'
          (certificate pinning)
        * Please set up the security association
          using EDHOC at <coap://example.org/edhoc>
        * But I don't want you to use any ciphersuite
          based on SHA-1
    * To access the URI, you'll also need an
      authorization (bearer) token
        * Specifically, you need a token with the
          scope "Register YetAnotherEcosystem
          resources in a resource directory"
        * You can obtain the token using ACE
          from the authorization server at
          <coap://as.example/>
            * Please connect to as.example using DTLS
            * Use these X.509 root certificates for
              that: ...
    * When you access the URI, you'll need to
      understand the CoRAL vocabularies
      'coreapps.org:resource-directory' and
      'coreapps.org:problem-details'

This could even be part of a CoRAL document. For example, if server A
serves a CoRAL document with a link to a resource on server B, then
server A could tell the client what it thinks is server B's RPK. That
would give the client immediately feedback if it's actually talking to
the server that server A intended (rather than, for example, a server
B that has changed ownership in the meantime). Of course, then the
question is, how server B could update all the links on other servers
pointing to it if it legitimately wants to change its keys,
authorization policies, or CoRAL vocabularies...

Klaus

---

From: Christian M. Amsüss <[email-masked]>
Date: Tue, 25 May 2021 11:30:14 +0200

Hello,

> also pass vocabulary-related information in the same way?

Well we already *have* methods for hint-level metadata, as in ct="0 40".
(Not sure whether we'll want to use content format numbers there or
something on a more detailed level, but I think it should be hint-level
negotiation just the same, with multiple possible representations of a
resource).

> When a Web browser is tossed a URI, it's preconfigured with a set of
> root certificates and a single purpose: Make a GET request to that URI
> and render the resulting HTML document. In a CoREnvironment, there are
> probably no root certificates and no predefined purpose.

There may not be root certificates, but I think that the same semantics
can still be applied: If someone requests, say, that a resource's
representation be shown on a display, and gives the resource's name as
"https://exmaple.com/logo.png" or "coap://example.com/logo.png", in both
cases a PKI'd certificate is a sane default to provide.

Sure, for most plain IP addresses, no such guarantee ca be made, but
even that may not hold: If the IP address is part of a VPN, host
authentication would be such a sane default. Similarly,
"https://3g2upl4pq6kufc4m.onion/" is also self-contained in that any
host that can access the resource can also make sure the server's
identity is what whoever sent the URI intended.

(Same goes for URNs, by the way: When someone hands over a blob and
claims that to be identified by urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
that can not be verified without more context. But nih:sha-256-32;53269057;b
can be used to verify alleged representations).

> At a minimum, you probably always toss a URI together with something
> like "Your resource directory is at this URI" or "Please POST your
> sensor data to this URI".

Yes -- either (as Carsten observed) in a link relation, or by the
precise point you place the URI. (Even if a system were not to work with
link-format or CoRAL style links: If, on a thusly defined system, you
PUT a plain URI to /2/0/1/3/2, that may *mean* "this is the resource to
POST your sensor data to").

On Sat, May 22, 2021 at 10:09:04PM +0200, Carsten Bormann wrote:
> If that document does contain a link relationship (and possibly
> further parameters), these become part of the application state,
> hopefully together with the provenance of that tossed document.

On Sat, May 22, 2021 at 02:44:32PM +0200, Klaus Hartke wrote:
> Additionally, you probably also need to configure some certificate/PSK
> and the intents/wills of the stakeholders/principals involved. Maybe
> some of that needs to be set directly, maybe some could be discovered
> through a layer of indirection. Is there something we could
> standardize here?

Sure, the link relation is part of the document (or its context), but
anything more should be as-necessary.

I'd like to reach a point where you *can* add some information about the
link (or the target?), but that'd be optional add-in because wherever it
makes sense there are good defaults.

These configurations may be separate even: Setting the address(es) of
the light switches may be done by a different entity (say, an RD
through which things are discovered) than setting the requirement that
switching commands must carry this or that authorization.

>       'coreapps.org:problem-details'

These are all good things to express. Most of these are all hint-level
-- it's good to have all these in advance (saving long back-and-forths),
but things should just as well work out if not (in the order as above,
not in the order in which it would fail):

* Trying to register anything outside of YetAnotherEcosystem would err
  with an understandable problem detail of "sorry wrong dictionary, use
  YetAnotherEcosystem"
* Accessing the RD without EDHOC-initiated OSCORE would be Unauthorized
  and contain a hint as to the EDHOC resource.
* Failure to use an ACE token (we don't have anything ACE+EDHOC yet, do
  we?) would result in 4.01 with an application/ace+cbor payload (which
  AFAIR can indicate the AS and necessary claims)
* The CoRAL vocabularies should be indicated in the message in some way
  (like content-formats are; if you request without Accept and get
  something you don't understand, better request again).

Of those that are not, I'm not sure they're best expressed here:

* the "better only register your public resources" could be grouped with
  "register your resources" command
* "No SHA-1" sounds like something decided per device, or part of the
  pinned certificate (we don't do hashes anyway without indicating the
  hash function).

* Certificate pinning: If we don't mean example.org to mean "whoever has
  a good claim through DNSSec or PKI to example.org", maybe we shouldn't
  say example.org here, but use a named device identifier in the first
  place. (rdlink comes to mind, but so do all systems that influenced
  it, including Tor, IPFS and magnet URIs).

  Otherwise, what good is the URI in the first place? If it's only
  usable with metadata, we could just as well split it up into "contact
  the server resolved from example.org, require RPK this-and-that, use
  path "/rd" -- the URI alone has no value then any more, and I'm not
  ready to concede that point yet. (In particular, if any input vector
  of URIs can make conflicting requirements on their authentication
  properties, this defeats collaboration between components inside a
  system, as the URI is no usable cache key any more).

BR
c