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

Robert Sparks <rjsparks@nostrum.com> Mon, 06 April 2015 18:44 UTC

Return-Path: <rjsparks@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 5375E1A90BB; Mon, 6 Apr 2015 11:44:47 -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=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 Lb2ooZulJvob; Mon, 6 Apr 2015 11:44:43 -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 156561A90B4; Mon, 6 Apr 2015 11:44:43 -0700 (PDT)
Received: from unnumerable-2.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t36IiZFP019732 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Apr 2015 13:44:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable-2.local
Message-ID: <5522D40E.8040402@nostrum.com>
Date: Mon, 06 Apr 2015 13:44:30 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, Derek Atkins <derek@ihtfp.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>
In-Reply-To: <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/MdCPQZMOsDU5eHglGSweVWTCjns>
Cc: "secdir@ietf.org" <secdir@ietf.org>, payload@ietf.org, "jspittka@gmail.com" <jspittka@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "payload-chairs@tools.ietf.org" <payload-chairs@tools.ietf.org>, "koenvos74@gmail.com" <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: Mon, 06 Apr 2015 18:44:47 -0000

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.


>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload