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

Derek Atkins <derek@ihtfp.com> Thu, 19 February 2015 17:08 UTC

Return-Path: <derek@ihtfp.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 3A3D81A8820; Thu, 19 Feb 2015 09:08:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level:
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no
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 a6ljRbIlRSKt; Thu, 19 Feb 2015 09:08:01 -0800 (PST)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8661A8931; Thu, 19 Feb 2015 09:07:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DF12BE2036; Thu, 19 Feb 2015 12:07:55 -0500 (EST)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 18102-08; Thu, 19 Feb 2015 12:07:54 -0500 (EST)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 024CEE2035; Thu, 19 Feb 2015 12:07:54 -0500 (EST)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t1JH7qEg014364; Thu, 19 Feb 2015 12:07:52 -0500
From: Derek Atkins <derek@ihtfp.com>
To: Roni Even <roni.even@mail01.huawei.com>
References: <sjmoaosz53h.fsf@securerf.ihtfp.org> <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com>
Date: Thu, 19 Feb 2015 12:07:51 -0500
In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> (Roni Even's message of "Thu, 19 Feb 2015 05:26:33 +0000")
Message-ID: <sjmk2zdzv6g.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/NYsjM6dfLmMBBxfHRjK-dcxfsgU>
Cc: Jean-Marc Valin <jmvalin@mozilla.com>, "secdir@ietf.org" <secdir@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] 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: Thu, 19 Feb 2015 17:08:03 -0000

Roni,

I'm not an RTP guy.  To me "SRTP" is a general class of "Secure RTP"
protocols.  So let's work on that as my starting point:  implementations
SHOULD protect their RTP stream.

Based on that, how about a re-wording here?  Instead of just saying "MAY
use SRTP", how about something like "SHOULD use one of the possible RTP
Security methods (See RFC7201, RFC7202)"?  (Obviously this can be worded
better).

-derek

Roni Even <roni.even@mail01.huawei.com> writes:

> Hi,
> The reason for the may is discussed in RFC7201 and RFC 7202, it can be
> a SHOULD and these RFCs exaplain when it is not required to use SRTP.
> Maybe add a reference to these RFCs in the security section when
> saying talking about good reasons for not using SRTP
>
> Roni Even
>
> ________________________________________
> From: Jean-Marc Valin [jvalin@mozilla.com] on behalf of Jean-Marc
> Valin [jmvalin@mozilla.com]
> Sent: Tuesday, February 17, 2015 10:23 PM
> To: Derek Atkins; iesg@ietf.org; secdir@ietf.org
> Cc: payload-chairs@tools.ietf.org; koenvos74@gmail.com; jspittka@gmail.com
> Subject: Re: sec-dir review of draft-ietf-payload-rtp-opus-08
>
> Hi Derek,
>
> There was no particular reason for the MAY, the text was merely copied
> from other RTP payload RFC. I totally agree with making it a SHOULD.
>
> Thanks,
>
>         Jean-Marc
>
> On 17/02/15 02:54 PM, Derek Atkins wrote:
>> Hi,
>>
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written with the intent of improving
>> security requirements and considerations in IETF drafts.  Comments
>> not addressed in last call may be included in AD reviews during the
>> IESG review.  Document editors and WG chairs should treat these
>> comments just like any other last call comments.
>>
>> Summary:
>>
>> Ready to publish with a question: I question why the use of SRTP is a
>> MAY and not a SHOULD (as detailed in the Security Considerations
>> section).  Considering PERPASS I believe this should be a SHOULD;
>> someone should have a very good reason why they are NOT using SRTP.
>>
>> Details:
>>
>>    This document defines the Real-time Transport Protocol (RTP) payload
>>    format for packetization of Opus encoded speech and audio data
>>    necessary to integrate the codec in the most compatible way.
>>    Further, it describes media type registrations for the RTP payload
>>    format.
>>
>> I have no other comments on this document.
>>
>> -derek
>>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>
>

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant