[bfcpbis] Ben Campbell's Discuss on draft-ietf-bfcpbis-bfcp-websocket-14: (with DISCUSS and COMMENT)

"Ben Campbell" <ben@nostrum.com> Wed, 18 January 2017 23:40 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: bfcpbis@ietf.org
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4304E126D74; Wed, 18 Jan 2017 15:40:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148478285523.2190.2128906462944738445.idtracker@ietfa.amsl.com>
Date: Wed, 18 Jan 2017 15:40:55 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/3GXzSdIXF_y329lLdHknGQ0JY_g>
Cc: bfcpbis@ietf.org, draft-ietf-bfcpbis-bfcp-websocket@ietf.org, eckelcu@cisco.com, bfcpbis-chairs@ietf.org
Subject: [bfcpbis] Ben Campbell's Discuss on draft-ietf-bfcpbis-bfcp-websocket-14: (with DISCUSS and COMMENT)
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 18 Jan 2017 23:40:55 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-bfcpbis-bfcp-websocket-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-bfcp-websocket/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I plan to ballot "yes" for this document, but I have some concerns about
the security properties that I think need to be resolved first. I have
followed the discussion resulting from Robert's Gen-ART review (and will
have comments about that in the "COMMENTS section", but I think I see an
additional issue that hasn't been covered in that discussion.

draft-ietf-bfcpbis-rfc4582bis (currently in the RFC Editors queue)
defines some situations where TLS and client authentication are
normatively required. Specifically, section 9 of that draft says that, if
the signaling channel is authenticated and has confidentiality and
integrity protection, the BFCP client MUST be authenticated. Section 14
additionally says that under those circumstances, BFCP is REQUIRED to use
the mandated cryptographic algorithm. But bfcp-websocket only says that
WSS and client authentication are RECOMMENDED.

I think this could be fixed by requiring WSS, and the web-based client
authentication techniques described in this draft whenever the signaling
protocol is secured. The simplest way to describe that might be to say
that BFCP-websocket must use at least as strong protections as the
signaling channel.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I appreciate the author's efforts in resolving the security
considerations issues from Robert's Gen-ART review, but I don't think the
current text is quite there yet. Version 14 added the text to say that,
when using websockets, the websocket security mechanisms are used instead
of those from draft-ietf-bfcpbis-rfc4582bis. But Robert also asked for
the draft to describe how that change impacts the security analysis in
draft-ietf-bfcpbis-rfc4582bis. I don't see text that does that. I'd like
to see, for each of the attacks described in
draft-ietf-bfcpbis-rfc4582bis, text that says describes how (or if) a
similar attack would be mitigated using websocket.

-4.2, first paragraph: You talk about how the payload size limit is
smaller when using websocket. Can you give guidance for actual reasonable
limits?

-5, 2nd paragraph: "The BFCP server is a will have a globally routable
address"
Is there an implied MUST hiding in there? Also, there's a typo around "is
will have".

-8, paragraph 8: Is the point that you SHOULD authenticate the client, or
that if you want to authenticate the client you SHOULD do it this way? I
suspect the former is intended, but the text implies the latter.