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

[🔓Dan Wing <[e-mail]>]

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