Subject: [secdir] SECDIR review of draft-ietf-weirds-json-response-10

From: Chris Inacio <[email-masked]>
Date: Mon, 27 Oct 2014 02:25:59 +0000

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
[email-masked]

---

From: Andy Newton <[email-masked]>
Date: Mon, 27 Oct 2014 22:56:27 +0000

Thanks for the review Chris. Comments are in-line...

On 10/26/14, 10:25 PM, "Chris Inacio" <[email-masked]> wrote:

>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.

Yes, I guess cache poisoning is possible. Good catch!

I plan to add the following paragraph to Section 5 where caching is
described:

  Clients using ³self² links for caching SHOULD not cache any object
  class instances where the authority of the self link is different
  than the authority of the server returning the data. Failing to do
  so might result in cache poisoning.

-andy