Re: [bfcpbis] Benjamin Kaduk's No Objection on draft-ietf-bfcpbis-rfc4583bis-26: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 03 December 2018 21:17 UTC

Return-Path: <kaduk@mit.edu>
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 3C68812D4E8; Mon, 3 Dec 2018 13:17:12 -0800 (PST)
X-Quarantine-ID: <iHrnb3emsATc>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 iHrnb3emsATc; Mon, 3 Dec 2018 13:17:09 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D8B1294D7; Mon, 3 Dec 2018 13:17:09 -0800 (PST)
X-AuditID: 1209190e-2ffff700000054d4-da-5c059d52422a
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id A3.D9.21716.35D950C5; Mon, 3 Dec 2018 16:17:07 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id wB3LH226026221; Mon, 3 Dec 2018 16:17:03 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wB3LGwKq032601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Dec 2018 16:17:00 -0500
Date: Mon, 03 Dec 2018 15:16:57 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "mary.ietf.barnes@gmail.com" <mary.ietf.barnes@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-bfcpbis-rfc4583bis@ietf.org" <draft-ietf-bfcpbis-rfc4583bis@ietf.org>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>
Message-ID: <20181203211657.GN54918@kduck.kaduk.org>
References: <154046788456.16346.9779422142840687916.idtracker@ietfa.amsl.com> <E35FBC91-7DFF-4EAC-A81F-1F89C5091253@ericsson.com> <20181202233442.GB54918@kduck.kaduk.org> <3E120CE1-F0A1-4097-9919-5F0CD46CDFD2@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3E120CE1-F0A1-4097-9919-5F0CD46CDFD2@ericsson.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT1w2eyxpjMHWehcXHhd9YLP6tO8pk cWHmYUaL7hVv2S1m/JnIbPF5/35mBzaPX1+vsnnsnHWX3WPJkp9MAcxRXDYpqTmZZalF+nYJ XBmPt79lL7ghU/F8h1gD40bRLkZODgkBE4mPd1ezdTFycQgJrGGS+Pe0hwXC2cAocff6bKjM HSaJpaduMYG0sAioSKy9cYcVxGYDshu6LzOD2CICZhLXP/cygTQwC6xiktizajkLSEJYIEFi 69Rd7CA2L9C+9y+2MEFMfcIo8WnvfkaIhKDEyZlPwBqYBbQkbvx7CVTEAWRLSyz/xwES5hRw kHjzeAkrSFgUaPHnBQITGAVmIWmehaR5FkLzAkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRbrG ermZJXqpKaWbGEGBzSnJt4NxUoP3IUYBDkYlHt4ZTqwxQqyJZcWVuYcYJTmYlER5VwYBhfiS 8lMqMxKLM+KLSnNSiw8xSnAwK4nwFhSyxAjxpiRWVqUW5cOkpDlYlMR5f4k8jhYSSE8sSc1O TS1ILYLJynBwKEnwnpwENFSwKDU9tSItM6cEIc3EwQkynAdoeA1IDW9xQWJucWY6RP4Uo6KU OO/vHqCEAEgiozQPrheUeCSy99e8YhQHekWYt3M6UBUPMGnBdb8CGswENDhnCxPI4JJEhJRU A+OlW2rc9/PDnJ5w9jW73LzJcrVBRKsvcdWELaFn+KKORyxj7Il+o7DzNOPxS/nJD5OrrX4k WJ8qnXyvZluy/YqOcx77bKMSJe8UnK97WLtd1Yklbsn7p5HHCrVmNQrYFByf3RH6w8HtyrzA umjxDQr3tt45Xytb/ab9uvSzH811uqGZSWmVn5VYijMSDbWYi4oTAZbHF/sXAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/eyINauB_NOiORcz5ao8JW5h9kmM>
Subject: Re: [bfcpbis] Benjamin Kaduk's No Objection on draft-ietf-bfcpbis-rfc4583bis-26: (with COMMENT)
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 03 Dec 2018 21:17:12 -0000

On Mon, Dec 03, 2018 at 12:17:28PM +0000, Christer Holmberg wrote:
> Hi,
> 
> ...
> 
>     >>>    Section 7
>     >>>    
>     >>>          Note: When using Interactive Connectivity Establishment (ICE)
>     >>>          [RFC8445], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward
>     >>>          procedures for connection management as UDP/BFCP described above
>     >>>          apply.  [...]
>     >>>    
>     >>>    nit: this sentence as written applies only when all three of ICE,
>     >>>    TCP/DTLS/BFCP, and UDP/TLS/BFCP apply (which is nonsensical).  I assume the
>     >>>    intended grouping is: (1) ICE is used, and (2) either TCP/DTLS/BFCP or
>     >>>    UDP/TLS/BFCP is used.
>     >>   
>     >> Correct. I will replace "and" with "or".
>     >
>     >I'm not sure that just replacing the one word is enough of a fix, but I
>     >trust you will do the right thing.
>     
>     I took a second look, and "or" is good :)
> 
> ---
> 
>     >>> Section 12
>     >>>
>     >>> It's probably worth noting explicitly that the non-(D)TLS proto values
>     >>> offer neither integrity protection nor confidentiality protection to the
>     >>> BFCP stream.
>     >>     
>     >> I think the protection of the BFCP streams belong to 4582bis.
>     >
>     > This is a non-blocking comment, but I think it's appropriate to mention
>     > here.	
> 
> What about:
> 
> "The usage of certain proto values in the SDP offer/answer negotiation will result in a BFCP stream that is not protected by TLS or DTLS. Operators will need to provide integrity protection and confidentiality protection of the BFCP stream using other means."

That's even better than what I would have come up with :)

>     >>> An attacker able to view the SDP exchanges can determine which media flows
>     >>> contain which content, which could exacerbate existing metadata leakage
>     >>> channels in some circumstances.
>     >>     
>     >> I am not sure how that is related to the BFCP SDP negotiation?
>     >
>     > The premise here (perhaps farfetched) is that the attacker can view the SDP
>     > exchange but the actual media flows are secured with (D)TLS and not visible
>     > to the attacker.  The (D)TLS flows will leak some information via packet
>     > size/timing, perhaps allowing for traffic analysis to determine what sorts
>     > of media flows are going where.  The new attributes in the BFCP SDP
>     > negotiation can make this sort of traffic analysis more effective.  I would
>     > be fairly receptive if you wanted to say that this is not more noteworthy
>     > than for normal SDP security considerations, though.
>     
> In general I agree with you that non-protected SDP attributes can help in traffic analysis, but the BFCP attributes only provide information about the BFCP stream itself - they don't even indicate which media streams will be controlled by BFCP to begin with (that is negotiated on BFCP level).
> 
> But, I could add something like:
> 
> "The SDP attributes defined in this specification do not add additional security considerations to the generic security considerations for protecting SDP attributes [RFC3264]. The attributes do not reveal information about the content of individual BFCP controlled media streams, nor do they reveal which media streams will be BFCP controlled." 

That's some nicely worded text, but if you conclude that it's not adding
enough value to justify its inclusion in the document, I'd support you on
it.  Thanks for the extra discussion, though; I found it helpful to think
about this area a bit more.

-Benjamin