IETF Logo Mail Archive

[secdir] SecDir review of draft-loreto-http-bidirectional-05

"Laganier, Julien" <julienl@qualcomm.com> Thu, 16 December 2010 16:36 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FE53A6911; Thu, 16 Dec 2010 08:36:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.365
X-Spam-Level:
X-Spam-Status: No, score=-106.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oka77V3rCaFn; Thu, 16 Dec 2010 08:36:50 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id E55D53A6910; Thu, 16 Dec 2010 08:36:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1292517515; x=1324053515; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"secdir@ietf.org"=20<secdir@ietf.org>,=20"iesg@iet f.org"=20<iesg@ietf.org>|CC:=20"draft-loreto-http-bidirec tional.all@tools.ietf.org"=0D=0A=09<draft-loreto-http-bid irectional.all@tools.ietf.org>|Date:=20Thu,=2016=20Dec=20 2010=2008:38:32=20-0800|Subject:=20SecDir=20review=20of =20draft-loreto-http-bidirectional-05|Thread-Topic:=20Sec Dir=20review=20of=20draft-loreto-http-bidirectional-05 |Thread-Index:=20AcudP61PHFCNnvUZQyaEtBtH++x06g=3D=3D |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F29F6FBFE5 D@NALASEXMB04.na.qualcomm.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=cFgIMvcvaNC0eLE3VVcFhHkVgYlA1TnhaD5hSwpZh/M=; b=q6/k0+pNkGV5A+KSeHGC//POk2LSImxQwnOlZrVf+X/Whv3ZTfcsBbci JaY19dZkDrjpQOes/0XH24RTI6En9HQ2zbrJRNOe196KjoBKB0CQHDypc 4Uf+/BAHmtmDbjXakMCL5uizQcDolvPVttfWIk23HhBUi3U35PnS5/Ruj w=;
X-IronPort-AV: E=McAfee;i="5400,1158,6198"; a="66890541"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 16 Dec 2010 08:38:34 -0800
X-IronPort-AV: E=Sophos;i="4.59,355,1288594800"; d="scan'208";a="19139220"
Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 16 Dec 2010 08:38:34 -0800
Received: from nasanexhc08.na.qualcomm.com (172.30.39.7) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 16 Dec 2010 08:38:36 -0800
Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 16 Dec 2010 08:38:34 -0800
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Thu, 16 Dec 2010 08:38:34 -0800
From: "Laganier, Julien" <julienl@qualcomm.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Date: Thu, 16 Dec 2010 08:38:32 -0800
Thread-Topic: SecDir review of draft-loreto-http-bidirectional-05
Thread-Index: AcudP61PHFCNnvUZQyaEtBtH++x06g==
Message-ID: <BF345F63074F8040B58C00A186FCA57F29F6FBFE5D@NALASEXMB04.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-loreto-http-bidirectional.all@tools.ietf.org" <draft-loreto-http-bidirectional.all@tools.ietf.org>
Subject: [secdir] SecDir review of draft-loreto-http-bidirectional-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 16 Dec 2010 16:36:51 -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 document describes "Known issues and best practices for the Use of Long Polling and                    Streaming in Bidirectional HTTP", and it has the following abstract:

   There is widespread interest in using the Hypertext Transfer Protocol
   (HTTP) to enable asynchronous or server-initiated communication from
   a server to a client as well as from a client to a server.  This
   document describes the known issues and the best practices related to
   the use of HTTP, as it exists today, to enable such "bidirectional
   HTTP".  The two existing mechanisms, called "HTTP long polling" and
   "HTTP streaming" are described.

The document is very clear and articulate and I have not found any security issues that were not covered appropriately in the Security Considerations sections.

I have two concerns regarding the use of "should", "must" etc.:

1. I have found at least one occurrence where a recommendation is made using lower cases "recommended" and "should". Should upper cases be used instead?

2. Similarly, parts of the text describes node behavior using lower cases "should" and "must". This makes it hard for the reader to differentiate between behavior specified in another standard document from behavior that can be reasonably expected from a deployed implementation. I would suggest that upper case requirements key words ("SHOULD", "MUST") be used if the behavior thereby enounced is specified within another RFC documents, and that document be cited next to the statement. 
 
Nits:

s/DOS attacks\.[RFC4732]/Denial-of-Service (DoS) attacks [RFC4732]/

Hope that helps,

--julien

v2.23.0 | Report a Bug | By Email