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

["Paul E. Jones" <[e-mail]>]

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)" <[e-mail]>
To: "Spencer Dawkins at IETF" <[e-mail]>
Cc: "Alissa Cooper" <[e-mail]>in>; "IESG" <[e-mail]>rg>; 
"[e-mail]" <[e-mail]>rg>; "Paul E. Jones" 
<[e-mail]>om>; "[e-mail]" <[e-mail]>uk>; 
"Mary Barnes" <[e-mail]>om>; 
"[e-mail]" 
<[e-mail]>rg>; "[e-mail]" 
<[e-mail]>
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 <[e-mail]>
>Date: Friday, November 13, 2015 at 1:15 PM
>To: Charles Eckel <[e-mail]>
>Cc: Alissa Cooper <[e-mail]>in>, IESG <[e-mail]>rg>, 
>"[e-mail]" <[e-mail]>rg>, Paul Jones 
><[e-mail]>r.com>, "[e-mail]" <[e-mail]>uk>, 
>Mary Barnes <[e-mail]>om>, 
>"[e-mail]" 
><[e-mail]>f.org>, "[e-mail]" 
><[e-mail]>
>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) 
>><[e-mail]> wrote:
>>>
>>>From: Spencer Dawkins at IETF <[e-mail]>
>>>Date: Friday, November 13, 2015 at 12:51 PM
>>>To: Charles Eckel <[e-mail]>
>>>Cc: Alissa Cooper <[e-mail]>in>, IESG <[e-mail]>rg>, 
>>>"[e-mail]" <[e-mail]>rg>, Paul Jones 
>>><[e-mail]>ketizer.com>, "[e-mail]" 
>>><[e-mail]>.abdn.ac.uk>, Mary Barnes <[e-mail]>om>, 
>>>"[e-mail]" 
>>><[e-mail]>[e-mail]>, "[e-mail]" 
>>><[e-mail]>
>>>
>>>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) 
>>>><[e-mail]> wrote:
>>>>>Hi Spencer,
>>>>>
>>>>>Please see inline.
>>>>>
>>>>>From: Spencer Dawkins at IETF <[e-mail]>
>>>>>Date: Saturday, November 14, 2015 at 2:57 AM
>>>>>To: Alissa Cooper <[e-mail]>
>>>>>Cc: IESG <[e-mail]>rg>, "[e-mail]" 
>>>>><[e-mail]>[e-mail]>, Paul Jones <[e-mail]>om>, 
>>>>>"[e-mail]" <[e-mail]>uk>, Mary Barnes 
>>>>><[e-mail]>[e-mail]>, 
>>>>>"[e-mail]" 
>>>>><[e-mail]>[e-mail]>, "[e-mail]" 
>>>>><[e-mail]>;[e-mail]>, Charles Eckel <[e-mail]>
>>>>>
>>>>>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 <[e-mail]> 
>>>>>>wrote:
>>>>>>>Hi Spencer,
>>>>>>>
>>>>>>>Does Charles’ proposal below work for you?
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Alissa
>>>>>>>
>>>>>>>>On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) 
>>>>>>>><[e-mail]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>From: Spencer Dawkins at IETF <[e-mail]>
>>>>>>>>Date: Friday, November 6, 2015 at 7:23 AM
>>>>>>>>To: Alissa Cooper <[e-mail]>
>>>>>>>>Cc: "[e-mail]" <[e-mail]>rg>, "[e-mail]" 
>>>>>>>><[e-mail]>lt;[e-mail]>, Paul Jones <[e-mail]>om>, 
>>>>>>>>"[e-mail]" <[e-mail]>uk>, Mary Barnes 
>>>>>>>><[e-mail]>[e-mail]>, 
>>>>>>>>"[e-mail]" 
>>>>>>>><[e-mail]>[e-mail]>, "[e-mail]" 
>>>>>>>><[e-mail]>t;><[e-mail]>, Charles Eckel <[e-mail]>
>>>>>>>>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" <[e-mail]> 
>>>>>>>>>wrote:
>>>>>>>>> >
>>>>>>>>> > Hi Spencer,
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF 
>>>>>>>>><[e-mail]> wrote:
>>>>>>>>> >
>>>>>>>>> >> Hi, Charles,
>>>>>>>>> >>
>>>>>>>>> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) 
>>>>>>>>><[e-mail]> 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:[e-mail]
>>>>>>>>> >> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>
>>>>>>
>>>>
>>