Re: [core] The various positions on draft-ietf-core-resource-directory-25

[Christian Amsüss <[e-mail]>]

Hello Reviewers, CoRE and IESG members,

thanks for your input to the Resource Directory document, and your
patience while it was being processed.

Before the individual point to point responses can go out, this mail is
to address the general status, and answer a few points that were brought
up by different reviewers (it will be referred back to in the point to
point responses).

In summary, the points raised in the reviews led to the changes of the
recently uploaded [-26], and where no changes were made, the reasoning
behind the choices in the document is outlined below or in the
following mails. (Either way, short of aggregated nits paragraphs, all
points are responded to in the following mails).

A few larger issues evolved from the review comments being discussed in
the interim meetings, so please expect a -27 at a later point (after
IETF109) with the changes mentioned below.

Kind regards
Christian

[-26]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-26


Preface
=======

References into the issue tracker are primarily intended for bookkeeping and to
give you access to the altered text if you're curious -- but for general review
purposes, the responses are self-contained.

Anticipated changes
===================

We have opted to submit a new version that should clear out all the other
comments, so that the remaining work can be focused and swift:

* Replay and Freshness (OPEN-REPLAY-FRESHNESS)

  The comment on DTLS replay made us reevaluate the security properties of
  operations on the registration resource. While these are successively harder
  going from DTLS without replay protection to DTLS with replay protection and
  hardest with OSCORE, the text as it is is still vulnerable to an attacker
  stopping a reoccurring registration, or undoing alterations in registration
  attributes.

  Mitigation from a concurrent document (the Echo mechanism of
  I-D.ietf-core-echo-request-tag in event freshness mode) is planned, but the
  text is not complete yet.

* Necessity of the `anchor` value in all responses

  The requirements around Limited Link Format and the necessity to express all
  looked up links in fully resolved form have stemmed from different ways
  RFC6690 has been read, both in the IETF community and by implementers.

  A comment from Esko Dijk has shown a clear error in one of the readings. That
  reading is single-handedly responsible for most of the overhead in the wire
  format (savings can go up to 50%), which is of high importance to the CoRE
  field.

  Due to that, it is the WG's and authors' intention to remove the reading from
  the set of interpretations that led to the rules set forth. The change will
  not render any existing RD server implementation incompatible (older RDs
  would merely be needlessly verbose), and the known implementations of
  Link-Format parsers can easily be updated.

  The updates to the document could not be completed in time with the rest of
  the changes, because a) it requires revisiting the known implementations for
  confirmation and b) will affect almost every example that contains lookup
  results.

* Server authorization (OPEN-SERVER)

  The two areas of "how is the RD discovery secured" and "what do applications
  based on the RD need to consider" jointly opened up new questions about
  server authorization and the linkage between a client's intention and the
  server's promises that may easily not conclusde in timeframe reasonable for
  RD.

  While steps have been taken to address the issue both on the RD discovery and
  the applications side
  (https://github.com/core-wg/resource-directory/pull/306), the ongoing
  discussions in the working group may turn up with a less cumbersome phrasing
  for these parts.

* There's a few small open issues Esko brought up on the issue tracker that
  could not be addressed in time; most of them are about enhancing the
  examples, which best happens after the anchor cleanup anyway.

Repeated topics
===============

A few common topics came up in multiple reviews, and are addressed in the
following section; the individual responses can be found in follow-up mails,
and refer to the common topics as necesary.

GENERIC-FFxxDB
--------------

"Where do the ff35:30:2001:... addresses come from?"

response:

There's a coverage gap between RFC3849 (defining example unicast addresses) and
RFC3306 (defining unicast-prefix-based multicast addresses). For lack of an
agreed-on example multicast address, the used ones were created by applying the
unicast-prefix derivation process to the example address. The results
(ff35:30:2001:db8::1) should be intuitively recognizable both as a multicast
address and as an example address.

The generated address did, however, fail to follow the guidance of RFC 3307 and
set the first bit of the Group ID. Consequently, the addresses were changed
from ff35:30:2001:db8::x to ff35:30:2001:db8::8000:x, which should finally be a
legal choice of a group address for anyone operating the 2001:db8:: site. (The
changes can be viewed at https://github.com/core-wg/resource-directory/pull/270).

GENERIC-6MAN
------------

"Whas this discussed with 6MAN?"

response:

Not yet; a request for feedback was sent out recently.

(Mail at https://mailarchive.ietf.org/arch/msg/ipv6/xY0AqPvbja45gxgW02GU3oWPTwc/).

GENERIC-WHOPICKSMODEL
---------------------

"How does the client know which security policies the RD supports?"

response:

The client can only expect any level of trustworthiness if there is a
claim to that in the RD's credentials. Typically, though, that claim will not
be encoded there, but implied. For example, when configuring an application
that relies authenticated endpoint names, then telling the application to use
the RD authenticated via PKI as coaps://rd.example.com should only be done if
the configurator is sure that rd.example.com will do the required checks on
endpoint names.

Some clarification has been added in https://github.com/core-wg/resource-directory/pull/265.

GENERIC-SUBJECT
---------------

"Section 7.1 says: '... can be transported in the subject.' -- where precisely?"

response:

That text was only meant to illustrate to the reader what such a policy could
contain, not to set one (which would require more precision).

It has been made more explicit that this is merely setting the task for the
policies. As an example, some more precision is given by referring to
SubjectAltName dNSName entries.

Changes in https://github.com/core-wg/resource-directory/pull/308.


(If you have read up to this point, please continue reading the
follow-up mails addressing the individual reviewer's points.)