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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Thu, 05 November 2015 23:42 UTC

Return-Path: <eckelcu@cisco.com>
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 F35031B3D61; Thu, 5 Nov 2015 15:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 uEEvP-Ic0N_T; Thu, 5 Nov 2015 15:42:46 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC581B3D64; Thu, 5 Nov 2015 15:42:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16511; q=dns/txt; s=iport; t=1446766966; x=1447976566; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VzizgRKCG1S1qyqMsUneZp+e/7anQ2vEQv/hk2PhzCA=; b=Ft8y8JNugTbYMqjv+/VAS7hToRNJX7wVAV/NAuxaLGNaMK5nY8aCXVay gRg0hm8mhf7qllRQ8gVdO9pqcAIRkv4jKwh+AEL/esB/rD7KGBCJg94On zm2QHWawOOVYl8by8p4OIWIokyLFT4jL3AZLY0TREn+ixuxcFdUActHtw 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D3AQDu6DtW/5tdJa1egm5NU28GvgMBDYFfFwEJhSVKAoE9OBQBAQEBAQEBgQqENQEBAQMBAQEBZQYLBQsCAQgRAwECASMEByEGCxQJCAIEAQ0FG4d+AwoIDbxaDYQ+AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASLUoJTgigNhDEFlkgBiAyDIoF0gVqTFoNgg3EBHwEBQoIRHRaBQHIBhBeBBwEBAQ
X-IronPort-AV: E=Sophos; i="5.20,249,1444694400"; d="scan'208,217"; a="47868673"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2015 23:42:22 +0000
Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA5NgMdD026758 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 23:42:22 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 17:42:21 -0600
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 17:42:21 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Alissa Cooper <alissa@cooperw.in>
Thread-Topic: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)
Thread-Index: AQHRF3IJ5JJDWYYKUEOdhULB9tmr356NOVMAgAAGM4CAANkWAP//x2GAgACCJ4CAAASuAIAArPmA
Date: Thu, 05 Nov 2015 23:42:21 +0000
Message-ID: <D26216C3.5E457%eckelcu@cisco.com>
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> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> <CAKKJt-fivGMaovuPuPsr1MnAuPW+qRc=g3=yHVX=71iE4LqKTg@mail.gmail.com>
In-Reply-To: <CAKKJt-fivGMaovuPuPsr1MnAuPW+qRc=g3=yHVX=71iE4LqKTg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.70.233.176]
Content-Type: multipart/alternative; boundary="_000_D26216C35E457eckelcuciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/0Se78oageqo9qjgzmXXJWTbhzHE>
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>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "Paul E. Jones" <paulej@packetizer.com>, "iesg@ietf.org" <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 23:42:49 -0000

From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>>
Date: Friday, November 6, 2015 at 7:23 AM
To: Alissa Cooper <alissa@cooperw.in<mailto:alissa@cooperw.in>>
Cc: "iesg@ietf.org<mailto:iesg@ietf.org>" <iesg@ietf.org<mailto:iesg@ietf.org>>, "bfcpbis-chairs@ietf.org<mailto:bfcpbis-chairs@ietf.org>" <bfcpbis-chairs@ietf.org<mailto:bfcpbis-chairs@ietf.org>>, Paul Jones <paulej@packetizer.com<mailto:paulej@packetizer.com>>, "gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>" <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>, Mary Barnes <mary.ietf.barnes@gmail.com<mailto:mary.ietf.barnes@gmail.com>>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org<mailto:draft-ietf-bfcpbis-rfc4582bis@ietf.org>" <draft-ietf-bfcpbis-rfc4582bis@ietf.org<mailto:draft-ietf-bfcpbis-rfc4582bis@ietf.org>>, "bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>>, Charles Eckel <eckelcu@cisco.com<mailto:eckelcu@cisco.com>>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)


Hi, Alissa,

On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in<mailto:alissa@cooperw.in>> wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>> wrote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com<mailto: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.

That usage is certainly more common in some parts of the IETF than others, but it does get used. But ignoring that.

Do you think "RECOMMENDED unless you are interworking with a pre-standardization deployment that is already insecure" is tight enough?

The reason I'm asking, is that offpath attacks on UDP-based protocols are a lot easier than TCP-based protocols, and if the IETF is going to publish a proposed standard with a known deficiency to accommodate pre-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as possible.

I agree with your intent. My concern with calling out exceptions is that it can make the existing recommendation in the draft seem weaker. How about this:

OLD:

   … It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm according to Section 7 always be used.  In cases
   where signaling/control traffic is properly protected, as described
   in Section 9 it is REQUIRED to use a mandated encryption algorithm.
   BFCP entities MAY use other security mechanisms as long as they
   provide similar security properties.

NEW

   … It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm according to Section 7 always be used.  In cases
   where signaling/control traffic is properly protected, as described
   in Section 9 it is REQUIRED to use a mandated encryption algorithm.
   BFCP entities MAY use other security mechanisms to interwork with
   legacy implementation that do not use TLS/DTLS as long as these
   mechanisms provide similar security properties.

Cheers,
Charles


Thanks,

Spencer

> 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<mailto:bfcpbis@ietf.org>
>> https://www.ietf.org/mailman/listinfo/bfcpbis