Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT)

[Barry Leiba <[e-mail]>]

Ben, can you check version -26 and see how much of your ballot is
addressed there?

Christian, do you think you've addressed all of Ben's issues in -26?

Barry

On Tue, Nov 3, 2020 at 12:28 PM Christian Amsüss <[e-mail]> wrote:
>
> (This is one of the point-to-point follow-up mails on the RD -25
> reviews; for the preface, please see the preceding mail on "The various
> positions on draft-ietf-core-resource-directory-25" at
> <https://mailarchive.ietf.org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>).
>
> As DISCUSS:
>
> > I agree with Roman that the authorization model seems under-developed.
> > While I recognize that there is need for flexibility across various
> > deployments, I think that we should be providing a default model (and
> > procedures for it) that will apply in many cases, and let
> > deployments specify alternate models if needed.  This stuff is hard
> > enough to get right that we should have a secure option that people can
> > use if they don't need to have customized details.  (To be clear, I
> > agree with the change of focus from -24 to -25 on the properties that a
> > security policy needs to provide and/or consider, as that is
> > fundamentally the important thing.  I just want a fallback/default
> > option that "does something reasonable in most cases" in addition.
> > Doing that by reference to some other existing thing would be fine, if
> > such a thing exists.)
>
> response:
>
> There is no external policy we could reference, so a new section was created.
> The First-Come-First-Remembered policy implements one of the candidates that
> were considered for this role, and was picked because unlike its "endpoint name
> comes from the certificate" it is a mode which an implementation can use
> without any further configuration whatsoever.
>
> The related changes can be viewed in
> https://github.com/core-wg/resource-directory/issues/258.
>
> > In particular, the current text seems to rely on the authorization
> > model including:
> >
> > (1) the RD knowing how clients will be using it (and thus what
> > properties the RD needs to enforce), which in the general case cannot be
> > known (though for static networks it could be), yet I don't see any
> > discussion that indicates this as a prerequisite; and
> >
> > (2) the client either knowing out-of-band that an entity is authorized
> > to act as a RD or just blindly trusting any of the unauthenticated (*)
> > advertisement mechanisms.  (* Yes, there may be some protection in the
> > network on subscribing to the relevant multicast address, DNS-SD, etc.,
> > but the client cannot a priori know that such protections are in place.)
> >
> > Relatedly, the naming model and naming authority should have some
> > clearer discussion.  We do mention in Section 7 the possibility for a
> > weak naming model where the RD is responsible for enforcing uniqueness
> > of names but otherwise link attributes are the primary authorization
> > criteria (vs. a traditional scheme with a naming authority and naming
> > hierarchy), but with naming as a fundamental prerequisite of any
> > authentication/authorization scheme, I think clearer discussion of how a
> > naming model is to be selected (and, perhaps more importantly, that it
> > must be fixed as part of a given deployment) for a given network is
> > needed.
>
> respond:
>
> The responsibilities are the other way around. The RD does not need to know the
> clients' expectations, the clients may only expect things they know to be true
> of the RD.
>
> See GENERIC-WHOPICKSMODEL.
>
> > If I understand correctly, we have some codepoint squatting going on in
> > the examples (e.g., for resource types).
>
> response:
>
> The rt=temperature-c, rt=light-lux and if=sensor are used where endpoints
> mimick the examples of RFC6690; it is a point here to have things look just
> like in direct discovery.
>
> The if=core.a and if=core.p use values from the expired and partially abandoned
> core-interfaces -- given its future is unclear, they've been replaced by
> examples with tag URIs, as has the et=oic.d.sensor (a value that's registered,
> but not to for et but for rt) and rt="light"; rt=sensor was dropped as it was
> not essential to the example.
>
> The individual changes are listed in
> https://github.com/core-wg/resource-directory/pull/266.
>
> > We should talk about the security properties of the various RD discovery
> > mechanisms that are defined.
>
> response:
>
> A section was added in the security considerations on this topic (see
> https://github.com/core-wg/resource-directory/pull/275 for text
> changes). It does not go into the properties of each mechanism, as the host
> discovery steps are generally unprotected; instead, it emphasizes the
> importance of checking the RD's authorization for any security properties the
> client would expect. In the context of the server authorization topic (see
> OPEN-SERVER), it was added that if the authorization is conditional on the
> resources being advertised with a particular resource type, that authorization
> already needs to be checked during the discovery phase (details in
> https://github.com/core-wg/resource-directory/pull/306).
>
> As COMMENT:
>
> > My apologies for where these comments diverge off into rambling
> > incoherency, or where I'm misunderstanding something that's clearly laid
> > out; this document had the misfortune of being the last one I got to
> > this week.
> >
> > Section 1
> >
> >    [RFC6690] only describes how to discover resources from the web
> >    server that hosts them by querying "/.well-known/core".  In many
> >    constrained scenarios, direct discovery of resources is not practical
> >    due to sleeping nodes, disperse networks, or networks where multicast
> >    traffic is inefficient.  These problems can be solved by employing an
> >    entity called a Resource Directory (RD), which contains information
> >    about resources held on other servers, allowing lookups to be
> >    performed for those resources.
> >
> > nit(?): I'd consider specifying that the RD is "a trusted entity".
> > (Even when the resources themselves are authenticated, a hostile RD can
> > still deny existence of a given resource, so by choosing to use an RD
> > there is some level of trust involved.)
>
> response:
>
> Putting it in there as a trusted entity would give the reader a wrong
> impression of the general case. Any trust placed in the RD must be earned by a
> security policy backed by the RD's credentials.
>
> > Section 2
> >
> >    Resource Directory (RD)
> >       A web entity that stores information about web resources and
> >       implements the REST interfaces defined in this specification for
> >       discovery, for the creation, the maintenance and the removal of
> >       registrations, and for lookup of the registered resources.
> >
> > nit: the list structure is not parallel here.  Maybe "for discovery,
> > creation, maintenance, and removal of registrations, and for lookup of
> > the registered resources"?
>
> response:
>
> The intended structure that's linearized into the sadly untreeish structure of
> written language was
>
> * discovery
> * of registrations
>   - creation
>   - maintenance
>   - removal
> * lookup
>
> I think this is what the current text expresses, whereas the proposed one
> groups discovery with "of registrations", while it's more a top-level thing.
>
> >    Commissioning Tool
> >       Commissioning Tool (CT) is a device that assists during the
> >       installation of the network by assigning values to parameters,
> >       naming endpoints and groups, or adapting the installation to the
> >       needs of the applications.
> >
> > Is "the installation of the network" a one-time event?   (Might a CT be
> > involved when adding a new device to a network at a later time?)
>
> response:
>
> CTs can come back to help new devices into the network; the text has been
> clarified to that point in
> https://github.com/core-wg/resource-directory/pull/295.
>
> There are remaining questions about how long a network can operate autonomously
> while the CT is absent and can thus not refresh registrations, but those exceed
> the scope of the document. (Discussed at
> https://github.com/core-wg/resource-directory/issues/290).
>
> > Section 3.1
> >
> >    Information SHOULD only be stored in the RD if it can be obtained by
> >    querying the described device's /.well-known/core resource directly.
> >
> > When might that not be the case?
>
> response:
>
> The prime example here is with devices that don't even have a copy of what they
> might want to (but can't for resource constraints) express there; those use a
> CT to do their work.
>
> The second example I can come up with is when devices have complex
> confidentiality requirements on the links, but rely on the RD and thus publish
> data to an authorized RD of which they don't even know who precisely might be
> authorized to read them.
>
> > Section 3.2
> >
> >    The RD architecture is illustrated in Figure 1.  An RD is used as a
> >    repository of registrations describing resources hosted on other web
> >    servers, also called endpoints (EP).  An endpoint is a web server
> >    associated with a scheme, IP address and port.  A physical node may
> >
> > (side note) hmm, I feel like in the HTTP world an endpoint is more
> > likely to be associated with a DNS name than an IP address, in common
> > usage.  Also, we later go on to assert that the endpoint's name has
> > primacy and that the IP address/port can be ephemeral.
>
> response:
>
> This is leading the reader from the CoAP definition of endpoints to the
> endpoints as registrants as used in the RD.
>
> >    An endpoint uses specific interfaces to register, update and remove a
> >    registration.  It is also possible for an RD to fetch Web Links from
> >    endpoints and add their contents to its registrations.
> >
> >    At the first registration of an endpoint, a "registration resource"
> >    is created, the location of which is returned to the registering
> >    endpoint.  The registering endpoint uses this registration resource
> >    to manage the contents of registrations.
> >
> > Does the "RD fetches links unilaterally" case count as a "first
> > registration of an endpoint"?  I'm having a hard time seeing how these
> > two statements are consistent with each other, and a naive reading
> > admits the possibility that a given endpoint could be "locked out" of
> > the ability to manage the contents of its registrations.
>
> response:
>
> The act of the endpoint triggering the RD to fetch links from it is the
> creation. And the "locking out" is the correct reading -- a client that uses
> simple client has no way of managing the contents. If it were capable enough to
> do that, it'd go the regular registration route.
>
> > Section 4
> >
> >    REST clients (registrant-EPs and CTs during registration and
> >    maintenance, lookup clients, RD servers during simple registrations)
> >    MUST be prepared to receive any unsuccessful code and act upon it
> >    according to its definition, options and/or payload to the best of
> >    their capabilities, falling back to failing the operation if recovery
> >    is not possible.  In particular, they should retry the request upon
> >
> > "MUST be prepared [...] to the best of their abilities" seems
> > non-actionable.  The stuff after "In particular", on the other hand, is
> > actual concrete guidance that could be mandated using normative
> > language.
>
> response:
>
> Right; fixed in https://github.com/core-wg/resource-directory/pull/276.
>
> > Section 4.1
> >
> >    1.  In a 6LoWPAN, just assume the Border Router (6LBR) can act as an
> >        RD (using the ABRO option to find that [RFC6775]).  Confirmation
> >        can be obtained by sending a Unicast to "coap://[6LBR]/.well-
> >        known/core?rt=core.rd*".
> >
> > nit(?): I was unaware that "Unicast" was a proper noun.
>
> response:
>
> Addressed in https://github.com/core-wg/resource-directory/pull/277.
>
> > Section 4.3
> >
> >    "core.rd" in the query string.  Likewise, a Resource Type parameter
> >    value of "core.rd-lookup*" is used to discover the URIs for RD Lookup
> >    operations, core.rd* is used to discover all URI paths for RD
> >    operations.  [...]
> >
> > Is the distinction between URIs (for RD Lookup) and URI paths (for RD)
> > important here?
>
> response:
>
> No, it isn't. Fixed in https://github.com/core-wg/resource-directory/pull/277.
>
> >    While the link targets in this discovery step are often expressed in
> >    path-absolute form, this is not a requirement.  Clients of the RD
> >    SHOULD therefore accept URIs of all schemes they support, both as
> >    URIs and relative references, and not limit the set of discovered
> >    URIs to those hosted at the address used for URI discovery.
> >
> > I'm not sure I see how the "not limit [...] to those hosted at the
> > address used for URI discovery" follows from the non-requirement for
> > expression of the link-targets from discovery in path-absolute form.
> > (Given the ability to send the discovery query to a multicast address,
> > the guidance seems okay; it's just the "therefore" that is puzzling me.)
>
> response:
>
> If it was a requirement on the server, the clients could rely on it and thus
> implicitly limit the set by failing to parse the full URIs.
>
> (It could say "explicitly or implicitly limit", but only the "implicitly
> limit" case justifies the "therefore".)
>
> >    It would typically be stored in an implementation information link
> >    (as described in [I-D.bormann-t2trg-rel-impl]):
> >
> >    Req: GET /.well-known/core?rel=impl-info
> >
> > This seems to be depicting a link-relation type that is not registered
> > at https://www.iana.org/assignments/link-relations/link-relations.xhtml
> > , i.e., codepoint squatting.  Please put in a stronger disclaimer that
> > this is an example link relation type, not just an example exchange.
>
> response:
>
> A note has been added that the type is just proposed in a WIP document (in
> https://github.com/core-wg/resource-directory/pull/278).
>
> > Section 5
> >
> > These first few paragraphs give the impression that this is
> > first-come-first-served with minimal authentication or authorization
> > checking.  Mentioning that there are authorization checks, with a
> > forward-reference, might be helpful.
>
> response:
>
> It's more a last-come-longest-remembered, but even the most minimal security
> policies would ensure that the registration resources belong to the "same"
> device (for whatever the policy defines as same).
>
> Clarified in https://github.com/core-wg/resource-directory/pull/292.
>
> >    further parameters (see Section 9.3).  The RD then creates a new
> >    registration resource in the RD and returns its location.  The
> >
> > Is this returned "registration resource" expected to function as a
> > "capability URL" (https://www.w3.org/TR/capability-urls/) that would
> > need to contain an appropriate amount of entropy to be reasonably
> > unguessable by parties other than the registrant-ep/CT responsible for
> > it?
>
> response:
>
> No, it is not a capability URL -- it will be discoverable through the endpoint
> lookup interface.
>
> Note that around ACE, bearer tokens (which capability URLs are) are generally
> discouraged in favor of proof-of-possession tokens.
>
> >    The registration request interface is specified as follows:
> >
> >    Interaction:  EP -> RD
> >
> > I thought that the CT could be a requestor as well as the EP.
>
> response:
>
> Yes it can be. The expression in the interaction tables is an artifact of the
> CTs being a not-even-special case of EPs, but as we have both of them in the
> rest of the text, so do we now in those lists. (Changes in
> https://github.com/core-wg/resource-directory/pull/309).
>
> >          well.  The endpoint name and sector name are not set when one
> >          or both are set in an accompanying authorization token.
> >
> > What should the RD do if they are set but also present in the
> > accompanying authorization token?
>
> response:
>
> The wording has been updated in
> https://github.com/core-wg/resource-directory/pull/273; it now (by
> construction, but also explicitly) explains conflict handling.
>
> >    Req: POST coap://rd.example.com/rd?ep=node1
> >    Content-Format: 40
> >    Payload:
> >    </sensors/temp>;ct=41;rt="temperature-c";if="sensor",
> >
> > (side note) XML for the sensors, not SenML?  With Carsten as an author,
> > even? ;)
>
> response:
>
> This is clearly a mistake, and got removed in an emergency update in
> https://github.com/core-wg/resource-directory/pull/279.
>
> More seriously, though, these examples are from RFC6690 (which does not have
> ct= entries for reasons of chronology), and keeping them aligned is a good
> thing.
>
> >    An RD may optionally support HTTP.  Here is an example of almost the
> >    same registration operation above, when done using HTTP.
> >
> >    Req:
> >    POST /rd?ep=node1&base=http://[2001:db8:1::1] HTTP/1.1
> >    Host: example.com
> >
> > Wouldn't "Host: rd.example.com" be closer to "almost the same
> > registration"?
>
> response:
>
> Fixed in https://github.com/core-wg/resource-directory/pull/277.
>
> (I had brief qualms about introducing a protocol-negotiation situation here,
> but performing "almost the same registration" over two protocols already
> necessarily does that).
>
> > Section 5.1
> >
> > I'm a little uneasy about specifying new behavior for POST to the
> > existin /.well-known/core that was defined by RFC 6690 for other uses.
> > What factors go into using the same well-known URI vs. defining a new
> > one for this usage?
>
> response:
>
> It-always-having-been-that-way, primarily. As no large deployments are known,
> this is fixed in https://github.com/core-wg/resource-directory/pull/259
> by switching to a standalone /.well-known/rd.
>
> >    The sequence of fetching the registration content before sending a
> >    successful response was chosen to make responses reliable, and the
> >    caching item was chosen to still allow very constrained registrants.
> >
> > I'm not sure what "the caching item" is supposed to be (if it's not a
> > typo/misordering of words).
>
> response:
>
> Now phrased as "the point about caching" (in
> https://github.com/core-wg/resource-directory/pull/277) which should
> be easier to read. A few lines up we recommend that the RD caches the .wk/c,
> and this provides the rationale.
>
> > Section 5.3
> >
> >    queries concerning this endpoint.  The RD SHOULD continue to provide
> >    access to the Registration Resource after a registration time-out
> >    occurs in order to enable the registering endpoint to eventually
> >    refresh the registration.  The RD MAY eventually remove the
> >    registration resource for the purpose of garbage collection.  If the
> >    Registration Resource is removed, the corresponding endpoint will
> >    need to be re-registered.
> >
> > (This MAY is actually a MUST for the simple registration case, per §5.1,
> > right?)
>
> response:
>
> No, it's a choice there as well. One server may keep them around forever, and
> when the simple client comes back it'll show with the same registration
> resource in the resource lookup. Another server may GC it and assign a
> different registration resource when it returns.
>
> > Section 5.3.1
> >
> >    An update MAY update the lifetime or the base URI registration
> >    parameters "lt", "base" as in Section 5.  Parameters that are not
> >
> > What about the "extra-attrs"; are they inherently forbidden from
> > updates?
>
> response:
>
> The introduction paragraph was overly specific and fixed in
> https://github.com/core-wg/resource-directory/pull/294.
>
> >                             base :=  Base URI (optional).  This
> >          parameter updates the Base URI established in the original
> >          registration to a new value.  If the parameter is set in an
> >          update, it is stored by the RD as the new Base URI under which
> >          to interpret the relative links present in the payload of the
> >          original registration, following the same restrictions as in
> >          the registration.  If the parameter is not set in the request
> >
> > nit: is it the interpretation of relative links that is following the
> > same restrictions as in the registration, or the new value of the
> > parameter being supplied in the update?
>
> response:
>
> The restrictions apply to the new value, and were moved up there in
> https://github.com/core-wg/resource-directory/pull/294.
>
> >    The following example shows how the registering endpoint updates its
> >    registration resource at an RD using this interface with the example
> >    location value: /rd/4521.
> >
> > The path component "4521" contains a worryingly small amount of
> > unpredictableness; I would prefer examples that used longer random
> > locations, as for capability URLs.  (Throughout the document, of
> > course.)  See also draft-gont-numeric-ids-sec-considerations, that I'm
> > AD sponsoring, though I do not see any clear issues on first glance.
>
> response:
>
> See comment on the original capability URL question -- they are not.
>
> > (Also, it might be worth another sentence that this update is serving
> > just to reset the lifetime, making no other changes, since this might be
> > expected to be a common usage.)
>
> response:
>
> Stating purpose rather than mechanism now (since
> https://github.com/core-wg/resource-directory/pull/294).
>
> > Section 6
> >
> > With "Resource Lookup" and "Endpoint Lookup" as (apparent) top-level
> > siblings, would it make sense to put 6.2, or at least 6.3, as
> > subsections under 6.1?
>
> response:
>
> It would from a hierarchical table-of-contents point of view, but given the
> focus of lookup is on resource lookup, the existing sequence captures the
> narrative of "With an RD, you can look up resources, here is how you use it,
> here is what it looks like, and by the way if you really need it you can even
> look at the registrations themselves".
>
> > Section 6.1
> >
> >    Resource lookup results in links that are semantically equivalent to
> >    the links submitted to the RD.  The links and link parameters
> >    returned by the lookup are equal to the submitted ones, except that
> >    the target and anchor references are fully resolved.
> >
> > Are the "submitted ones" the submissions at registration time, or during
> > the lookup query itself?  (I assume registration-time, but being
> > explicit costs little.)
>
> response:
>
> Some words added for clarity in
> https://github.com/core-wg/resource-directory/pull/294.
>
> >    If the base URI of a registration contains a link-local address, the
> >    RD MUST NOT show its links unless the lookup was made from the same
> >    link.  The RD MUST NOT include zone identifiers in the resolved URIs.
> >
> > Same link as what?
>
> response:
>
> The link the endpoint sits on; clarified in
> https://github.com/core-wg/resource-directory/pull/294.
>
> > Section 6.2
> >
> >    The page and count parameters are used to obtain lookup results in
> >    specified increments using pagination, where count specifies how many
> >
> > (We haven't introduced the page and count parameters yet.)
>
> response:
>
> Wording has been enhanced in
> https://github.com/core-wg/resource-directory/pull/294.
>
> >    operator as in Section 4.1 of [RFC6690].  Attributes that are defined
> >    as "link-type" match if the search value matches any of their values
> >
> > Where is it specified how an attribute might be "defined as
> > 'link-type'"?  This is the only instance of the string "link-type" in
> > this document, and it does not appear in RFC 6690 at all...
>
> response:
>
> That should have said "relation-types"; it does now, and also refers to
> the 6690 ABNF (since
> https://github.com/core-wg/resource-directory/pull/294.
>
> >    references) and are matched against a resolved link target.  Queries
> >    for endpoints SHOULD be expressed in path-absolute form if possible
> >    and MUST be expressed in URI form otherwise; the RD SHOULD recognize
> >    either.  The "anchor" attribute is usable for resource lookups, and,
> >    if queried, MUST be for in URI form as well.
> >
> > I don't see how it can be only a SHOULD to recognize either given these
> > generation criteria.
>
> response:
>
> If the URI is on a different scheme/host, I assert things are clear. (Just to
> ensure I didn't get your point wrong.)
>
> Otherwise, in practice there can happen mistakes where server and client
> disagree about the default values of the Uri-Scheme, Uri-Host and Uri-Port
> options -- as anyone who's ever tried to set up an HTTP reverse proxy for a
> WebDAV server can attest to. We're trying to avoid creating these situations,
> but when they do happen. We don't automatically declare the offending party
> broken by putting a MUST here, but encourage the peer to assist it. The client
> can help by providing the relative reference (for then, disagreement passses
> unnoticed), and the server by recognizing the full URI (for the client may have
> obtained it and not know that it'd match what the server thinks is its Uri-Host
> name).
>
> (The "and MUST be expressed in URI form otherwise" sounds like a factual
> necessity, but it is here to rule out the corner case of a client handing out
> //hostname/path style references).
>
> > Section 6.3
> >
> >    The following example shows a client performing a lookup of all
> >    resources of all endpoints of a given endpoint type.  It assumes that
> >    two endpoints (with endpoint names "sensor1" and "sensor2") have
> >    previously registered with their respective addresses
> >    "coap://sensor1.example.com" and "coap://sensor2.example.com", and
> >    posted the very payload of the 6th request of section 5 of [RFC6690].
> >
> > Er, the 6th request is a GET; do we mean to say the response to the 6th
> > request?
>
> response:
>
> Yes. Fixed in https://github.com/core-wg/resource-directory/pull/294.
>
> > Section 6.4
> >
> >    The endpoint lookup returns registration resources which can only be
> >    manipulated by the registering endpoint.
> >
> > This seems to leave it unclear whether the endpoint lookup is expected
> > to return resources that the requestor will not have permission to
> > manipulate (in addition to those it does have permission for).
>
> response:
>
> Clarified in https://github.com/core-wg/resource-directory/pull/294.
>
> >    While Endpoint Lookup does expose the registration resources, the RD
> >    does not need to make them accessible to clients.  Clients SHOULD NOT
> >    attempt to dereference or manipulate them.
> >
> > But why expose them at all if they're not going to be accessible?
>
> response:
>
> They serve as identifiers (think URI rather than URL), and may additionally be
> used in implementation defined operations on the resource that could be allowed
> for administrators. Last but not least, link-format (unlike the upcoming CoRAL)
> does not have means of talking about something without naming it.
>
> (I do see the point, and if we started RD anew with the benefit of having
> CoRAL, chances are this would look a bit different, and the names would not be
> exposed to just any lookup client).
>
> The WG discussion of this did, however, lead to a point added to the security
> considerations about the RD's choice of what to put in there (change in
> https://github.com/core-wg/resource-directory/pull/267).
>
> >    An RD can report endpoints in lookup that are not hosted at the same
> >    address.  [...]
> >
> > The "same address" as what?
>
> response:
>
> Sharpened in https://github.com/core-wg/resource-directory/pull/294.
>
> > Section 7.1
> >
> >    Whenever an RD needs to provide trustworthy results to clients doing
> >    endpoint lookup, or resource lookup with filtering on the endpoint
> >
> > How will the RD know whether the client is expecting trustworthy
> > results?  (When would a client *not* expect trustworthy results?)
>
> response:
>
> It won't per-client, it is configured for one. See GENERIC-WHOPICKSMODEL.
>
> >    name, the RD must ensure that the registrant is authorized to use the
> >    given endpoint name.  This applies both to registration and later to
> >    operations on the registration resource.  It is immaterial there
> >    whether the client is the registrant-ep itself or a CT is doing the
> >    registration: The RD can not tell the difference, and CTs may use
> >
> > I suppose there might be plausible authorization models where a
> > return-routability check to a given address constitutes authorization to
> > use that address as an endpoint name, in which case the RD can tell the
> > difference between a registrant-ep and a CT attempting to act on its
> > behalf.
>
> WGF-6
> response:
>
> The RD might do such checks, but then again the EP might just be using
> different network interfaces simultaneously. At that point where the EP uses a
> different (and usually dormant) network interface for registration, the line
> between EP and the CT gets blurry; we tolerate that blurriness because the
> distinction is not so much a technical one (the REST server does not care
> whether the request originates at its network peer, is proxied through there or
> sent from there on behalf of someone completely different) as long as the
> credentials are good.
>
> Frankly, I'm personally not too happy with distinguishing CTs in the first
> place; it is more reflective of what I understand to be an industry practice
> than a distinction in this CoAP application.
>
> >    When certificates are used as authorization credentials, the
> >    sector(s) and endpoint name(s) can be transported in the subject.  In
> >    an ACE context, those are typically transported in a scope claim.
> >
> > As Russ noted in the Gen-ART review, "transported in the subject" is
> > sufficiently vague to not really be actionable.  It might be better to
> > say that the holder of the private key corresponding to the public key
> > certified in the certificate is generally considered authorized to act
> > on behalf of any identities (including endpoint names) contained in the
> > certificate's subject name.
>
> response:
>
> See GENERIC-SUBJECT.
>
> > Section 7.1.1
> >
> >    Conversely, in applications where the RD does not check the endpoint
> >    name, the authorized registering endpoint can generate a random
> >    number (or string) that identifies the endpoint.  The RD should then
> >
> > How much entropy/randomness in the random name?  Does a CSPRNG need to
> > be used?  (I do see the follow-up about doubling the length in case of
> > failure or starting with a UUID if that's not possible, but some
> > guidance on where to start still seems appropriate.)
>
> respond:
>
> There is no requirement here as collisions only result in retries.
>
> For those cases where the client implementer thinks they can get away with not
> implementing retry, UUID URNs are pointed to, which themselves cover the topic.
>
> > Section 7.2
> >
> >    When lookup clients expect that certain types of links can only
> >    originate from certain endpoints, then the RD needs to apply
> >    filtering to the links an endpoint may register.
> >
> > As before, how will the RD know what behavior clients are relying on?
>
> response:
>
> It will not. It may, however, advertise it explicitly. If, for example, an
> application like LwM2M always ensures trusted endpoint names, the RD may
> advertise as rt="core.rd-lokup-ep example.lwm2m", and then clients that trust
> that metadatum (which they'll want to verify from some claim) know they can
> trust the RD to have checked ep names.
>
> See also GENERIC-WHOPICKSMODEL
>
> >    An RD may also require that only links are registered on whose anchor
> >    (or even target) the RD recognizes as authoritative of.  One way to
> >
> > I don't think I can parse this sentence (especially "the RD recognizes
> > as authoritative of").
>
> response:
>
> Rephrased to "require that links are only registered if the registrant is
> authorized to publish information about the anchor [...] of the link." in
> https://github.com/core-wg/resource-directory/pull/294.
>
> > Section 8
> >
> > In contexts where we discuss DTLS and TLS as being generally comparable,
> > we typically will state that DTLS replay protection is required in order
> > to provide equivalent levels of protection.
>
> response:
>
> This item rippled quite a bit beyond the original response of "Huh? CoAP
> doesn't already do this? Well, here we need it".
>
> As things stand, requiring replay protection make it harder to exploit the
> issue described at OPEN-REPLAY-FRESHNESS, but once that is addressed for good,
> replay protection should not be necessary any more for the RD, as all its
> operations are becoming long-term idempotent.
>
> > We might also want to reiterate or refer back to the previous discussion
> > of the potential for attributes or resource/endpoint names, link
> > relations, etc. that may need to be confidential, the relevant access
> > control/filtering, and the avenues by which disclosure of resource names
> > can occur even when access to those resources will not be permitted.  (I
> > think some of this overlaps with 8288 and 6690, but don't mind repeating
> > it.)
>
> response:
>
> There is a pointer back saying that the necessary access control depends on the
> protection objectives set in the policies (since
> https://github.com/core-wg/resource-directory/pull/250).
>
> > Section 8.1
> >
> > It's probably worth reiterating that all name comparisons must be done
> > at sector scope (since failing to do so can lead to attacks).
>
> response:
>
> It is; fixed since https://github.com/core-wg/resource-directory/pull/296.
>
> >    Endpoint authentication needs to be checked independently of whether
> >    there are configured requirements on the credentials for a given
> >    endpoint name (Section 7.1) or whether arbitrary names are accepted
> >    (Section 7.1.1).
> >
> > I think this is more properly authorization than authentication.
>
> response:
>
> Yes; fixed in https://github.com/core-wg/resource-directory/pull/271.
>
> > Section 8.3
> >
> >    attacks.  There is also a danger that NTP Servers could become
> >    implicated in denial-of-service (DoS) attacks since they run on
> >    unprotected UDP, there is no return routability check, and they can
> >    have a large amplification factor.  The responses from the NTP server
> >    were found to be 19 times larger than the request.  An RD which
> >
> > (It's not clear to me why the specific discussion of NTP numbers is
> > relevant here, since RD is not NTP.)
>
> response:
>
> The section has been shortened in
> https://github.com/core-wg/resource-directory/pull/249.
>
> > Section 9.3
> >
> > Should we also include "rt" in the initial entries?  I see it is used as
> > a query parameter for resource lookup in the examples in Section 6.3.
>
> response:
>
> It's used as is any other link attribute. There's no registry for them, and
> while there's been talk over ond over that it would be nice, I don't think
> there will be any until linkformat-CoRAL conversion is defined (and even then
> it may not be comprehensive). Selectively picking some distinguished common
> link attributes into this registry won't make things less messy.
>
> The prime line of defense against this getting messy is the expert guidance
> that for some types of parameters their short names should be checked against
> "commonly used target attributes".
>
>
> >    *  indication of whether it can be passed as a query parameter at
> >       registration of endpoints, as a query parameter in lookups, or be
> >       expressed as a target attribute,
> >
> > (Since this text does not clarify about lookup of endpoints vs.
> > resources...
> >
> >    Review" as described in [RFC8126].  The evaluation should consider
> >    formal criteria, duplication of functionality (Is the new entry
> >    redundant with an existing one?), topical suitability (E.g. is the
> >    described property actually a property of the endpoint and not a
> >    property of a particular resource, in which case it should go into
> >    the payload of the registration and need not be registered?), and the
> >
> > ... and this text suggests that query parameters for *resource* lookups
> > need not be registered.)
> >
> >    potential for conflict with commonly used target attributes (For
> >    example, "if" could be used as a parameter for conditional
> >    registration if it were not to be used in lookup or attributes, but
> >    would make a bad parameter for lookup, because a resource lookup with
> >    an "if" query parameter could ambiguously filter by the registered
> >    endpoint property or the [RFC6690] target attribute).
> >
> > Then why do we use it as an example of lookup filtering in Section 6.2?
>
> response:
>
> The text suggests that target attributes for registered resources need not be
> registered. These unregistered wild-west attribute names can be used both with
> resource lookups (matching only resources which), and in endpoint lookups
> (matching endpoints that contain any resource which).
>
> If `if` were to be put in for use in an RD parameter used with lookup, that
> would not per se create ambiguous queries (the rules would still say "matches
> either"), but the results would be prone to causing confusion.
>
> > Section 10.1.2
> >
> > Should we really be using unregistered resource types (i.e., codepoint
> > squatting) in the examples?
>
> response:
>
> Addressed together with the earlier code squatting comments in
> https://github.com/core-wg/resource-directory/pull/266.
>
> >    After the filling of the RD by the CT, the application in the
> >    luminaries can learn to which groups they belong, and enable their
> >    interface for the multicast address.
> >
> > Just to check: the luminaries are learning their own group membership by
> > querying the resource directory?
>
> response:
>
> Not directly. They (in this very particular example that seems to be based on
> industry process but which I'd not necessarily recommend for imitation) use a
> heuristic to find any multicast URI they might possibly provide, and join that
> group.
>
> > Section 10.2.2
> >
> > Please expand MSISDN.
>
> response:
>
> Taking a step back from this and other comments led to a drastical shortening
> of the example.
>
> See also GENERIC-ODDEXAMPLES
>
> > Section 13.2
> >
> > I think RFC 7252 should probably be normative.
> >
> > Likewise for RFC 8288 ("the query parameter MUST be [...] a token as
> > used in [RFC8288]").
>
> response:
>
> RFC7252 (CoAP) and RFC7230 (HTTP) were promoted to a normative reference.
> (RFC7641 (CoAP observe) wasc left as informative because while they are
> optional components, RD is not so much specified using them but more happens to
> combine with them).
>
> RFC8288 was also promoted, but not due to the quoted line (that's not
> implementation relevant but merely setting out rules for the registry
> operation), but because we explicitly pull it in in terminology and the
> information model.
>
> (Changes in https://github.com/core-wg/resource-directory/pull/307).