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

[Roman Danyliw <[e-mail]>]

Hi Christian!

Thanks for these pull requests (now in -26) and the additional explanations below.  They addressed my DISCUSS and COMMENT feedback.  I will clear my ballot.

Regards,
Roman

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Christian Amsüss
> Sent: Tuesday, November 3, 2020 12:25 PM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; The IESG <[e-mail]>; [e-mail]
> Subject: Re: [core] Roman Danyliw's Discuss on draft-ietf-core-resource-
> directory-25: (with DISCUSS and COMMENT)
> 
> (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:
> 
> > 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?
> 
> response:
> 
> The RD does not distinguish between endpoints and CTs; both are just CoAP
> clients that have to present suitable credentials.
> 
> The first mention of CTs in the security policies has some text to that.
> 
> > -- 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.
> 
> response:
> 
> The "authentication" here is a plain error -- it is the authorization that needs to
> be checked. (Fixed in https://github.com/core-wg/resource-directory/pull/271).
> 
> The First-Come-First-Remembered policy that is now provided should help the
> reader to understand how a policy can come to an authorization decision even
> with arbitrary endpoint names (see https://github.com/core-wg/resource-
> directory/pull/258).
> 
> > -- 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)?
> 
> response:
> 
> The precise identifiers used will depend on the security policies in place.
> 
> The abovementioned First-Come-First-Remembered policy makes precise points
> about the fields to introspect for that case, other to-be-defined policies are
> expected to do the same.
> 
> And as 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?
> 
> response:
> 
> There have been different approaches to the sleepy nodes problem. None has
> resulted in a WG document even, but the awake helper being a proxy is a
> common theme. Note that a proxy does not need to contact the origin server
> to serve all requests as it may have a fresh representation. The different
> approaches to sleepy result in "beefed up" proxies that have better chances of
> being able to serve some kind of cached response.
> 
> > ** 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).
> 
> response:
> 
> They do now (as per https://github.com/core-wg/resource-directory/pull/264).
> 
> > ** Section 4.0.  Per “… falling back to failing the operations if
> > recovery is not possible”, can “failing the operation” be clarified?
> 
> response:
> 
> Not without growing the text a lot. A failed operation's meaning depends on
> the
> operation: In steps from finding an RD to registration, it means stopping
> whatever was just tried and continuing with other options, and eventually
> running out of them notifying the user. In regstration updates, it means that a
> new registration is started. In lookups, the application may fall back to methods
> outside the specification (eg. doing multicast discovery when no RD is around
> or usable) or just report to the user.
> 
> For where there is something to say, sections contain paragraphs starting "If
> the ... fails".
> 
> > ** 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?
> 
> response:
> 
> If there is a security policy in place for link confidentiality, yes. The presence of
> such a policy doesn't rule out replication at all, though -- if the target directory
> is authorized to receive the links (as it upholds the same link confidentiality
> policies), forwarding can still be justified, and is expected to happen like that in
> managed installations.
> 
> The paragraph has been amended to refer to the security policies applicable to
> lookups. (Concrete change in https://github.com/core-wg/resource-
> directory/pull/272).
> 
> > ** Section 4.1.  Per “2. In a network that supports multicast well,
> > …”, what does it mean to “support multicast _well_”?
> 
> response:
> 
> "Not well" is meant to roughly summarize "not efficiently" (when the multicast
> would be flooded over many individual links), "not conveniently" (when it
> works but the tooling around it makes it hard to use for implementations), or
> even "not at all" (when other CoAP transports than CoAP-over-UDP are
> involved).
> 
> > ** Section 5.  Per the ep definition of the URI Template Variables,
> > what does it mean for the an endpoint to be “(mostly mandatory)?
> 
> "Mostly mandatory" here means that it is mandatory unless the RD is
> configured to recognize the endpoint name from the credentials.
> Enhancements have been made to the wording of the exception at
> https://github.com/core-wg/resource-directory/pull/273, which should make
> the phrase "mostly mandatory" fully understandable by the end of the item.
> 
> > ** 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”.
> 
> response:
> 
> See GENERIC-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?
> 
> response:
> 
> Applications can describe typical sizes of their deployments; for example, in a
> single-tenant home automation system, 256 is a sane upper bound for the size
> estimate, so 4 hex digits would suffice.
> 
> Where there's no such estimates available, the UUID way is universally
> applicable.
> 
> > ** 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.
> 
> response:
> 
> The intended verification is with a trusted source, which would typically be the
> server hosting the resource.
> 
> This became part of a larger discussion around server authorization at
> <https://mailarchive.ietf.org/arch/msg/core/JyW0XAkXre1wvKoNxMwegOUCy
> wc/>,
> and while there is hope that what comes of this will be useful to CoRE (or even
> web) applications in general, the changes to the text ("to request it again from
> an authorized server, typically the one that hosts the target resource",
> https://github.com/core-wg/resource-directory/pull/306) should make the
> paragraph itself clear enough.
> 
> > ** 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”
> 
> response:
> 
> A reference has been added in the other direction, as that is where the care
> must be taken -- the "MAY make [...] available" now cautions about any link
> confidentiality policies (change in https://github.com/core-wg/resource-
> directory/pull/272).
> 
> > ** Editorial Nits -- Global.  s/can not/cannot/g
> 
> response:
> 
> Addressed in https://github.com/core-wg/resource-directory/pull/253
> 
> > -- 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.
> 
> response:
> 
> Understandable; it was changed in https://github.com/core-wg/resource-
> directory/pull/274.