Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Thu, 05 November 2015 22:12 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B4B1B3C3E for <bfcpbis@ietfa.amsl.com>; Thu, 5 Nov 2015 14:12:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
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 8Goclfnz9xIs for <bfcpbis@ietfa.amsl.com>; Thu, 5 Nov 2015 14:12:29 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A47C1B3C54 for <bfcpbis@ietf.org>; Thu, 5 Nov 2015 14:12:23 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D69C7208B4 for <bfcpbis@ietf.org>; Thu, 5 Nov 2015 17:06:35 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 05 Nov 2015 17:06:35 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=mqHkCm2tER9gZj+jdxVmKKZ3Qvk=; b=PX3jnX Np8xSR4Zgezj6BGXEUi11dJeUPrESdrm+bq7qEuRCrn3grFUTVKs08ycvPwfjHf4 rq9a1BKKP+qC+vEpVWoxZCr1jagq2c5FFcHXHFQ5+pUtmjRUw/5zEh52qhPTDAJq sipZoVfkt46m4z7dHYtduB/qXxtdQ3dpSwrn4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=mqHkCm2tER9gZj+ jdxVmKKZ3Qvk=; b=SsVuox0+Wx6Hak5757ooi+kO9QDa6UVt89FjFS4Zo4A5KjR 15mebGE28hmywHILJ9ECw98W3rGriynmSK4UNwubzQ6CA3MT9gEqaSTQD3Y9cpSB SdXnhVfzBwxMJPaZ6KbEBmNuKnDgDto6CJNoiuH9weZmwsfVdlhgC6+1b0hs=
X-Sasl-enc: EfuqTq1DXtuHfowx6z5PgBk77W/ecZQcrvv/cXQ6JIWv 1446761195
Received: from [133.93.84.252] (dhcp-84-252.meeting.ietf94.jp [133.93.84.252]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C135C016D5; Thu, 5 Nov 2015 17:06:35 -0500 (EST)
References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <CAKKJt-ci2kndZsxmkUKchWCcEPApvoFT9QMsw6MeC7hfKso3tQ@mail.gmail.com> <D261445D.5E397%eckelcu@cisco.com> <CAKKJt-euqJ6skSf_0ivT04Yi5NpGPBSeWTOOiJRqq5QOrS61xA@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAKKJt-euqJ6skSf_0ivT04Yi5NpGPBSeWTOOiJRqq5QOrS61xA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-20392379-9182-494D-962A-9FD677DC435F"
Content-Transfer-Encoding: 7bit
Message-Id: <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in>
X-Mailer: iPhone Mail (12F70)
From: Alissa Cooper <alissa@cooperw.in>
Date: Fri, 06 Nov 2015 07:06:31 +0900
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/-JGwqA4yqB2odpZqJ5rMM6H3VSM>
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "Paul E. Jones" <paulej@packetizer.com>, The IESG <iesg@ietf.org>, Mary Barnes <mary.ietf.barnes@gmail.com>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Nov 2015 22:12:30 -0000

Hi Spencer,



> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Hi, Charles,
> 
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:
>> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we do not require TLS in order to maintain backward compatibility with RFC 4582.
> 
> Got it. I'm holding my nose on this one, based on backward compatibility, and given the degree of difficulty in splicing attack packets into the TCP sequence numbering space if you're off-path. I'm not thrilled, but someone else needs to decide when threats reach the level where making that incompatible change is necessary - and that might not be the right thing to do today.
>  
>> For UDP, the reason for not mandating DTLS is backward compatibility with existing solutions. The IMTC Role Based Video Best Practice established a set of recommendations for getting BFCP to work  within enterprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS was left for future study. Today we have many implementations of BFCP over UDP, but few if any using DTLS. We need the ultimate RFC that standardizes BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.
> 
> OK, I'm not the Protocol Security Police, so, fine, but it seems like the draft could be clearer about this, and what you said in your answer would be really helpful in the document. 
> 
> If the text said something like "DTLS is REQUIRED unless you are interworking with a pre-standardization deployment that is already insecure,

"REQUIRED unless" strikes me as a faulty construction. That case is what RECOMMENDED is for, when there is a known exception to the requirement.

Alissa

> in which case you're not making things worse by running without transport-level security", that would capture my concern and reflect what you're saying, unless I'm missing something.
> 
> Thanks to you and Paul for the speedy response on the evening of Bits and Bites!
> 
> Spencer
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis