Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08

Colin Perkins <csp@csperkins.org> Fri, 10 April 2015 07:24 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF01A00B5; Fri, 10 Apr 2015 00:24:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 nYjxShkM5Tl5; Fri, 10 Apr 2015 00:24:20 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3401A00B7; Fri, 10 Apr 2015 00:24:11 -0700 (PDT)
Received: from [81.187.2.149] (port=38464 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1YgTIO-0005Sg-LW; Fri, 10 Apr 2015 08:24:09 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <5527732E.60701@ericsson.com>
Date: Fri, 10 Apr 2015 08:24:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2194217-95C4-44C2-A435-BC5E191E29C3@csperkins.org>
References: <sjmoaosz53h.fsf@securerf.ihtfp.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <sjmpp7ggft8.fsf@securerf.ihtfp.org> <CAHbuEH63BtaENfm6-_itp1eLtSCyC8LRvGbGPbKVAR-k6GQdZA@mail.gmail.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <sjmd23ehf4o.fsf@securerf.ihtfp.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <B9A87595-5AAF-47CA-B898-8C8601D3B8C1@nostrum.com> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <sjm8ue1h1hc.fsf@securerf.ihtfp.org> <D8C8B618-E131-4F64-BFAC-CA62F7A354B8@nostrum.com> <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> <E4980EE8-5CBE-46D1-9B39-BE97B041B148@nostrum.com> <f609a3a3528c26aa832927bfeb78e978.squirrel@mail2.ihtfp.org> <5527732E.60701@ ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/9YXM_CdWQsRWhAdBs-ArnApfvts>
Cc: Ben Campbell <ben@nostrum.com>, "secdir@ietf.org" <secdir@ietf.org>, payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, payload-chairs@tools.ietf.org, koenvos74@gmail.com
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2015 07:24:22 -0000

On 10 Apr 2015, at 07:52, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> On 2015-04-09 16:19, Derek Atkins wrote:
>> 
>> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
>>> On 9 Apr 2015, at 9:00, Derek Atkins wrote:
>>> 
>>>> Ben,
>>>> 
>> [snip]
>>>> So you're suggesting (and would be okay with) this text:
>>>> 
>>>> RTP packets using the payload format defined in this specification
>>>> are subject to the security considerations discussed in the RTP
>>>> specification RFC3550, and in any applicable RTP profile such as
>>>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>>>> SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>>>> Why RTP Does Not Mandate a Single Media Security Solution"
>>>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>>>> formats responsibility to discuss or mandate what solutions are used
>>>> to meet the basic security goals like confidentiality, integrity and
>>>> source authenticity for RTP in general.  This responsibility lays on
>>>> anyone using RTP in an application.  They can find guidance on
>>>> available security mechanisms and important considerations in Options
>>>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>>>> Applications SHOULD use an appropriate strong security mechanism.
>>>> 
>>> 
>>> I am okay with that text.
>>> 
>>>> I think I'm okay with this.  (I kind of prefer my previous wording,
>>>> "Applications SHOULD implement at least one of the strong security
>>>> measures suggested by those references" only because it suggests that
>>>> multiple mechanisms are okay, whereas this new wording seems to imply
>>>> choosing only one).
>>> 
>>> How about "Applications SHOULD use one or more strong security
>>> mechanisms, as appropriate"?
>> 
>> Clearly now we're just getting down to wordsmithing..  :)
>> 
>> How about "Applications SHOULD use one or more appropriate strong security
>> mechanisms"?  (The subclause "as apporpriate" feels to me like it could be
>> ignored, as in "well, using a strong security mechanism isn't
>> appropriate").  I think the goal is to make sure that "appropriate"
>> modifies the "strong security mechanism" and not the "SHOULD use"  ;)
>> 
>> What say you?
> 
> Yes, I think that is fine. I don't see this contradicting RFC7202, and
> are happy to include this in draft-ietf-payload-rtp-howto's template
> text. I will wait a week before submitting an update version of the
> HOWTO with this text and updated references. I will send an separate
> email to the list and IESG to make clear that we are proposing this
> change. I note that the document is approved by IESG and thus I like to
> ensure that we still have consensus on this.
> 
> I hope that other RTP Payload format authors are paying attention to
> this. The template text is fairly carefully constructed  to be clear and
> not blur the lines of responsibility in this matter. The point of the
> above paragraph of template is to avoid this type of discussions.

+1 no objections


-- 
Colin Perkins
https://csperkins.org/