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

"Ben Campbell" <ben@nostrum.com> Thu, 09 April 2015 13:41 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 E8F4F1B2D85; Thu, 9 Apr 2015 06:41:29 -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 z7Xqt-BEMwQW; Thu, 9 Apr 2015 06:41:28 -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 07A411B2D80; Thu, 9 Apr 2015 06:41:22 -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 t39Df1tb088420 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 08:41:11 -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: "Colin Perkins" <csp@csperkins.org>
Date: Thu, 09 Apr 2015 08:41:01 -0500
Message-ID: <F411DBF4-AAF5-485C-819D-0CD383498ABF@nostrum.com>
In-Reply-To: <5D09A2DB-8A85-43ED-9EEC-C5CC2867F68A@csperkins.org>
References: <sjmoaosz53h.fsf@securerf.ihtfp.org> <551C612B.4030702@mozilla.com> <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> <f9665835930b18598 ce87f90b8296b39.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <55264EAB.609080 4@cs.tcd.ie> <5D09A2DB-8A85-43ED-9EEC-C5CC2867F68A@csperkins.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/-TMWIpPZLdmGitabeKi3DuNS61Y>
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
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 13:41:30 -0000

On 9 Apr 2015, at 5:11, Colin Perkins wrote:

> On 9 Apr 2015, at 11:04, Stephen Farrell <stephen.farrell@cs.tcd.ie> 
> wrote:
>> I do agree with Colin here (and with Ben and Robert) but...
>>
>> On 09/04/15 10:58, Colin Perkins wrote:
>>> A document giving normative security guidance for unicast SIP-based
>>> telephony using RTP is something we need, I agree. I'm happy to help
>>> reviewing such a thing, but it should be authored by someone more
>>> familiar with the deployed security mechanisms.
>>
>> I've just gotten offlist mail from another secdir reviewer who
>> noted that we had exactly the same discussion 7 years ago for
>> another payload document. And I recall it myself more recently.
>
> We've been around this loop multiple times. That's why we wrote RFCs 
> 7201 and 7202, to try to stop repeating the same discussion by 
> explaining the issues and providing guidance. The recommended text for 
> new RTP payload formats in the rtp-howto was also intended to help 
> clarify. Clearly something more is needed. If the issue is that 
> RFC7202 isn't clear, then I'm happy to work with someone to clarify in 
> an update, but I suspect we need the suggested documents giving 
> normative requirements for different application classes.

The problem is not that 7202 is not clear. It "clearly" says that the 
each class of RTP application needs to specify MTI strong security. The 
problem is that no such specification exists for SIP-based RTP unicast 
applications. So saying we SHOULD follow 7202 doesn't really help.

>
>> So that unicast SIP/RTP document really would save us all some
>> time and might help those implementing and deploying security
>> stuff in such cases. (And even if folks were not implementing
>> or deploying security stuff for this 7 years ago, I would say
>> that it's much more likely they will be doing that today and
>> in future.)
>
> Agreed.
>
> -- 
> Colin Perkins
> https://csperkins.org/