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

["Charles Eckel (eckelcu)" <[e-mail]>]

Hi Spencer,

Please see inline.

From: Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>>
Date: Saturday, November 14, 2015 at 2:57 AM
To: Alissa Cooper <[e-mail]<mailto:[e-mail]>>
Cc: IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Paul Jones <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Mary Barnes <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Charles Eckel <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:


From: Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>>
Date: Friday, November 6, 2015 at 7:23 AM
To: Alissa Cooper <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Paul Jones <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Mary Barnes <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Charles Eckel <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>> wrote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <[e-mail]<mailto:[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.

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
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/bfcpbis