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

"Ben Campbell" <ben@nostrum.com> Thu, 09 April 2015 14:08 UTC

Return-Path: <ben@nostrum.com>
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 62D631A1B29; Thu, 9 Apr 2015 07:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 25Qv1XCpXd1e; Thu, 9 Apr 2015 07:08:10 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7218C1A1B51; Thu, 9 Apr 2015 07:08:10 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39E7ufX090728 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 09:08:06 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: "Derek Atkins" <derek@ihtfp.com>
Date: Thu, 09 Apr 2015 09:07:55 -0500
Message-ID: <E4980EE8-5CBE-46D1-9B39-BE97B041B148@nostrum.com>
In-Reply-To: <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org>
References: <sjmoaosz53h.fsf@securerf.ihtfp.org> <C3DD8EE5-B066-4C06-99F4-B9147A128811@nostrum.com> <C17AE3D5-F62D-42A3-9F1F-885BF1B984EB@nostrum.com> <551EFB9C.4040504@xiph.org> <sjmy4m5grwp.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>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/UF3XOKHKHFH2ZSdzIh5dOFNk7VE>
Cc: "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, Colin Perkins <csp@csperkins.org>
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: Thu, 09 Apr 2015 14:08:11 -0000

On 9 Apr 2015, at 9:00, Derek Atkins wrote:

> Ben,
>
> On Thu, April 9, 2015 9:45 am, Ben Campbell wrote:
>> On 9 Apr 2015, at 8:31, Derek Atkins wrote:
>>
>>> Colin Perkins <csp@csperkins.org> writes:
>>>
>>>> I think "SHOULD use an appropriate strong security mechanism" is
>>>> quite
>>>> different to "SHOULD use SRTP", since we know of cases where SRTP
>>>> isn't suitable. That was my objection to the original text.
>>>
>>> I'm fine with "SHOULD use an appropriate strong security mechanism",
>>> which is what I tried to convey with my added sentence to the 
>>> guidance
>>> paragraph.
>>
>> I would be okay with "SHOULD use an appropriate strong security
>> mechanism". I assume the intended difference is the removal of the 
>> "as
>> suggested by those references" part.
>
> 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"?

>
> -derek
> -- 
>      Derek Atkins                 617-623-3745
>      derek@ihtfp.com             www.ihtfp.com
>      Computer and Internet Security Consultant