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

"Paul E. Jones" <paulej@packetizer.com> Fri, 13 November 2015 21:44 UTC

Return-Path: <paulej@packetizer.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 8FD0B1B32C1; Fri, 13 Nov 2015 13:44:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Ia2lANbdonCp; Fri, 13 Nov 2015 13:44:12 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 902FE1B32C0; Fri, 13 Nov 2015 13:44:08 -0800 (PST)
Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id tADLi0iP032028 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2015 16:44:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1447451041; bh=ybc8V0Yoj8cDmKvI5KhwvPdsj0F94q3ZhmAWhQS1wF0=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=OOhlHJQe1kXTlVuBMqPBTWCrqxWq05BFBFf0a7bUoWwdMkyl2ZDLvTnOmZ3fT2rl7 ctUHUGeuBsXcjgQyseQSVEx4p0JWKFVUc40RKyJ8IZoXOw21X1iWbKrusTUzEF6DwJ tDAC1b0GAwYAAHIKwlz/GsJiWZaJSwRCyL1Pzf1g=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, "Spencer Dawkins at IETF" <spencerdawkins.ietf@gmail.com>
Date: Fri, 13 Nov 2015 21:44:00 +0000
Message-Id: <em9204e9f4-61b3-48ec-a134-1b271be5aeb3@sydney>
In-Reply-To: <D26B955B.5EB22%eckelcu@cisco.com>
User-Agent: eM_Client/6.0.23421.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB76CF6052-B515-4113-83E6-105C5E8083D5"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (dublin.packetizer.com [10.109.150.103]); Fri, 13 Nov 2015 16:44:01 -0500 (EST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/cXFt2rvgwBUOgf1USd4A3TGUtmQ>
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>, Alissa Cooper <alissa@cooperw.in>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, 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
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
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: Fri, 13 Nov 2015 21:44:16 -0000

OK, we have this and several other suggested changes from Spencer we 
discussed during 94 that were agreed.

I'll revise the text and submit a new version of the draft to include 
this and the other suggestions.

Paul

------ Original Message ------
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Spencer Dawkins at IETF" <spencerdawkins.ietf@gmail.com>
Cc: "Alissa Cooper" <alissa@cooperw.in>in>; "IESG" <iesg@ietf.org>rg>; 
"bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>rg>; "Paul E. Jones" 
<paulej@packetizer.com>om>; "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>uk>; 
"Mary Barnes" <mary.ietf.barnes@gmail.com>om>; 
"draft-ietf-bfcpbis-rfc4582bis@ietf.org" 
<draft-ietf-bfcpbis-rfc4582bis@ietf.org>rg>; "bfcpbis@ietf.org" 
<bfcpbis@ietf.org>
Sent: 11/13/2015 4:32:17 PM
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on 
draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

