Re: Review of draft-ietf-bfcpbis-bfcp-websocket-13

"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Thu, 19 January 2017 03:38 UTC

Return-Path: <rmohanr@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC40128824; Wed, 18 Jan 2017 19:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Level:
X-Spam-Status: No, score=-17.721 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=-3.199, SPF_HELO_PASS=-0.001, 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 2JBQaW2Nmt-n; Wed, 18 Jan 2017 19:38:01 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92166127071; Wed, 18 Jan 2017 19:38:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14106; q=dns/txt; s=iport; t=1484797081; x=1486006681; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GQty+59aAxcjON/VS1U69Eu2FrttrQtZX1+WWSoWWN8=; b=XcoKvhVI7LzeqDa/FbRN8/IXP/e/XubO29s5Zn2l3YpdhJV/R/uf5X4I pDvmxWkz7lW1wnOGfNKrl4Qxn9HfLLg9qbzB/f2pklEaYD0ss9hZdBA25 d0ycPNbgem3M/dVZvBp2ogVc3ApFZz7+Bbt/FBynQySXUzhJPiZFyqqmy U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CVAQC5M4BY/4oNJK1eGQEBAQEBAQEBAQEBBwEBAQEBgzkBAQEBAR9ggQkHg0qKCJICiASNKIIMKoV4AhqBbD8YAQIBAQEBAQEBYyiEaQEBAQMBIxFFDAQCAQgOAwMBAgECAiYCAgIfERUICAIEAQ0FiGgDEAgOsACCJYc6DYJ8AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4dFgmmCUTuBJxYHMQKCTC2CMQWbCjgBhl+DGINnhAWBd4UOiWiKG4hTAR84gUUVSgGGI3MBhygrgQOBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.33,252,1477958400"; d="scan'208";a="372553992"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2017 03:38:00 +0000
Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v0J3bxGw019550 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Jan 2017 03:38:00 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 18 Jan 2017 22:37:59 -0500
Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1210.000; Wed, 18 Jan 2017 22:37:59 -0500
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Robert Sparks <rjsparks@nostrum.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Subject: Re: Review of draft-ietf-bfcpbis-bfcp-websocket-13
Thread-Topic: Review of draft-ietf-bfcpbis-bfcp-websocket-13
Thread-Index: AQHSZtrvLlWBbuxPF0Ot2Hb1sMMLCaE7V2SAgAHZcICAArxVAA==
Date: Thu, 19 Jan 2017 03:37:59 +0000
Message-ID: <71C7D0A4-33D3-4A8C-87BF-1DBD260C5E4A@cisco.com>
References: <148356935771.12990.3012565684208685571.idtracker@ietfa.amsl.com> <D3CB19F0-B068-4DD8-A628-E20BEECD7707@cisco.com> <d606eaa2-391b-4e4f-40b0-c485350a32d5@nostrum.com>
In-Reply-To: <d606eaa2-391b-4e4f-40b0-c485350a32d5@nostrum.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.196.92.111]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D519E91D4245AA488294831169291A04@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lddG3ZCXwR9tPT0F_nQYr5oJCiE>
Cc: "draft-ietf-bfcpbis-bfcp-websocket.all@ietf.org" <draft-ietf-bfcpbis-bfcp-websocket.all@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2017 03:38:03 -0000

Just to close this thread. We had an offline discussion with Robert and posted a new revision with his comments incorporated. Below are the changes

In security consideration section we added:
When using BFCP over websockets, the security mechanisms defined in
   [I-D.ietf-bfcpbis-rfc4582bis] are not used.  Instead, the application
   is required to build and rely on the security mechanisms in
   [RFC6455].

On the point about websocket libraries giving the application the control to select the algorithm to use for TLS setup, there is no such control provided by the current WS API 
at https://www.w3.org/TR/2012/CR-websockets-20120920/ WebSocket W3C API spec 

New revision published with Roberts comments: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-bfcp-websocket-14

Regards,
Ram

