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

[Carsten Bormann <[e-mail]>]

On Mar 5, 2019, at 13:47, Klaus Hartke <[e-mail]> wrote:
> 
> 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".

Right.

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

Sense-making is a complex function.
In most environment, we can’t forbid everything that doesn’t make sense.

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

Well, there is a statement in there: “If you want to discover information about kadse, it may be of interest that kefer hosts that resource over there.”  Without additional context, that may be nonsensical, but with an RT, it might point to any kind of resource that is of interest in conjunction with knowing about the current server.

E.g., a CoAP server could point to a data backup server (and, probably, hope that that one over there indeed backs up this server, but it doesn’t know!).

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

Then don’t do that.

> that need to be mitigated. In particular,
> links that “associate a link’s context with another resource cannot be
> trusted

This is a nice example of a misuse of the word “trust”.  How do you “trust a link”?
It is obvious that the device exhibiting this link wants you to know it, and (assuming some form of integrity, which is missing in the example), you can “trust that”, but that’s all you can trust.
Whether that has influence on what you do next depends on your authorization policies.

> since they are effectively assertions by a third party that
> could be incorrect or malicious.”

Right.  In CoAP we have much less of “automatically following” (we don’t even have redirects!).

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

I can’t parse this sentence.  Links associate “contexts” (bad name for the source of a link) to target resources.  Section 2.1 only helps you find out what the “context” is (and I agree, it exhibits some weirdness).

> What’s the security model of Link Format?

6690 pretty much punts to 5988 here.
And that already has above’s “then don’t do it”.
(And reminds people that you need integrity protection/authentication if you want to do something grave based on the information.)

> That is, what are the rules
> that client should follow for trusting links

Don’t “trust”, except in the sense of “this device wanted to give you that information”.
We don’t treat discovery information as signed claims, right?
But claims they are.

> 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

I think an even more interesting problem is that a link-format can contain coaps:// links without any indication on the kind of security that goes with that.  That is a discovery problem we haven’t solved very well yet.

Grüße, Carsten