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

[Spencer Dawkins at IETF <[e-mail]>]

Thanks - and Charles' latest proposal makes me feel better about clearing.

Spencer

On Fri, Nov 13, 2015 at 3:44 PM, Paul E. Jones <[e-mail]>
wrote:

> 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]>; "IESG" <[e-mail]>; "
> [e-mail]" <[e-mail]>; "Paul E. Jones" <
> [e-mail]>; "[e-mail]" <[e-mail]>;
> "Mary Barnes" <[e-mail]>; "
> [e-mail]" <
> [e-mail]>; "[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]>, IESG <[e-mail]>, "
> [e-mail]" <[e-mail]>, Paul Jones <
> [e-mail]>, "[e-mail]" <[e-mail]>,
> Mary Barnes <[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 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]>, IESG <[e-mail]>, "
>> [e-mail]" <[e-mail]>, Paul Jones <
>> [e-mail]>, "[e-mail]" <[e-mail]>,
>> Mary Barnes <[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]>, "[e-mail]" <
>>> [e-mail]>, Paul Jones <[e-mail]>, "
>>> [e-mail]" <[e-mail]>, Mary Barnes <
>>> [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]>, "[e-mail]" <
>>>> [e-mail]>, Paul Jones <[e-mail]>, "
>>>> [e-mail]" <[e-mail]>, Mary Barnes <
>>>> [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)
>>>>
>>>> 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] <[e-mail]>
>>>> >> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>
>>>>
>>>>
>>>
>>
>