[core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-resource-directory-26: No Objection

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/



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

Thanks for the updates in the -26; they help a lot.

I'm particularly happy to see the (default/example)
"first-come-first-remembered" policy in § 7.5, which does a good job of
documenting its properties (including potential deficiencies) and can be
usable for many environments.  (I do have some suggestions for
improvements to the specific wording in the section-by-section comments,
but on the whole I like it.)

It does lead in to a more general comment, though (which is not exactly
new to the changes in the -26 though it is reflected in several of
them): some aspects of the concept of "authorization" to appear in a
directory, and the verification of authorization for the entire flow
from client locating the RD server to final request at the discovered
resource, are somewhat subtle.  (The new text discusses, e.g., "repeat
the URI discovery step at the /.well-known/core resource of the
indicated host to obtain the resource type information from an
authorized source" and "a straightforward way to verify [discovered
information] is to request it again from an authorized server, typically
the one that hosts the target resource".)  The aspects I'm concerned
about are not matters of a resource server being authorized to publish
to a directory or a client deeming that a server is authorized to act as
an RD (though both of those are also important), but seems to rather
just be relating to the RD faithfully disseminating the information the
RD retrieved from /.well-known/core discovery on the given server(s)
(or otherwise learned via some other mechanism).
In this sense the RD is just acting as a cache or efficiency aid, but
the authoritative source of the information remains (in general) the
server hosting the resource.  To be clear, I think the procedures that
this document specifies are good and correct procedures for a client to
perform, I'm just not sure whether "authorized" is the right term in
these cases; "authoritative" might be more appropriate, in that the
operation in question is to verify the information retrieved from the RD
(which acts in some sense as an intermediary) at the more authoritative
source.

(On a tangent from that note, it seems that there is not necessarily any
indication to a client that a server claiming to provide a given
resource (whether discovered via RD or /.well-known/core) is actually
authorized to provide such a resource and be trusted by the client.  But
that's not really a property of RD, and rather the underlying CoRE
mechanism and any provisioned trust database, so my thoughts about it
seem out of scope for this document.)

Section 5.1

   URI Template Variables are as they are for registration in Section 5.
   The base attribute is not accepted to keep the registration interface
   simple; that rules out registration over CoAP-over-TCP or HTTP that
   would need to specify one.  For some time during this document's
   development, the URI template "/.well-known/core{?ep,...}" has been
   in use instead.

(It's not entirely clear to me what the reader is expected to do with
the information about the previous formulation.)

Section 7.3

   In this case, the endpoint (and not the lookup clients) needs to be
   careful to check the RD's authorization.

(It seems that something also needs to cause the RD to check the
authorization of lookup clients to receive the information in question,
which might be worth reiterating in this section.)

Section 7.5

   *  If the client's credentials indicate any subject name that is
      certified by any authority which the RD recognizes (which may be
      the system's trust anchor store), all those subject names are
      stored.  [...]

I'm pretty sure the intent here is that only the subject names that are
certified by the recognized authority(ies) are stored, in which case I'd
suggest to s/all those/all such/.

      With X.509 certificates, the Common Name (CN) and the complete
      list of SubjectAltName entries are stored.  In both cases, the
      authority that certified the claim is stored along with the
      subject, as the latter may only be locally unique.

(I can understand why the "store the whole list" logic is used, though
there may be some subtleties about name constraints on the (X.509) CAs
used, which is why we typically don't recomment treating the entire list
of names in the certificate as validated from a single operation,
instead preferring "is this certificate authenticated for this specific
name?" when the specific target name is available.)

   *  If neither is present, a reference to the security session itself
      is stored.  With (D)TLS, that is the connection itself, or the
      session resumption information if available.  With OSCORE, that is
      the security context.

Should we talk about whether the lifetime of registration entries is
related to the various lifetimes of these credentials/identifiers?  DTLS
without resumption is perhaps an interesting case, in that keeping the
DTLS association "live" just to be able to update the registration
information seems impractical, so perhaps some fixed cap would be
applied on the lifetime in that case.  If resumption is used, the
resumption information (ticket or session state) has some finite
lifetime that could be used to bound the lifetime of the registration.
IIRC an OSCORE security context can also have an expiration time;
certificates and JWT/CWT have expiration time as well (though the
procedures in the first bullet point would effectively allow a "renewal"
operation), but the validity period (if any) of a raw public key would
have to be provisioned along with that key (or just have RPK be handled
akin to DTLS without resumption, I guess).

   Any operation on a registration resource, including registrations
   that lead to an existing registration resource, MUST be rejected by
   the RD unless all the stored information is found in the new
   request's credentials.

(Similar to my earlier parenthetical comment, the requirement for exact
match of all subject name information is unusual.  In effect this is a
way of pinning the set of names that the CA has chosen to include in a
single certificate, which is arguably a stronger requirement than needed
but should not lead to any unauthorized access.)