Draft: draft-ietf-core-resource-directory

Commentary: This is in response to a note from the SecDir review[1 ] . It harmonizes the general SHOULD of using protection with the policies text of being application specific , adds OSCORE to the options ( the text there was simply not touched since OSCORE became an option for CoAP ) , and points to where it says more about what comes from not following that recommendation ( for the access control part ; there is already an example in the endpoint identification part ) . [ 1 ] : Part of the changes -- will merge only when ACKed ; then it 'd go into -26 . 
 Merged while processing the previous interim 's discussion outcome . 
 Before the 2020 - 08 - 13 telechat , some reviews have come in : : Not   : Clarification on " subject " -- my intention was to include anything " subject " , but I do n't really know what else to put in there . Minor : Why is the first attempt special ? -- Can clarify , PR to come . [ edit : ] Nits addressed in More nits ( IDnits ) do not require editing , but some explanation -- where would that go ? Shepherd writeup ? ( that would be → :   that the DDOS mitigation section is a bit history heavy . I had similar comment in ; should we use that comment to shorten here ? [ edit : If so , want an ACK . ] " It is my impression , that Security Considerations were mostly written having in mind that ( D)TLS is always used , however it is only " SHOULD " in this draft ( or even " MAY " if we look at RFC6690 which Security Considerations this draft refers to ) . I think that adding a few words describing which consequences for security not using ( D)TLS would have and in which cases it is allowed will make the Security Considerations more consistent . " -- [ edit : covered in ] I 'll issue PRs for what I think we can do something about quickly , but wo n't merge them or create a -26 without an ACK on them ( given we 're late in the whole publication stage and my impression is that ill - coordinated uploads do more harm than good ) and will follow up on this comment when they 're ready for review . 
 With the additional reviews that have come in today , I see no point in addressing some of what has come in in a pre - telechat update ( as we ca n't resolve all the discuss points ) -- taking the urgency off this . I 'll still file PRs for changes resulting from the reviewer comments . Procedurally ( so this goes to or Is the general expectation with IESG comments that the text be further improved to answer all the points ( especially when they are comments ) , or can a plain " we did it that way because " suffice ? In the latter case , would it make sense to collect point - to - point responses here so they get author or WG review before " we " answer them ? 
 With and its follow - ups sent out , this is closed ; any further comments will be opened as new issues .
Mailing list commentary: Hello , 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 ] : 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 value in all responses The requirements around    and the necessity to express all looked up links in fully resolved form have stemmed from different ways has been read , both in the IETF community and by implementers . A comment from 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 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 . While steps have been taken to address the issue both on the RD discovery and the applications side ( ) , 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
Paragraph (version A):
The security considerations as described in Section 5 of RFC8288 and
Section 6 of RFC6690 apply.  The "/.well-known/core" resource may be
protected e.g. using DTLS when hosted on a CoAP server as described
in RFC7252.  DTLS or TLS based security SHOULD be used on all
resource directory interfaces defined in this document.
Paragraph (version B):
The security considerations as described in Section 5 of RFC8288 and
Section 6 of RFC6690 apply.  The "/.well-known/core" resource may be
protected e.g. using DTLS when hosted on a CoAP server as described
in RFC7252.
Paragraph (version B):
Access that is limited or affects sensitive data SHOULD be protected,
e.g. using (D)TLS or OSCORE (RFC8613; which aspects of the RD this
affects depends on the security policies of the application (see
policies).
Paragraph (version B):
The precise access controls necessary (and the consequences of
failure to enforce them) depend on the protection objectives of the
application and the security policies (policies) derived from them.
Paragraph (version A):
Security considerations: Shorten amplification mitigation by
removing the references to earlier cases of DDoS amplification,
and by removing redundancies between the problem introduction and
the description of how an RD could become part of the problem.
Paragraph (version B):
Shorten amplification mitigation by removing the references to
earlier cases of DDoS amplification, and by removing
redundancies between the problem introduction and the
description of how an RD could become part of the problem.