[secdir] Secdir review of draft-ietf-hybi-permessage-compression-22

Robert Sparks <rjsparks@nostrum.com> Wed, 24 June 2015 21:18 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2591B2E41; Wed, 24 Jun 2015 14:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3czA62rSkgJ; Wed, 24 Jun 2015 14:18:26 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3020A1B2E40; Wed, 24 Jun 2015 14:18:26 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5OLIPfg000957 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 24 Jun 2015 16:18:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
Message-ID: <558B1E9C.8080505@nostrum.com>
Date: Wed, 24 Jun 2015 16:18:20 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "secdir@ietf.org" <secdir@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-hybi-permessage-compression.all@ietf.org
Content-Type: multipart/alternative; boundary="------------050005090203080403030500"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/ts4j9Ypol4Cs_QbSv4mBy8djKmU>
Subject: [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 24 Jun 2015 21:18:27 -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.

Summary: Ready with issues

(fwiw, I also reviewed up through version -24).

Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other.
(If that's not what it's trying to set up, please clarify).

It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that?
Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently.

This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document?

It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected.

RjS