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

[Benjamin Kaduk <[e-mail]>]

Hi Christian,

(inline)

On Fri, Feb 26, 2021 at 04:32:25PM +0100, Christian M. Amsüss wrote:
> Hello Ben,
> 
> thanks for the updates.
> 
> All but the last have, if any, editorial changes pending in the issue
> tracker; on that certificates point I could use a short "yes that's what
> I meant" or other suitable answer.
> 
> > [...], 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.
> 
> To get these fine points right I think I'd need an updated security
> glossary and a generally more aligned CoRE terminology on authority and
> information sources.
> 
> IMO the right place for this is the further discussion on how to do
> better in the space between "trust the RD" and "ask again". The
> continuing work on CoRAL at https://github.com/core-wg/coral/issues/59
> is a starting point.

That seems like a fine place to have this discussion; the only thing I
might consider for this document is to use "authoritative" instead of
"authorized" in the couple places I indicated.  But I'll leave that up to
you, since you've thought about it more than I have...

> >    [...]  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.)
> 
> New readers can take it as a curious historical note -- but even though
> a rought survey indicated that all implementations are straightforward
> to upgrade, we might have missed some that took this mechanism that sat
> there stable for most of the lifetime of this document for stable and
> deployed based on it. For those cases, this gives the RD operator who
> finds themselves confused by such a POST the hint to find where things
> went wrong.
> 
> >    *  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).
> 
> For DTLS, I expect that this is either done with resumption in mind, or
> on connections that are kept alive for other reasons (like the proxying
> from resource-directory-extensions). When resumption is used, the finite
> lifetime of the ticket does not give an automatic limit to the
> permissible lifetime, for (AFAIK) a new ticket can be obtained.

Yes.  I think my mental model was that the limit based on the ticket
lifetime would be provisional and could be extended if the ticket was used
to resume and a new ticket issued on the resumed session.

> If lifetime limits base on the authorization are, they should be applied
> consistently not only to first-come-first-remembered, but also to other
> time-limited authorizations and other circumstances (eg. RDs that only
> take long-lived registrations from specially authorized registrants like
> CTs). 
> 
> These are, in general, hard for the device to act on -- its choices are
> to not be discoverable (which, in models like LwM2M makes them not even
> available for reconfiguration) or to spend more resources for keepalives
> than it is configured to (which we currently have no means to express;
> core-problem-details would help here).
> 
> Under those considerations, I expect that the RD taking the registration
> even with a longer-than-comfortable-or-realistic lifetime is usually the
> best option and should thus be the generally expected way of operation.
> Other modes can be explored as well, and I've taken this up in the
> resource-directory-extensions collection (but can't promise that
> anything will come of it).

Okay.  That's all I can ask for, and thanks for talking it through a bit
here.

> > 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.)
> 
> Queued for updated text as "The RD (always, but especially here) then
> needs to verify any lookup client's authorization before reveling this
> information directly (in resource lookup) or indirectly (when using it
> to satisfy a resource lookup search criterion)".
> 
> > 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/.
> 
> Good point, queued up.
> 
> >       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.)
> >
> > [...]
> >
> > (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.)
> 
> Not sure I get this right -- would
> 
>     If the client's credentials indicate any subject name that is
>     certified by any authority which the RD recognizes **for that name**
>     (which may be the system's trust anchor store), all those subject
>     names are stored." 
> 
> be a suitable resolution?

That might just be making things more complicated for minimal benefit (and
if it is used the s/those/such/ from an earlier comment would still be
needed).  Basically, what the current text is doing is saying that "we
trust this issuer at least sometimes, and will just lump everything they
named into a single conglomerate and treat that conglomerate as an opaque
thing that must match exactly in the future".  In that sense we don't
actually care which names the issuer put in or whether we trust the issuer
to be an authority for all those names -- the actual identifier is "the
stuff the CA put in the cert" and we only need it as an opaque identifier
like that.

> I'd prefer to stick with the possibly suboptimal but at any rate easy to
> implement rule. I expect the typical RD to be coming more from a JWT /
> CWT / ACE background and not so much from an X.509 one. (Of course that
> may be just my personal angle speaking). "Match all" is hard to get
> wrong, even if it may be a tad stricter than absolutely necessary.
> 
> If we can phrase the rule better in a concise form that is still easy to
> understand for implementers, let's get this last point right --
> other than that, there can still be documented variations on this
> policy.

I don't think we're really going to be able to do better than "match all"
here without a lot of complications.  The current "match all" is a little
constraining on the CA's operations, but it is simple, as you note.  So I
think my comment here is really just a comment, and not suggesting any
(additional) changes to this document at this time.  Maybe in the future
we'll have some better ideas...

Thanks,

Ben