[secdir] secdir review of draft-ietf-forces-protoextension-04

Tobias Gondrom <tobias.gondrom@gondrom.org> Mon, 04 August 2014 22:17 UTC

Return-Path: <tobias.gondrom@gondrom.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 683121A0367; Mon, 4 Aug 2014 15:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.001
X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vc2yyd9m65RQ; Mon, 4 Aug 2014 15:17:44 -0700 (PDT)
Received: from www.gondrom.org (www.gondrom.org []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3777B1A0350; Mon, 4 Aug 2014 15:17:44 -0700 (PDT)
X-No-Relay: not in my network
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=L2jOhswxAW41IUamdneOZJuLe+QHXYN5Cfts1v/iUJohar6KR6+8q6zX2G6ugeNbexci2WCTNy24UgCPg4QjFl6+CC3nIzn7YxVYHHgsMDZZA1Y0/jG2cXExdfy9r+3Pnv90XhtbgsYbIhOHRXEF2Rar6Zb9ER7k+DdsPqsxaiM=; h=X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type;
X-No-Relay: not in my network
X-No-Relay: not in my network
Received: from [] (5ec20b19.skybroadband.com []) by www.gondrom.org (Postfix) with ESMTPSA id 997981539007B; Tue, 5 Aug 2014 00:17:42 +0200 (CEST)
Message-ID: <53E00686.7030909@gondrom.org>
Date: Mon, 04 Aug 2014 23:17:42 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: draft-ietf-forces-protoextension.all@tools.ietf.org, iesg@ietf.org
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------040302020804040505010707"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LscY2CxPp5Ksgd-IDZxfSmeqBA0
Cc: secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-forces-protoextension-04
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, 04 Aug 2014 22:17:55 -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.

The draft is standards track and describes a few extensions to ease
programmability and to improve wire efficiency of some transactions. It
adds extensions to the ForCES Protocol RFC5810 and RFC7121.

The document appears mostly ready for publication.

The security considerations section (section 6) only refers to RFC 5810.

1 Nits and 3 Questions regarding the security section below:

- section last paragraph:

1. section last paragraph: 
"On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a
   master CE can turn on support for extended results by setting the
   value to 2 in which case the FE MUST switch over to sending only

Not sure about the full network topology, but could that enable a master
CE to effectively make the replies of a FE unreadable to other
old-version CEs (which can only understand RESULT-TLVs) by switching on
the "only" new EXTENDEDRESULT-TLVs?

2. with the New Codes in section 3.2.1. :
do any of the new more detailed error codes (e.g. "E_EMPTY |  Table is
empty") pose a risk of data leakage of information detail that was not
intended to be disclosed in that detail in the original RFC 5810?

3. section 3.1.:
Could the new "TABLERANGE-TLV", which requires significantly more
computing on the receiver per request from the sender, enable an
attacker for a type of Denial of Service attack scenario?

NOTE: though I reviewed the ID, I did not validate the XML structure in
appendix A.

Thank you and best regards.