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

"Roni Even" <ron.even.tlv@gmail.com> Thu, 09 April 2015 10:10 UTC

Return-Path: <ron.even.tlv@gmail.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 85C7C1B2DC1; Thu, 9 Apr 2015 03:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 IIw9ZHXQJ6TJ; Thu, 9 Apr 2015 03:10:44 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (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 2DF211B2DC0; Thu, 9 Apr 2015 03:10:44 -0700 (PDT)
Received: by wgsk9 with SMTP id k9so92327178wgs.3; Thu, 09 Apr 2015 03:10:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=3Rku2aadSWhpxRV/cF86B0xs8b9/9g9N/cdl9ctw08M=; b=PGsDbUVysk+YvZt4Zqvy9saUKoBNCvPM8P4KLRO/4PT9jVtVRcvXlP7C0Bcmc+zGHT /ptdfhbRKEpuu7HQYDJY3LyCsdDvb4jruN8pvpqmqB+wTkTg6slWuIr/W/lBJ94vvstt 5p9Yp5cOKpVq861n0s5rL7RhT1jnfTKWhi58YUd2PSn+IvyJv815TTQjhJeI40/vgIt3 MrwPtw/egm7UPGABSoSdlCrvhXnnKWNp8fPhLofuN0ZcjnVFna8zm+C/m9D2fQTG88Qk y8NNsz1zzeb5yr1/TcFt4CWzukKFzTkpLhk8Er/B4K9nj4667EZsfpey1r7YJCzLjrdK Pnag==
X-Received: by 10.180.208.7 with SMTP id ma7mr4995445wic.0.1428574242808; Thu, 09 Apr 2015 03:10:42 -0700 (PDT)
Received: from RoniE (bzq-79-183-196-8.red.bezeqint.net. [79.183.196.8]) by mx.google.com with ESMTPSA id mc20sm14944120wic.15.2015.04.09.03.10.38 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Apr 2015 03:10:42 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Colin Perkins' <csp@csperkins.org>, 'Ben Campbell' <ben@nostrum.com>
References: <sjmoaosz53h.fsf@securerf.ihtfp.org> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <sjmk2zdzv6g.fsf@securerf.ihtfp.org> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <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 ce87f90b8296b 39.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
In-Reply-To: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
Date: Thu, 09 Apr 2015 13:10:34 +0300
Message-ID: <04a301d072ad$6ee870a0$4cb951e0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLAzGR07a+fOctgPDsHC1O01O6N4gJZOkh2ATWEKvgCZomtcAJJ9cXnANMW9o8CPVYOiwH1GcU2AQ39HOQBpEQQdAG8p4kIAkKrjLMBUUHgjQHIXU6gAppERrgBK5MMvQKboLQIAa/Y3NwBfX3BqQKwtyf3Aft3YkEBlH20xgMMyKefAePqaP+aBT9KYA==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/4orRFtBF_OwIo58EstwVFnighE0>
Cc: secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, 'Kathleen Moriarty' <kathleen.moriarty.ietf@gmail.com>, 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 10:10:46 -0000

Hi,
I support what Colin says about SRTP being a security tool for unicast
telephony but other applications including multicast and broadcast that use
RTP may use other security mechanism.
Defining security for media in a specific application may be done when
defining the application like in RTCweb
(https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-23 section 4.2)
Roni Even

> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins
> Sent: 09 April, 2015 12:58 PM
> To: Ben Campbell
> Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; Kathleen
Moriarty;
> iesg@ietf.org; payload-chairs@tools.ietf.org; koenvos74@gmail.com; Derek
> Atkins
> Subject: Re: [payload] [secdir] sec-dir review of
draft-ietf-payload-rtp-opus-08
> 
> On 8 Apr 2015, at 20:49, Ben Campbell <ben@nostrum.com> wrote:
> > On 8 Apr 2015, at 14:38, Derek Atkins wrote:
> >>
> >> On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote:
> >>> On 8 Apr 2015, at 9:42, Derek Atkins wrote:
> ...snip...
> >>> For an extreme example, having that sentence in Codec format A and
> >>> not format B could lead to implementor decisions on the order of "I
> >>> don't want to bother with crypto, so I will choose codec B because
> >>> it has lighter requirements" might appear to make sense to someone
> >>> not steeped in this argument.
> >>>
> >>> What I'd _really_ like to do is take the energy in this thread and
> >>> apply it to creating a standards-track security document for RTP
> >>> unicast applications.
> >>
> >> Are you willing to hold up this document until that work is done so
> >> it can refer to the (yet-to-be-written) protocol security update
> >> draft?  I'm fine with that approach and I'm willing to review
> >> whatever draft you guys produce if that's how you'd like to proceed.
> >
> > No, I will go with the consensus on this one. I note that several WG
> participants objected to the orignally proposed SHOULD. I am pointing out
that
> this SHOULD is not much different, but I will go with what people want to
do.
> 
> 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.
> 
> > OTOH, what I would like to do would fix the problem for this, and all
> > other codec payload formats, after the fact if we do it right (since
> > it would apply to the application)
> >
> >>
> >> Or you can hold your nose and live with the "UGGH" of it based on
> >> what the WG original created in -08 and move forward for now, knowing
> >> that you can (and should) correct it "right" later.
> >
> > The work group did not put in a SHOULD. I think this is more of a
question of
> whether people are willing to hold there collective noses about the lack
of
> _normative_ privacy guidance for RTP in general, and if they are willing
to let
> payload formats continue to progress while that is being worked out.
> 
> One of the things RFC 7202 tries to convey is that "normative privacy
guidance
> for RTP in general" is not possible. The privacy requirements, for
example, of
> broadcast TV are different to those for a phone call, but both can use
RTP.
> 
> 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.
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload