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

"Ben Campbell" <ben@nostrum.com> Wed, 08 April 2015 18:53 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 568011B34FC; Wed, 8 Apr 2015 11:53:05 -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 14i58711_8g3; Wed, 8 Apr 2015 11:53:04 -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 750191B34FA; Wed, 8 Apr 2015 11:53:01 -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 t38Iqhrp060012 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 13:52:54 -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: "Derek Atkins" <derek@ihtfp.com>
Date: Wed, 08 Apr 2015 13:52:43 -0500
Message-ID: <B9A87595-5AAF-47CA-B898-8C8601D3B8C1@nostrum.com>
In-Reply-To: <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>
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> <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>
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/3614J8faaKhIwxcaHoG3t42jBCo>
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, Colin Perkins <csp@csperkins.org>
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: Wed, 08 Apr 2015 18:53:05 -0000

On 8 Apr 2015, at 9:42, Derek Atkins wrote:

> On Wed, April 8, 2015 10:35 am, Colin Perkins wrote:
> [snip]
>>
>> And as I keep saying, I believe that is inappropriate, since it's
>> recommending SRTP which is not suitable for many applications. The
>> rtp-howto draft suggests the following text:
>>
> [sniped and added below]
>>
>> (The two drafts referenced are what became RFCs 7201 and 7202).
>>
>> If you want to augment that with a "strong security SHOULD/MUST be 
>> used",
>> then I certainly don't object. However, a payload format really 
>> shouldn't
>> be trying to recommend use of a particular RTP security solution, 
>> such as
>> SRTP.
>
> Okay, so if you want to change the text completely (which I'm fine 
> with),
> how about just adding a single sentence to the end of what you have:
>
>  RTP packets using the payload format defined in this specification
>  are subject to the security considerations discussed in the RTP
>  specification RFC3550, and in any applicable RTP profile such as
>  RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>  SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>  Why RTP Does Not Mandate a Single Media Security Solution"
>  [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>  formats responsibility to discuss or mandate what solutions are used
>  to meet the basic security goals like confidentiality, integrity and
>  source authenticity for RTP in general.  This responsibility lays on
>  anyone using RTP in an application.  They can find guidance on
>  available security mechanisms and important considerations in Options
>  for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>  Applications SHOULD implement at least one of the strong security
>  measures suggested by those references.

I'm okay with using the rtp-howto text. But _strictly_as_an_individual_, 
I'd prefer not to add the last sentence, for 2 reasons:

1) This effectively creates a normative downref to informational RFCs 
(7201/7202). That's mainly a process issue, and we can do that if it's 
the right thing to do. But...

2) ... I still don't think a payload format is the right place to put 
this sort of thing (that is, the last sentence.) Now, if our plan is to 
put that text into all future payload formats, that's not quite as bad. 
But unless we plan to revise legacy formats, it still creates confusing 
inconsistency between formats.

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.