>Thanks Spencer. Based on your feedback, I have updated the proposal:
>
>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. An example of other
>    mechanisms is IPSEC to effectively secure a non-secure BFCP
>    connection.
>
>Cheers,
>Charles
>
>
>From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
>Date: Friday, November 13, 2015 at 1:15 PM
>To: Charles Eckel <eckelcu@cisco.com>
>Cc: Alissa Cooper <alissa@cooperw.in>in>, IESG <iesg@ietf.org>rg>, 
>"bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>rg>, Paul Jones 
><paulej@packetizer.com>r.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>uk>, 
>Mary Barnes <mary.ietf.barnes@gmail.com>om>, 
>"draft-ietf-bfcpbis-rfc4582bis@ietf.org" 
><draft-ietf-bfcpbis-rfc4582bis@ietf.org>f.org>, "bfcpbis@ietf.org" 
><bfcpbis@ietf.org>
>Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on 
>draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)
>
>>Hi, Charles,
>>
>>On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (eckelcu) 
>><eckelcu@cisco.com> wrote:
>>>
>>>From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
>>>Date: Friday, November 13, 2015 at 12:51 PM
>>>To: Charles Eckel <eckelcu@cisco.com>
>>>Cc: Alissa Cooper <alissa@cooperw.in>in>, IESG <iesg@ietf.org>rg>, 
>>>"bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>rg>, Paul Jones 
>>><paulej@packetizer.com>ketizer.com>, "gorry@erg.abdn.ac.uk" 
>>><gorry@erg.abdn.ac.uk>.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>om>, 
>>>"draft-ietf-bfcpbis-rfc4582bis@ietf.org" 
>>><draft-ietf-bfcpbis-rfc4582bis@ietf.org>is@ietf.org>, "bfcpbis@ietf.org" 
>>><bfcpbis@ietf.org>
>>>
>>>Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on 
>>>draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)
>>>
>>>>Hi, Charles,
>>>>
>>>>On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) 
>>>><eckelcu@cisco.com> wrote:
>>>>>Hi Spencer,
>>>>>
>>>>>Please see inline.
>>>>>
>>>>>From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
>>>>>Date: Saturday, November 14, 2015 at 2:57 AM
>>>>>To: Alissa Cooper <alissa@cooperw.in>
>>>>>Cc: IESG <iesg@ietf.org>rg>, "bfcpbis-chairs@ietf.org" 
>>>>><bfcpbis-chairs@ietf.org>s-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>om>, 
>>>>>"gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>uk>, Mary Barnes 
>>>>><mary.ietf.barnes@gmail.com>.barnes@gmail.com>, 
>>>>>"draft-ietf-bfcpbis-rfc4582bis@ietf.org" 
>>>>><draft-ietf-bfcpbis-rfc4582bis@ietf.org>c4582bis@ietf.org>, "bfcpbis@ietf.org" 
>>>>><bfcpbis@ietf.org>;bfcpbis@ietf.org>, Charles Eckel <eckelcu@cisco.com>
>>>>>
>>>>>Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on 
>>>>>draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)
>>>>>
>>>>>>So, we're getting there.
>>>>>>
>>>>>>On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper <alissa@cooperw.in> 
>>>>>>wrote:
>>>>>>>Hi Spencer,
>>>>>>>
>>>>>>>Does Charles’ proposal below work for you?
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Alissa
>>>>>>>
>>>>>>>>On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) 
>>>>>>>><eckelcu@cisco.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
>>>>>>>>Date: Friday, November 6, 2015 at 7:23 AM
>>>>>>>>To: Alissa Cooper <alissa@cooperw.in>
>>>>>>>>Cc: "iesg@ietf.org" <iesg@ietf.org>rg>, "bfcpbis-chairs@ietf.org" 
>>>>>>>><bfcpbis-chairs@ietf.org>lt;bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>om>, 
>>>>>>>>"gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>uk>, Mary Barnes 
>>>>>>>><mary.ietf.barnes@gmail.com>mary.ietf.barnes@gmail.com>, 
>>>>>>>>"draft-ietf-bfcpbis-rfc4582bis@ietf.org" 
>>>>>>>><draft-ietf-bfcpbis-rfc4582bis@ietf.org>fcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" 
>>>>>>>><bfcpbis@ietf.org>t;><bfcpbis@ietf.org>, Charles Eckel <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> 
>>>>>>>>>wrote:
>>>>>>>>> >
>>>>>>>>> > 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.
>>>>>>>>>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.
>>>>>>
>>>>>>Probably for Charles:
>>>>>>
>>>>>>This last sentence seems to be responsible for most of my 
>>>>>>remaining heartburn.
>>>>>>
>>>>>>My understanding was that TLS and (especially) DTLS were 
>>>>>>RECOMMENDED, not REQUIRED, because there are legacy 
>>>>>>implementations that have been deployed already. I can live with 
>>>>>>that, but is it obvious to everyone how a legacy receiver tells a 
>>>>>>sender to use a non-TLS/DTLS mechanism? I'm looking at the "use 
>>>>>>TLS" and "use DTLS" error codes in Table 5, and wondering where 
>>>>>>the "use legacy security mechanism" error code might be.
>>>>>>
>>>>>>Do legacy endpoints "just know" this?
>>>>>
>>>>>This draft describes how to use SDP to establish a BFCP connection. 
>>>>>The determination of whether to use TLS or TCP or DTLS or UDP is 
>>>>>based on the SDP offer/answer and the specification within it of 
>>>>>the m-line, e.g.
>>>>>
>>>>>m=application 50000 UDP/BFCP *
>>>>>
>>>>>
>>>>>m=application 50000 TCP/BFCP *
>>>>>
>>>>>m=application 50000 TCP/TLS/BFCP *
>>>>>
>>>>>m=application 50000 UDP/TLS/BFCP *
>>>>>
>>>>>
>>>>>When making the offer, an implementation has a choice of using any 
>>>>>of these and the answerer can choose to accept of reject. Some very 
>>>>>implementations supported TCP only. Most current implementations 
>>>>>support UDP only or in addition to TCP. In the future, we hope all 
>>>>>with support DTLS. Typically implementation the support more than 
>>>>>one transport provide configuration options, such as require DTLS, 
>>>>>or offer DTLS but accept UDP or DTLS, or offer DTLS first and if 
>>>>>rejected offer UDP. The current IMTC best practice recommends 
>>>>>offering UDP and if that fails offer TCP. This will be updated to 
>>>>>include DTLS once RFC4583bis is published.
>>>>
>>>>This all makes perfect sense to me. I'm not understanding how legacy 
>>>>implementations offering "UDP only" maps onto "other mechanisms that 
>>>>provide similar security properties" in the proposed text.
>>>>
>>>>Is "other mechanisms that provide similar security properties" even 
>>>>talking about the same thing?
>>>>
>>>>And thanks for the quick follow-up.
>>>
>>>Likewise. An example of other mechanisms is IPSEC and having a UDP 
>>>based BFCP  connection within it.
>>
>>OK, so you're talking about security mechanisms that aren't under 
>>application control at all then. I love those :D
>>
>>I'll clear, but I think the document might be clearer if you said that 
>>(even as an example).
>>
>>Thanks,
>>
>>Spencer
>>
>>>Cheers,
>>>Charles
>>>
>>>>
>>>>Spencer
>>>>
>>>>>Cheers,
>>>>>Charles
>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Spencer
>>>>>>
>>>>>>>>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
>>>>>>>>> >>mailto:bfcpbis@ietf.org
>>>>>>>>> >> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>
>>>>>>
>>>>
>>