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

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 10 April 2015 06:52 UTC

Return-Path: <magnus.westerlund@ericsson.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 8ADF71AD0A9; Thu, 9 Apr 2015 23:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 4PzemeL4KoiY; Thu, 9 Apr 2015 23:52:36 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364741AD0A7; Thu, 9 Apr 2015 23:52:34 -0700 (PDT)
X-AuditID: c1b4fb2d-f79a46d0000006b4-70-552773301751
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.40.01716.03377255; Fri, 10 Apr 2015 08:52:33 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.210.2; Fri, 10 Apr 2015 08:52:32 +0200
Message-ID: <5527732E.60701@ericsson.com>
Date: Fri, 10 Apr 2015 08:52:30 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Derek Atkins <derek@ihtfp.com>, Ben Campbell <ben@nostrum.com>
References: <sjmoaosz53h.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> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <sjm8ue1h1hc.fsf@securerf.ihtfp.org> <D8C8B618-E131-4F64-BFAC-CA62F7A354B8@nostrum.com> <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> <E4980EE8-5CBE-46D1-9B39-BE97B041B148@nostrum.com> <f609a3a3528c26aa832927bfeb78e978.squirrel@mail2.ihtfp.org>
In-Reply-To: <f609a3a3528c26aa832927bfeb78e978.squirrel@mail2.ihtfp.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja5hsXqowcrVbBbzO0+zWyx/eYLR YuWkHewWM/5MZLa4OfcQo0XDznyLE4f/MlqcDrS4dPEsk8WHhQ9ZHLg8pt2/z+axc9Zddo8l S34yeSz/+oDFY9bOJyweXy5/Zgtgi+KySUnNySxLLdK3S+DKOL/oLFvBU6mKiSvvsDUw3hft YuTkkBAwkXh3cDEThC0mceHeejYQW0jgKKPEuycGXYxcQPZyRonGD9/AErwCmhLt1xqZQWwW AVWJVR2fwJrZBCwkbv5oBKsRFQiWaHrRyA5RLyhxcuYTFhBbRMBJYv/DPYwgQ5kFOpkkejZt B2sWFgiQuDr9PjvE5qvsEtOexIHYnAIeEh1rf7GC2MwCBhJHFs2BsuUlmrfOZoao15ZoaOpg ncAoOAvJvllIWmYhaVnAyLyKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzBGDm75rbuDcfVr x0OMAhyMSjy8D9LUQ4VYE8uKK3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwDhr7vdlqtu+i02vZL/a+U/8MbtX3k6TxxJNTDq7fh5rcxB7stmlM05mz+/tTbwC/GKG 8eVmpSGzG4r6vXdaCFVd/nSPr0rXkiGraOO/qQ93W4v5ZtWuEeLwbt5zWnz/vB/Lpbq+H757 e/vzrU76h46KBezMct369FI+S3WCcNlBTWvx31MXeCqxFGckGmoxFxUnAgAtfjI/cgIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/g--gBGGiPwGAYumGR_qg_OnL39Y>
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: Fri, 10 Apr 2015 06:52:37 -0000

On 2015-04-09 16:19, Derek Atkins wrote:
> 
> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
>> On 9 Apr 2015, at 9:00, Derek Atkins wrote:
>>
>>> Ben,
>>>
> [snip]
>>> So you're suggesting (and would be okay with) this text:
>>>
>>>  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 use an appropriate strong security mechanism.
>>>
>>
>> I am okay with that text.
>>
>>> I think I'm okay with this.  (I kind of prefer my previous wording,
>>> "Applications SHOULD implement at least one of the strong security
>>> measures suggested by those references" only because it suggests that
>>> multiple mechanisms are okay, whereas this new wording seems to imply
>>> choosing only one).
>>
>> How about "Applications SHOULD use one or more strong security
>> mechanisms, as appropriate"?
> 
> Clearly now we're just getting down to wordsmithing..  :)
> 
> How about "Applications SHOULD use one or more appropriate strong security
> mechanisms"?  (The subclause "as apporpriate" feels to me like it could be
> ignored, as in "well, using a strong security mechanism isn't
> appropriate").  I think the goal is to make sure that "appropriate"
> modifies the "strong security mechanism" and not the "SHOULD use"  ;)
> 
> What say you?

Yes, I think that is fine. I don't see this contradicting RFC7202, and
are happy to include this in draft-ietf-payload-rtp-howto's template
text. I will wait a week before submitting an update version of the
HOWTO with this text and updated references. I will send an separate
email to the list and IESG to make clear that we are proposing this
change. I note that the document is approved by IESG and thus I like to
ensure that we still have consensus on this.

I hope that other RTP Payload format authors are paying attention to
this. The template text is fairly carefully constructed  to be clear and
not blur the lines of responsibility in this matter. The point of the
above paragraph of template is to avoid this type of discussions.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------