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:48 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 00CFA1B32DD; Fri, 13 Nov 2015 13:48:09 -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 z7nKq-DtQpaN; Fri, 13 Nov 2015 13:48:04 -0800 (PST)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 94E231B3277; Fri, 13 Nov 2015 13:48:04 -0800 (PST)
Received: by vkbq142 with SMTP id q142so86675vkb.3; Fri, 13 Nov 2015 13:48:03 -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=q1h0JqUDdvo6u1vZo/mnh1VeBhLg8lmY/tfCH3Mbtlc=; b=nz3/MjphJRBwyAAcHMMTSSlnHJpOsXCzigRLRWmBdGvLf5sLw20zdN/QcRkouF//P3 mFkuAxr8dBHRpkydXvIP0/ZeRWWkq/noReL/FdV181yg5rkLjqEyL1KEhTSwH3epYtpa 805FJX2FEJMZHHHjuIw/kQF7Kc1acDyu+Y3NdQrGLpLp530mnffEOPdnbPg4L/GjAe0j tFn/eW86zJTYjE96yWJbGf1mltBNClmLj6KWtBdb7++ItlLCq44blBL82hExFlFLp87b CM/5I567PChKvd6zVp/NA9C0wWcxTJpcqa1cXNUP44MG+NUdkaqtHcaMAbrA06Ljbaes uuow==
MIME-Version: 1.0
X-Received: by 10.31.133.129 with SMTP id h123mr33756vkd.154.1447451283392; Fri, 13 Nov 2015 13:48:03 -0800 (PST)
Received: by 10.31.149.79 with HTTP; Fri, 13 Nov 2015 13:48:03 -0800 (PST)
In-Reply-To: <em9204e9f4-61b3-48ec-a134-1b271be5aeb3@sydney>
References: <D26B955B.5EB22%eckelcu@cisco.com> <em9204e9f4-61b3-48ec-a134-1b271be5aeb3@sydney>
Date: Fri, 13 Nov 2015 15:48:03 -0600
Message-ID: <CAKKJt-cqqjgt=+5Qj+JENGE730fBu0EMhy+_4BJP8pt6TikQGQ@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Content-Type: multipart/alternative; boundary=001a114110be938fe30524730301
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/xBVFDKioGtQcGVfJLWdy90jJvG8>
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>, "Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, 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:48:09 -0000

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

Spencer

On Fri, Nov 13, 2015 at 3:44 PM, Paul E. Jones <paulej@packetizer.com>
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)" <eckelcu@cisco.com>
> To: "Spencer Dawkins at IETF" <spencerdawkins.ietf@gmail.com>
> Cc: "Alissa Cooper" <alissa@cooperw.in>in>; "IESG" <iesg@ietf.org>rg>; "
> bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>rg>; "Paul E. 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>
> 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 <spencerdawkins.ietf@gmail.com>
> Date: Friday, November 13, 2015 at 1:15 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 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
>>>> >>mailto:bfcpbis@ietf.org <bfcpbis@ietf.org>
>>>> >> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>
>>>>
>>>>
>>>
>>
>