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

From: Barry Leiba <[email-masked]>
Date: Fri, 2 Oct 2020 20:18:20 -0400

Authors and WGCs,
We have four DISCUSS ballots on this and a number of other IESG comments,
and I haven’t seen responses to the ADs.  When can we get some engagement
on these issues?

Barry

On Thu, Aug 13, 2020 at 4:12 AM Benjamin Kaduk via Datatracker <
[email-masked]> wrote:

> Benjamin Kaduk has entered the following ballot position for
>
> draft-ietf-core-resource-directory-25: Discuss
>
>
>
> When responding, please keep the subject line intact and reply to all
>
> email addresses included in the To and CC lines. (Feel free to cut this
>
> introductory paragraph, however.)
>
>
>
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>
>
> The document, along with other ballot positions, can be found here:
>
> https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
>
> 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.)
>
>
>
> 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.
>
>
>
> If I understand correctly, we have some codepoint squatting going on in
>
> the examples (e.g., for resource types).
>
>
>
> We should talk about the security properties of the various RD discovery
>
> mechanisms that are defined.
>
>
>
>
>
> ----------------------------------------------------------------------
>
> 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.)
>
>
>
> 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"?
>
>
>
>    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?)
>
>
>
> 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?
>
>
>
> 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.
>
>
>
>    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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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?
>
>
>
>    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.)
>
>
>
>    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.
>
>
>
> 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.
>
>
>
>    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?
>
>
>
>    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.
>
>
>
>          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?
>
>
>
>    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? ;)
>
>
>
>    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"?
>
>
>
> 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?
>
>
>
>    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).
>
>
>
> 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?)
>
>
>
> 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?
>
>
>
>                             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?
>
>
>
>    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.
>
>
>
> (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.)
>
>
>
> 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?
>
>
>
> 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.)
>
>
>
>    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?
>
>
>
> 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.)
>
>
>
>    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...
>
>
>
>    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.
>
>
>
> 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?
>
>
>
> 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).
>
>
>
>    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?
>
>
>
>    An RD can report endpoints in lookup that are not hosted at the same
>
>    address.  [...]
>
>
>
> The "same address" as what?
>
>
>
> 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?)
>
>
>
>    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.
>
>
>
>    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.
>
>
>
> 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.)
>
>
>
> 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?
>
>
>
>    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").
>
>
>
> 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.
>
>
>
> 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.)
>
>
>
> 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).
>
>
>
>    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.
>
>
>
> 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.)
>
>
>
> 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.
>
>
>
>    *  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?
>
>
>
> Section 10.1.2
>
>
>
> Should we really be using unregistered resource types (i.e., codepoint
>
> squatting) in the examples?
>
>
>
>    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?
>
>
>
> Section 10.2.2
>
>
>
> Please expand MSISDN.
>
>
>
> 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]").
>
>
>
>
>
>
>
>

---

From: Christian M. Amsüss <[email-masked]>
Date: Sat, 3 Oct 2020 11:24:31 +0200

Hello Barry,

> and I haven’t seen responses to the ADs.  When can we get some engagement

we've come to rough agreement on how to respond to the harder points on
an interim meeting, and will go through the worked-out version for the
next document revision on the next one (scheduled for 2020-10-08). I
expect to submit an updated version together with point-to-point
responses on the weekend following that.

Best regards
Christian

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