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

"Roni Even" <ron.even.tlv@gmail.com> Tue, 07 April 2015 10:06 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 A3E7E1A2130; Tue, 7 Apr 2015 03:06:16 -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 AQDljscyCBmI; Tue, 7 Apr 2015 03:06:12 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 325851A1F73; Tue, 7 Apr 2015 03:06:12 -0700 (PDT)
Received: by widdi4 with SMTP id di4so11129918wid.0; Tue, 07 Apr 2015 03:06:10 -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=qTHiJaAZfY6Tt3S/czRdFEnZoV4UleZNNH+zbhi9NSY=; b=RKNpXX6c85hGtuj2xH534QrKUUGJRdLaT7sWTjRZQnnYuIe32+T4qrZWPH3fWPElVk ylSWJOVq60adBFQwfQmQFRfEA1FiqGtKcrtw31WQU4gXJzKbmxBRV1BmnMHPIfqWh8i6 7twNMjHMKFEzkKFIagt3irIBg95CinTeC25B198dJ8VxRsHQxWNtwVonCtJIfZDyUhLv PRSpDPV6urLpE05ai/TZy0scjbxy/5SKy1mGNvn4CDyGXwRYwRT7FF80xwxGxmIGm/5y nMms+mEWz8HIYNKi/sBJdK97NoP7pvtOTWgMugk9pmzrJck7/AQ6BgU3D+3IjKvNQjIp xVow==
X-Received: by 10.194.63.172 with SMTP id h12mr37623368wjs.48.1428401170907; Tue, 07 Apr 2015 03:06:10 -0700 (PDT)
Received: from RoniE (bzq-79-180-57-80.red.bezeqint.net. [79.180.57.80]) by mx.google.com with ESMTPSA id o5sm10709647wia.0.2015.04.07.03.06.07 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Apr 2015 03:06:10 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Colin Perkins'" <csp@csperkins.org>, "'Robert Sparks'" <rjsparks@nostrum.com>
References: <sjmoaosz53h.fsf@securerf.ihtfp.org> <54E3A32F.2010008@jmvalin.ca> <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>
In-Reply-To: <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org>
Date: Tue, 7 Apr 2015 13:06:05 +0300
Message-ID: <035501d0711a$7856b0a0$690411e0$@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+fOctgPDsHC1O01O6N4gIDGikzAlk6SHYBNYQq+AJmia1wAkn1xecA0xb2jwI9Vg6LAfUZxTYBDf0c5AGkRBB0AbyniQgCQquMs5qw0GDQ
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/msgPm0D53JNZ4SnifSM1sKh4K90>
Cc: secdir@ietf.org, payload@ietf.org, jspittka@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: Tue, 07 Apr 2015 10:06:16 -0000


> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins
> Sent: 06 April, 2015 9:50 PM
> To: Robert Sparks
> Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; 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 6 Apr 2015, at 19:44, Robert Sparks <rjsparks@nostrum.com> wrote:
> > inline (particularly for Derek)
> > On 4/6/15 11:13 AM, Ben Campbell wrote:
> >> On 6 Apr 2015, at 11:09, Derek Atkins wrote:
> >>
> >>> "Timothy B. Terriberry" <tterribe@xiph.org> writes:
> >>>
> >>>> Ben Campbell wrote:
> >>>>>> So my suggestion would be something more to the effect of:
> >>>>>>
> >>>>>> "Opus does not provide any built-in confidentiality or integrity
> >>>>>> protection. Protection requirements vary between RTP applications.
> >>>>>> See RFC 7201 and RFC 7202 for a discussion.
> >>>>
> >>>> This seems like reasonable text to me. I agree with the rationale
> >>>> that preceded it. As much as I want to see encryption everywhere, a
> >>>> payload format is not the right place to mandate it.
> >>>
> >>> As was stated already in this thread, the expected follow up drafts
> >>> for MTI security have not been written.
> >>>
> >>> I leave it up to the Security ADs who have the real power here, but
> >>> I still prefer my original wording (including the SHOULD).
> >>>
> >>> I understand your reluctance because it's a codec, but it's the
> >>> first codec to get through the process since the Perpass work, which
> >>> basically says "everything should be encrypted."  Since you cannot
> >>> go back in time to modify the existing RFCs, you can augment them
> >>> going forward by other additions.
> >>>
> >>> As for the concern about "different security requirements for
> >>> different codecs", frankly I don't buy that argument.  Either your
> >>> RTP application supports security or it doesn't.  Once it does, it
> >>> should be able to negotiate that along side the codec negotitation.
> >>> So I don't see the concern -- we're not mandating a specific
> >>> security technology, just that you SHOULD use one.  Well, that's
> >>> true regardless of the codec, isn't it?
> >>>
> >>> Or are you really saying "We don't care about security.  We just
> >>> want to be able to use this codec in existing, insecure RTP
> >>> applications without adding new securty measures"?
> >>
> >> I'm saying this is the wrong layer to solve the problem.
> >>
> >> We had some work planned to better specify this in general for RTP. I
think
> the right answer is finish that work. If we do that right, it should apply
> regardless of codec.
> >>
> > That's exactly right.
> >
> > We've had this conversation several times before. The individual payload
> documents are not the place to add the kind of guidance Derek is asking
for.
> They should be about how you put things in RTP, not how applications use
(and
> secure RTP), unless there's something unique about the payload that
interacts
> with the general mechanics for using and securing RTP.
> >
> > Stephen will remember that we've queued up work on a document that would
> describe securing unicast RTP set up with SDP (capturing the outcome of
the
> rtpsec bof at IETF68). The last I heard on the subject Dan Wing was taking
the
> token to work on that document, but it's been awhile. That's where the
effort
> should focus - an individual payload document is not the right place.
> 
> +1
> 
> As Robert, and others, say, RTP payload format documents are not the right
> place to mandate security mechanisms. This is the point of RFC7202, which
is
> about how strong security can best be defined for classes of RTP
applications.
> This is not in conflict with the perpass work, since the goal of RFC7202
is to
> show how to provide strong security.
[Roni Even] What Colin says +1

> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload