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

Chris Inacio <inacio@cert.org> Mon, 27 October 2014 02:26 UTC

Return-Path: <inacio@cert.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 988671A6F03; Sun, 26 Oct 2014 19:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id e8eyHQCUimy7; Sun, 26 Oct 2014 19:26:04 -0700 (PDT)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821F41A6EF2; Sun, 26 Oct 2014 19:26:04 -0700 (PDT)
Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu []) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s9R2Q2Kv014264; Sun, 26 Oct 2014 22:26:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1414376762; bh=SPMhh0VHLuuvT45k0ft+KGDWgVcsbdiZwiAs/eID2AI=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:In-Reply-To: References; b=f3g8y4LIV186hbDYQn2LuEgmy6epilmev79uDb3lQeHu8/jVgNClm0H+OJ/qZjiLq iqtIHd7B1ZrgXywmomY1qsVW+oow+ems7wGhPrhZ60GdMPsRBxzncUdJFE5jb8SAFW fYZuSC63I/bUZAv+MUWX2iu0sr/cb8H8PGZi8Ktk=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu []) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s9R2Q7b5015634; Sun, 26 Oct 2014 22:26:07 -0400
Received: from MARATHON.ad.sei.cmu.edu ([]) by CASSINA.ad.sei.cmu.edu ([]) with mapi id 14.03.0123.003; Sun, 26 Oct 2014 22:26:00 -0400
From: Chris Inacio <inacio@cert.org>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-weirds-json-response.all@tools.ietf.org" <draft-ietf-weirds-json-response.all@tools.ietf.org>
Thread-Topic: SECDIR review of draft-ietf-weirds-json-response-10
Thread-Index: AQHP8Y1YaIwz5nPq40qGThlj74eNJQ==
Date: Mon, 27 Oct 2014 02:25:59 +0000
Message-ID: <F5B32DFF-FD3C-48A7-B24B-0232BFFA7127@cert.org>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <0512A6444B8453448D887EB34F8D5E95@sei.cmu.edu>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Btf936TQf4tTWvm1ID2hnPJwjGY
Subject: [secdir] SECDIR review of draft-ietf-weirds-json-response-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Oct 2014 02:26:06 -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.


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.


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