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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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:
----------------------------------------------------------------------

There appear to be a few areas of straightforward, under-specified elements of
the authorization model.

-- How does the RD know that a node claiming to be a CT is in fact a CT and is
permitted to register on behalf of end-points?  It seems like there is a
missing, simple statement to make that this is configured out of band with the
RD?  Or is that carrier somehow in a authentication credentials?

-- Is there are reason why there is not normative guidance requiring the RD to
check whether authentication clients are authorized to register particular
resources?  Section 7.1 covers the issue, but all of Section 7.* is explicitly
noted as informative.  Section 8.1. says “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)” but this text seems to frame it as authentication
issue.  Section 8.2 seems to stress only the distinction between the
registration and lookup API.

-- Section 8.1.  Per “If the server does not check whether the identifier
provided in the DTLS handshake matches the identifier used at the CoAP layer
then it may be inclined to use the endpoint name for looking up what
information to provision to the malicious device.”, this is good advice.  If
DTLS PSK and RPK are used, what identifiers does the RD have to check to ensure
the DTLS and CoAP layers match?  Per 9.1.3.1. (for PSK) and 9.1.3.2.1 (for RPK)
of RFC7252 there is the notion of identifiers for DTLS but those don’t manifest
in CoAP?  Additionally, when DTLS with a certificate is used, is it intended to
compare the subjectAltName with the authority in the Registration Base URI
(i.e., which exact certificate fields should it compare with the CoAP)?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 3.5.  Per “When endpoints are not connected … a remote server is
usually used to provide proxy access to the endpoints”, this architecture
wasn’t entirely clear to me.  How can a proxy provide access to an endpoint
that isn’t connected?  Or is proxy meant as a substitute here or an
intermediary?

** Section 3.6.  The home and building automation use case doesn’t make any
reference to the RD architecture (like the other two use cases).

** Section 4.0.  Per “… falling back to failing the operations if recovery is
not possible”, can “failing the operation” be clarified?

** Per Section 4.0.  Per “An RD MAY make the information submitted to it
available to further directories”, are there circumstances where end points
would not want that?

** Section 4.1.  Per “2. In a network that supports multicast well, …”, what
does it mean to “support multicast _well_”?

** Section 5.  Per the ep definition of the URI Template Variables, what does
it mean for the an endpoint to be “(mostly mandatory)?

** Section 7.1.  Per “When certificates are used as authorization credentials,
the sector(s) and endpoint name(s) can be transported in the subject”,
recommend being more precise on what exact X.509 field(s) you mean when saying
“subject”.

** Section 7.1.1. Per “Registrants that are prepared to pick a different
identifier when their initial attempt at registration is unauthorized should
pick an identifier at least twice as long as the expected number of
registrants”, how would a registrant know the population size?

** Section 7.2.  Per “To avoid the limitations, RD applications should consider
prescribe that lookup clients only use the discovered information as hints, and
describe which pieces of information need to be verified with the server”, I
wasn’t sure which verification this would be.

** Section 7.3.  This section cautions about the differences between the
registrant publishes itself vs. what is in the RD.  It might be worth
reiterating that the RD may also publish what it knows to others per Section
4.0’s “An RD MAY make the information submitted to it available to further
directories”

** Editorial Nits
-- Global.  s/can not/cannot/g

-- Section 4.  Editorial.  Per “Only multicast discovery operations are not
possible on HTTP, and Simple Registration can not be executed as base attribute
… can not be used there”, this sentence didn’t parse.