Skip to main content

Last Call Review of draft-ietf-bfcpbis-bfcp-websocket-13
review-ietf-bfcpbis-bfcp-websocket-13-genart-lc-sparks-2017-01-04-00

Request Review of draft-ietf-bfcpbis-bfcp-websocket
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-01-11
Requested 2016-12-21
Authors Victor Pascual , Anton Roman , Stephane Cazeaux , Gonzalo Salgueiro , Ram R
I-D last updated 2017-01-04
Completed reviews Genart Last Call review of -13 by Robert Sparks (diff)
Opsdir Last Call review of -13 by Bert Wijnen (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-ietf-bfcpbis-bfcp-websocket by General Area Review Team (Gen-ART) Assigned
Reviewed revision 13 (document currently at 15)
Result Ready w/issues
Completed 2017-01-04
review-ietf-bfcpbis-bfcp-websocket-13-genart-lc-sparks-2017-01-04-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bfcpbis-bfcp-websocket13-
Reviewer: Robert Sparks
Review Date: 2017-01-04
IETF LC End Date: 2017-01-11
IESG Telechat date: 2017-01-19

Summary: Basically ready but with issues that need to be addressed
before publication as a Proposed Standard

Issues: 

The BFCP spec (at draft-ietf-bfcpbis-rfc4582bis) relies heavily on
recommendations it makes about the use of TLS or DTLS, and even goes to
the point of specifyig a particular set of cipher suites to use wih
those protocols when using them with BFCP. The security considerations
section of that document details some specific attacks and how the use
of TLS/DTLS mitigates them (providing some justification for the cipher
suites that the document specifies).

This document provides a _COMPLETELY DIFFERENT_ security mechanism
(essentially punting entirely to whatever a websocket library provides
with the expectation that that will also be rooted in TLS) when it
substitutes websockets as the layer under BFCP. The security
considerations section needs to make this much more obvious -
implementers and deployers need to be see this as a strong-primary
point to avoid anyone thinking all the thinking that went into securing
BFCP as captured in draft-ietf-bfcpbis-rfc4582bis still applies.

There should be more discussion about what a BFCP implementation that
cares about the attacks discussed in section 14 of
draft-ietf-bfcpbis-rfc4582bis requires of its library. The current
document gets most of the way there, but there are things missing.
Shouldn't there be some discussion of ensuring the websocket library
used supports and will use the cipher suites called out in the core
BFCP document? If not, this document needs to be very explicit that you
are only going to get the confidentiality protection the library
provides. The current consideration section calls out relying on "a
typical webserver-client model" and talks about server authentication,
but not client authentication. Section 8 shows most of what you're
expecting the server to do to authenticate the client, but you need
more text about what you expect the client libraries to be doing to let
the server do its job (and you should point back to that from the
security considerations section).

I strongly recommend simply walking through the cases again in the
security considerations section of this document, explaining how the
websocket library and the bfcp implementation are going to interact to
mitigate the attacks. 

Nits/editorial comments: 

The 3rd paragraph of section 3 speaks generally about how the websocket
protocol works - you call out it can carry text or binary data and that
it supports split frames. But then you go on to constrain the use of
the protocol in this document to a particular bit of binary data and
constrain using the protocol to not split frames (and to only put one
BFCP message in each frame). This is confusing. I suggest deleting the
second sentence of that paragraph and the indented call-out below it.
If the observation about the API callbacks is important, work it in 
where you talk about the one-messsage-per-frame restriction.

The last sentence of the second paragraph of section 5 relies on an
inference that you should make explicit. Instead of "is a server on the
Internet", say "will have a globally routable address". 

The last paragraph of 6.1 is not logically sound - it falls apart at
"So". Please restructure it. As it stands, it says something like:
'Some soda manufacturers don't provide sugar-free variants of their
soda. Therefore, we recommend always drinking sugar-laden soda, but we
allow drinking sugar-free.' What were you actually trying to say?