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>, "bfcpbis-chairs@ietf.org" <
> bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "
> gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <
> mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <
> draft-ietf-bfcpbis-rfc4582bis@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>, "bfcpbis-chairs@ietf.org" <
>> bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "
>> gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <
>> mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <
>> draft-ietf-bfcpbis-rfc4582bis@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)
>>
>> 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.

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