[core] Trusting links in .well-known/core

[Klaus Hartke <[e-mail]>]

RFC 6690 defines "CoRE Resource Discovery" as "discovery of resources
hosted by a constrained web server" [1]. The RFC then proceeds to
specify that "resource discovery in CoRE is accomplished through the
use of a well-known resource URI that returns a list of links about
resources hosted by that server" [2].

Let's say a client requests a representation of .well-known/core from
server 'kadse.example' and gets a link to a resource on
'kefer.example':

=>
   GET coap://kadse.example/.well-known/core

<=
   2.05 Content
   Content-Format: application/link-format

   <coap://kefer.example/42/>

Because of Section 2.1 of RFC 6690 [3], the context of this link is
<coap://kefer.example/>. So it's a link from <coap://kefer.example/>
to <coap://kefer.example/42/> with link relation type "hosts".

In other words, the client says it wants to discover the resources
hosted by (coap, kadse.example, 5683) and (coap, kadse.example, 5683)
says that there is a resource hosted by (coap, kefer.example, 5683)
named <coap://kefer.example/42/>. That doesn't seen to make a lot of
sense.

Are such links currently allowed? If yes, should they be forbidden?

Furthermore: RFC 8288, on which RFC 6690 is based, notes that there
are "attack vectors opened by automatically following, trusting, or
otherwise using links" [4] that need to be mitigated. In particular,
links that "associate a link's context with another resource cannot be
trusted since they are effectively assertions by a third party that
could be incorrect or malicious."

Because of Section 2.1 of RFC 6690 [3], essentially *every* link in a
Link Format representation associates the link's context with another
resource.

What's the security model of Link Format? That is, what are the rules
that client should follow for trusting links in .well-known/core
representations in Link Format?

Klaus

[1] https://tools.ietf.org/html/rfc6690#section-1
[2] https://tools.ietf.org/html/rfc6690#section-4
[3] https://tools.ietf.org/html/rfc6690#section-2.1
[4] https://tools.ietf.org/html/rfc8288#section-5