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