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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 13 November 2015 21:15 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4D41B3214; Fri, 13 Nov 2015 13:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL0IeNcB_OBF; Fri, 13 Nov 2015 13:15:15 -0800 (PST)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438821B3201; Fri, 13 Nov 2015 13:15:15 -0800 (PST)
Received: by ykdv3 with SMTP id v3so169660092ykd.0; Fri, 13 Nov 2015 13:15:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cfOXzCkrDvER6LZ4ooy0qfl2T5AxCMEGTstXltPeyW8=; b=wMT9WbflPrg0uN5yqTz2bjOtnvq6yizMOiHeF3tJu9GYGbFupk/NofoWblUK8CfZ1+ ZskFkEOOO+sEWRUtn9W1ZUJGbOd2TBtNBX1y4mOXjhSD7zP5r/Ata8Ifi97zc4045ykO YTn25Cf5oIIB+YTdUrFozz73nA5xbUmx6/RX/Mz1y2GtQsDcVA50AXB5/c47HKnFpojG xTr8mHoHgclHKHAuprcRxlWiL5nm9+RVQi5AgWShbd/0tnlRHh67kLTUYNVtfDtiMw8q DlHynaqJLEm4inXb96bqjbSuOC2CnuzGdsWwrrjfIgVS8CoCse1rfKHZh6ffTaf2bM7Y LEnA==
MIME-Version: 1.0
X-Received: by 10.13.210.134 with SMTP id u128mr3450834ywd.175.1447449314498; Fri, 13 Nov 2015 13:15:14 -0800 (PST)
Received: by 10.31.149.79 with HTTP; Fri, 13 Nov 2015 13:15:14 -0800 (PST)
In-Reply-To: <D26B8E4A.5EAFE%eckelcu@cisco.com>
References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <CAKKJt-ci2kndZsxmkUKchWCcEPApvoFT9QMsw6MeC7hfKso3tQ@mail.gmail.com> <D261445D.5E397%eckelcu@cisco.com> <CAKKJt-euqJ6skSf_0ivT04Yi5NpGPBSeWTOOiJRqq5QOrS61xA@mail.gmail.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> <CAKKJt-fivGMaovuPuPsr1MnAuPW+qRc=g3=yHVX=71iE4LqKTg@mail.gmail.com> <D26216C3.5E457%eckelcu@cisco.com> <0BAEEA7C-B892-460B-AAD3-80A0F85E766D@cooperw.in> <CAKKJt-dNc8ijc-8HqXAtS_QEPDQrw51dODLuycHteTgqHJ==Ew@mail.gmail.com> <D26B7187.5EAB9%eckelcu@cisco.com> <CAKKJt-eix9N15_7DO_hRt4yry4-buDREOGut3CwBS1eNy9GqTg@mail.gmail.com> <D26B8E4A.5EAFE%eckelcu@cisco.com>
Date: Fri, 13 Nov 2015 15:15:14 -0600
Message-ID: <CAKKJt-dYn2s=4RM0yOg0aji=FO-2CwkRf26_iBJ3ooXfFPAYbg@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
Content-Type: multipart/alternative; boundary=001a114e4e7438a07b0524728eb9
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/NAzTQW7Ppg2zofaGxF71g90xyKE>
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Alissa Cooper <alissa@cooperw.in>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "Paul E. Jones" <paulej@packetizer.com>, IESG <iesg@ietf.org>, Mary Barnes <mary.ietf.barnes@gmail.com>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 21:15:19 -0000

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