Skip to main content

Last Call Review of draft-ietf-weirds-json-response-10
review-ietf-weirds-json-response-10-secdir-lc-inacio-2014-10-30-00

Request Review of draft-ietf-weirds-json-response
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-10-24
Requested 2014-10-16
Authors Andy Newton , Scott Hollenbeck
I-D last updated 2014-10-30
Completed reviews Genart Last Call review of -10 by Dan Romascanu (diff)
Secdir Last Call review of -10 by Christopher Inacio (diff)
Assignment Reviewer Christopher Inacio
State Completed
Request Last Call review on draft-ietf-weirds-json-response by Security Area Directorate Assigned
Reviewed revision 10 (document currently at 14)
Result Has issues
Completed 2014-10-30
review-ietf-weirds-json-response-10-secdir-lc-inacio-2014-10-30-00
I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

My only concern about the security considerations section is related to
self-references necessary in the responses to cache results.  Is it possible to
create a poisoned cache based on the self-reference?  What should a client do
in order to protect itself from such an attack.

Otherwise, the security considerations for this draft are adequate in my
opinion, although I will state that the vast majority of the security
considerations are actually included by reference.  (I would have more comments
about the submitted weirds security considerations not being adequate than what
is stated in this draft.)  I would like to see the privacy section mentioned in
the security considerations section and possibly referenced from the security
considerations section.

After reading the draft, it is my view that this draft primarily describes the
data models to return weirds queries and nothing in this data model *appears*
to change any current practice with regards to privacy.

GENERAL COMMENTS:

Caching was mentioned once or twice, but not particularly described in the
draft.  I believe that topic should be covered more or removed.

I found the text overall reasonably well written, but without any motivating
text to the descriptions.  Additionally, the examples dominate the text and
tracing JSON nesting between "[" and "{" for multiple pages is quite difficult.

NITS:

Section 1.2:
        ". . . is specified in four sections:"  followed by a numbered list of
        5 items.

        "A response to a search for multiple
   objects yields a JSON object that contains an array of JSON objects
   that are the subject of the search" =>  subject should be "subjects"

Example starting on page 18:
        On page 20 it states that the example has status, port43, networks, and
        autnums.  I don't see those in the example.


Section 10.2.1
        #2 & #5 are duplicates.
        #3 & #6 differ only in the statement about trying again later. 
        (Permanent vs. transient failure message?  Maybe permanent/transient
        could be included in the "Value:" field.)


--
Chris Inacio
inacio at cert.org