-----Original Message-----
From: Robert Sparks <rjsparks@nostrum.com>
Date: Tuesday, 17 January 2017 at 8:51 PM
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Cc: "draft-ietf-bfcpbis-bfcp-websocket.all@ietf.org" <draft-ietf-bfcpbis-bfcp-websocket.all@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Review of draft-ietf-bfcpbis-bfcp-websocket-13

    
    
    On 1/15/17 11:36 PM, Ram Mohan R (rmohanr) wrote:
    > Hi Robert,
    >
    > Thanks for your review. Please see inline <Ram>
    >
    >> -----Original Message-----
    >> From: Robert Sparks <rjsparks@nostrum.com>
    >> Date: Thursday, 5 January 2017 at 4:05 AM
    >> To: "gen-art@ietf.org" <gen-art@ietf.org>
    >> Cc: "draft-ietf-bfcpbis-bfcp-websocket.all@ietf.org" <draft-ietf-bfcpbis-bfcp-websocket.all@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ietf@ietf.org" ><ietf@ietf.org>
    >> Subject: Review of draft-ietf-bfcpbis-bfcp-websocket-13
    >> Resent-From: <alias-bounces@ietf.org>
    >> Resent-To: <anton.roman@quobis.com>, <stephane.cazeaux@orange.com>, <gsalguei@cisco.com>, <sergio.garcia.murillo@gmail.com>, <rmohanr@cisco.com>, ><victor.pascual.avila@oracle.com>, <keith.drage@alcatel-lucent.com>, <eckelcu@cisco.com>, <ben@nostrum.com>, <alissa@cooperw.in>, ><aamelnikov@fastmail.fm>, Charles Eckel <eckelcu@cisco.com>
    >> Resent-Date: Thursday, 5 January 2017 at 4:05 AM
    >    >  Reviewer: Robert Sparks
    >     > Review result: Ready with Issues
    >      
    >     > 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.
    >
    > <Ram> I will add the below line in security consideration section. Is this sufficient?
    >
    > NEW:
    > “The security considerations described in draft-ietf-bfcpbis-rfc4582bis are applicable here as well.”
   >  Well, no. That misses the point entirely.    
    >      
    >    >  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.
    >
    > <Ram> Good point. I would prefer to add a text something to the effect of:
    >
    > “The security considerations mentioned in section 14 of [draft-ietf-bfcpbis-rfc4582bis] are applicable here. In order to mitigate
    > the attacks mentioned in section 14 of [draft-ietf-bfcpbis-rfc4582bis], it is RECOMMENDED that the clients and server use secure WebSocket
    > with an encryption algorithm according to Section 7 of [draft-ietf-bfcpbis-rfc4582bis]”
    Do websocket libraries give the application that kind of control?
    >
    >> 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).
    >
    > <Ram> section 8 second para has text on what client should do. Also 4th para has some text.  Is there anything else you would like to see in that?
    Yes - you're still looking at the text that describes how the client 
    authenticates the server.
    I was asking for more text talking about what the client needs to do to 
    allow the server to authenticate the client.
    I'm rereading the 5th paragraph now and maybe you're saying all you can.
    
    >   I will add a line in security considerations
    >
    > EXISTING:
    > The security model here is a typical webserver-
    >     client model where the client validates the server certificate and
    >     then connects to the server
    >
    > NEW:
    > The security model here is a typical webserver-
    >     client model where the client validates the server certificate and
    >     then connects to the server. Section 8 describes the authentication procedures between client and server.
    >      
    >     > 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.
    >
    > <Ram>  I am ok to delete the second line and the indented call-out.
    >
    >    >
    >    > 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".
    >
    > <Ram> Ok will fix it.
    >
    >    >
    >    > 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?
    >
    > How about changing to this?
    >
    > EXISTING:
    > Some web browsers do not allow non-secure WebSocket connections to be
    >     made.  So, while this document recommends the use of Secure
    >     WebSockets (i.e.TCP/WSS) for security reasons, TCP/WS is also
    >     permitted so as to achieve maximum compatibility among clients.
    >
    > NEW:
    > While this document recommends the use of Secure
    >     WebSockets (i.e.TCP/WSS) for security reasons, TCP/WS is also
    >     permitted so as to achieve maximum compatibility among clients.
    That's much clearer
    >
    > Regards,
    > Ram
    >      
    >      
    >      
    >      
    >
    >