[bfcpbis] SDP directorate review of draft-ietf-bfcpbis-bfcp-websocket-10

🔓Dan Wing <dwing@cisco.com> Sat, 06 August 2016 18:32 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC5F12B05C for <bfcpbis@ietfa.amsl.com>; Sat, 6 Aug 2016 11:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Level:
X-Spam-Status: No, score=-15.768 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 oCe5UhMg8VZM for <bfcpbis@ietfa.amsl.com>; Sat, 6 Aug 2016 11:32:12 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4032E12B054 for <bfcpbis@ietf.org>; Sat, 6 Aug 2016 11:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2416; q=dns/txt; s=iport; t=1470508332; x=1471717932; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=JfK9xEpYb5gLFCTrknX+bS1U/QtX4EDmIkJMkUBSNgQ=; b=M82jiygtkq26gHqoGnflL1urVdt/zNTAD1NSBiSxi1OwOtZI+F4OzU2L jSY1APGQOIGoiPYbawwxiID2ROk1hdI48qDCimrbDnd/azs9TYN6V1o5i /hYJz4YSUHSNhRxSGiSm7DF2m6iPUb4CM+JI6ytQN8qgnXNMYjqCavxtE I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACBgDGLKZX/4wNJK1dg0VWuguBfYYdg?= =?us-ascii?q?Sw6EgEBAQEBAQFdJ4UfP4E/iEPBHgEBCAEBAQEBASGGKoF4gVKFLYNCgi8Fjw2?= =?us-ascii?q?KLIkZhXGBa4Rbgw+FbpAsJQEuhBochywBAQE?=
X-IronPort-AV: E=Sophos;i="5.28,479,1464652800"; d="scan'208";a="134839947"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Aug 2016 18:32:11 +0000
Received: from [10.24.108.237] ([10.24.108.237]) (authenticated bits=0) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u76IW79S020230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Aug 2016 18:32:11 GMT
From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= <dwing@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 6 Aug 2016 11:31:51 -0700
Message-Id: <AE16A664-8EE6-40E8-A117-7E8FB04CAEB7@cisco.com>
To: draft-ietf-bfcpbis-bfcp-websocket@tools.ietf.org, bfcpbis@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Authenticated-User: dwing
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/SOqNvB9xMPpN6EkS1hKh-g2DBm4>
Cc: mmusic-chairs@tools.ietf.org, bfcpbis-chairs@tools.ietf.org
Subject: [bfcpbis] SDP directorate review of draft-ietf-bfcpbis-bfcp-websocket-10
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Aug 2016 18:32:13 -0000

My review of draft-ietf-bfcpbis-bfcp-websocket-10 as part of SDP directorate review.


Section 6.1, "Transport Negotiation" is unclear if it is overriding the port handling described in draft-ietf-bfcpbis-sdp-ws-uri-05, or merely re-stating the port handling described in draft-ietf-bfcpbis-sdp-ws-uri-05.  That is, the text is not clear if the port in the wss-uri override what is in the 'm' line?  I suggest using exactly the same phrasing in both documents.  This is stated clearly in Section 6.2, and should only be stated once in this document -- or perhaps just defer to what draft-ietf-bcpbis-dsp-ws-uri says and not attempt to re-discuss it here in this document would be best, no?  Section 7 seems pretty duplicative of draft-ietf-bcpbis-dsp-ws-uri, too; which document is normative where the text disagrees, and if the text is word-for-word identical, what purpose is served to repeat it?

nits:  Section 4.1 should clarify that "bFcP" is compared case-insensitive, which we all know, but bears repeating.


Section 8:
"   When a BFCP WebSocket client connects to a BFCP WebSocket server, it
   SHOULD use TCP/WSS as its transport.  The WebSocket client SHOULD
   inspect the TLS certificate offered by the server and verify that it
   is valid."

"Is valid" is too vague.  Please add citation to RFC7525, if that is appropriate.  Or if RFC7525's procedures are inappropriate, detail what steps are performed to determine validity.  It seems the a=fingerprint is *not* supposed to be used, right?  Rather, chasing the certificate chain is used against the FQDN in the wss-uri.

Section 8:
"   Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] states that BFCP clients
   and floor control servers SHOULD authenticate each other prior to
   accepting messages, and RECOMMENDS that mutual TLS/DTLS
   authentication be used."
...
"   In order to authorize the WebSocket connection, the BFCP WebSocket
   server MAY inspect any cookie [RFC6265] headers present in the HTTP
   GET request."

This "MAY" to check cookies is too weak, when the recommendation in ietf-bcpbis-rfc4582bis was mutual authentication! The server needs to better authorize the client than just a MAY!  I don't understand how this document can suggest reducing a SHOULD to a MAY, when we're talking of authorizing and authenticating clients.  

-d