Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
"Roni Even" <ron.even.tlv@gmail.com> Tue, 07 April 2015 13:34 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 9360C1B3578; Tue, 7 Apr 2015 06:34:09 -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 evARzNh8jESj; Tue, 7 Apr 2015 06:34:05 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 E68C41B35BB; Tue, 7 Apr 2015 06:33:25 -0700 (PDT)
Received: by wiax7 with SMTP id x7so10911551wia.0; Tue, 07 Apr 2015 06:33:24 -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=Z4NhQLbpjxCoAdHBWJh98hY3TrZjEUyyODi/z0woSE4=; b=T96IekD+u3djS5Lwa8hDydAR5sjf4GuWQpZYnVUzFldpwsXrYGQjTSpfzCTIpliZJZ 1GeXm6Swff6i9YYDHPWcjaBac8ufTZp/6UbVTkupdYg2xkF0EVmZoficVg8mhX9e9jza gPLXJeOWPz0C4IK2K3dnOg9c1kNhDJvJhIoSS1XDPJhuR8T+Mk2OvUYVW2DO2W6kTp1G 0dHobI2F5vkj0260hHpZcQWQl0s2JrjAcdatTG5I+pXmiyY2oU7vS/RlrHggrv20rr+e +2FsQrj4QdQzlOWuQiyIAddCHvkgNNlUhwYpwwPZ+0eIRNAmO60r/1M3yfbO05pSbwyD CLpw==
X-Received: by 10.194.110.38 with SMTP id hx6mr39248516wjb.128.1428413604710; Tue, 07 Apr 2015 06:33:24 -0700 (PDT)
Received: from RoniE (bzq-79-180-57-80.red.bezeqint.net. [79.180.57.80]) by mx.google.com with ESMTPSA id kr5sm11017404wjc.1.2015.04.07.06.33.21 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Apr 2015 06:33:23 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Jean-Marc Valin' <jmvalin@mozilla.com>, '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> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com>
In-Reply-To: <5523C5AE.7040108@mozilla.com>
Date: Tue, 07 Apr 2015 16:33:18 +0300
Message-ID: <036a01d07137$6b6add90$424098b0$@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+AJmia1wAkn1xecA0xb2jwI9Vg6LAfUZxTYBDf0c5AGkRBB0AbyniQgCQquMswFRQeCNAchdTqCamD0VsA==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/gbSxx6-tBmUx-neSB_b4GH19iqM>
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 13:34:09 -0000
Hi Jean-Marc, I think this sounds good, I suggest also to mention RFC6562 Roni > -----Original Message----- > From: Jean-Marc Valin [mailto:jmvalin@mozilla.com] > Sent: 07 April, 2015 2:55 PM > To: Roni Even; 'Colin Perkins'; '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 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Does anyone object to this earlier proposal? > > "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." > > If not, that's probably what should go in the RFC (assuming it works for > Kathleen Moriarty's DISCUSS too). > > Jean-Marc > > On 07/04/15 06:06 AM, Roni Even wrote: > > > > > >> -----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 > > > > _______________________________________________ payload mailing list > > payload@ietf.org https://www.ietf.org/mailman/listinfo/payload > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVI8WrAAoJEJ6/8sItn9q9czQH/jWr/wOYnF/Np5pyGT/VVLQ4 > CtfYkhfI3FlwZzz0xldUW7pkiiXMXAV99pQHVV85JQ+yBjpYS+TgScoLmlXKftqt > Et41PYxD4MTA/HMqR+ayIXEwu0xLKGKZiCzeI3/4eyJq2yrMa/LoYv0E+2d9+Eow > isDpaXfayJ8OmpAEml52ErJm3bRdvuEioIarVgFqgA+jBg8F01jU34PHcw18ppnK > c93yERmrCK8wDizGYnICrRpdnLojKZ3aR+xfdFGW3JA5XbkGyR3uJc6ACM7r2ap1 > UjkYSYviOjSVk2vRnNzqi1pcnTpTjuWxE+GQTJ9o+rr1M3zESWBvYoLVyaenAQg= > =iesF > -----END PGP SIGNATURE-----
- Re: [secdir] [payload] sec-dir review of draft-ie… Kathleen Moriarty
- Re: [secdir] [payload] sec-dir review of draft-ie… Stephen Farrell
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Derek Atkins
- Re: [secdir] sec-dir review of draft-ietf-payload… Ben Campbell
- Re: [secdir] sec-dir review of draft-ietf-payload… Jean-Marc Valin
- Re: [secdir] sec-dir review of draft-ietf-payload… Ben Campbell
- Re: [secdir] sec-dir review of draft-ietf-payload… Derek Atkins
- Re: [secdir] sec-dir review of draft-ietf-payload… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Timothy B. Terriberry
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Derek Atkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Robert Sparks
- Re: [secdir] [payload] sec-dir review of draft-ie… Colin Perkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Roni Even
- Re: [secdir] [payload] sec-dir review of draft-ie… Jean-Marc Valin
- Re: [secdir] [payload] sec-dir review of draft-ie… Roni Even
- Re: [secdir] [payload] sec-dir review of draft-ie… Derek Atkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Stephen Farrell
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Stephen Farrell
- Re: [secdir] [payload] sec-dir review of draft-ie… DRAGE, Keith (Keith)
- Re: [secdir] [payload] sec-dir review of draft-ie… Colin Perkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Kathleen Moriarty
- Re: [secdir] [payload] sec-dir review of draft-ie… Colin Perkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Derek Atkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Colin Perkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Derek Atkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Colin Perkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Colin Perkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Colin Perkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Roni Even
- Re: [secdir] [payload] sec-dir review of draft-ie… Stephen Farrell
- Re: [secdir] [payload] sec-dir review of draft-ie… Derek Atkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Derek Atkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Derek Atkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Jean-Marc Valin
- Re: [secdir] [payload] sec-dir review of draft-ie… Kathleen Moriarty
- Re: [secdir] [payload] sec-dir review of draft-ie… Ben Campbell
- Re: [secdir] [payload] sec-dir review of draft-ie… Derek Atkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Colin Perkins
- Re: [secdir] [payload] sec-dir review of draft-ie… Magnus Westerlund
- Re: [secdir] [payload] sec-dir review of draft-ie… Magnus Westerlund
- [secdir] sec-dir review of draft-ietf-payload-rtp… Derek Atkins
- Re: [secdir] sec-dir review of draft-ietf-payload… Roni Even
- Re: [secdir] sec-dir review of draft-ietf-payload… Derek Atkins