Things it takes to send a CoAP request

[chrysn]

This is a bit wobbly still, but IMO something we should clarify better:

What are the pieces that go into dereferencing a CoAP URI, especially when OSCORE is involved (which unlike DTLS does not bring its own scheme)?

It's tempting to claim that OSCORE makes this special, but even dereferencing a coaps URI needs a piece of policy: "How is the stack supposed to know whom to trust and which credentials to present?" In a web-browser-style deployment, the implied policy is "whoever presents a valid certificate for that name from the root CA", but different uses of CoAP exist, eg. on LwM2M where AIU there is a coaps URI with an IP literal of the bootstrap server, and next to it a certificate (or RPK) that needs to present.

And then there is the choice of whether or not a proxy should be taken. This can be a simple no/yes-and-which choice (as is offered by browsers), but can also become more complex when URIs are not DNS based (eg. with 6tisch.arpa, "where is my Tor entry point so I can resolve .onion addresses?").

All those are decisions that a CoAP stack probably may in good conscience claim to just solve automatically, but others may offer those as choices (and some applications need the choices). Right now there is no place that explains that there are choices in the first place.

The documentation of RIOT-rs has a current PR with some text on that matter (that is biased towards RIOT-rs's choices, but might provide some starting point); discussion around that PR triggered the creation of this issue.

[chrysn]

A question that has come up now twice is that of how these are needed or not needed in HTTP:

• The URI is required in HTTP just as in CoAP.
• In HTTP, there are also choices:
  • Should a proxy be used? If so, are there proxy-exempt addresses?
  • Should the system's name resolution service be used, or should DoH be used?
  • Is a browser plugin available that intercepts requests to .onion and redirects them into a different transport? (Optionally, this is implemented in a proxy that makes the decision internally and presents as a single proxy towards the browser)
    Outside of the browser, splitting between the host name and the next hop destination is possible in a more fine grained way, eg. using curl's --connect-to and --resolve options.
• The security policy in the browser is usually fixed: "Accept everything that has an X509 certificate chain down to one of these root certificates" -- augmented with a list of system installed authorities (which the browser may or may not respect) and explicit exceptions ("for wrong.host.badssl.com:443, accept a certificate with fingerprint fa:a1:63:..."), which are usually created interactively on demand, and pinnings managed through HSTS.
  This default policy is now also active in most command line tools, but can be overridden by giving an explicit CA or an explicit certificate.
  [edit, added:] Clients authenticating with client certificates is rarely used in browsers (mostly, clients are identified using cookies acting as short-lived bearer tokens, which comes with its own set of complexities). When client certificates are used, a GUI popup presents the user with a runtime choice.

There are extra reasons in CoAP to use them, for example:

• Carrying 216KiB (du -schL --apparent-size /etc/ssl/certs/*.pem) of CA certificates is not what a typical IoT device can do, and the trust model is typically a different one anyway (one can use CWTs for authentication, while https://datatracker.ietf.org/doc/draft-tschofenig-tls-cwt/ is not even there for TLS let alone HTTPS let alone browsers).
• CoAP can be used with a lot more auto-discovery than HTTP, enabling uses such as CoJP (6tisch.arpa) or using a peer that just established a connection to the device to relay requests to.

But all these choices are there in HTTP just as well, and as with HTTP, a system-wide policy is quite a sensible option -- but still just an option.