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

Derek Atkins <> Mon, 06 April 2015 16:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B72B01A8AE7; Mon, 6 Apr 2015 09:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.61
X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KbB4rCQMyTzf; Mon, 6 Apr 2015 09:09:34 -0700 (PDT)
Received: from (MAIL2.IHTFP.ORG []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CAF501A8AE6; Mon, 6 Apr 2015 09:09:34 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06E3BE2038; Mon, 6 Apr 2015 12:09:33 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 26889-04; Mon, 6 Apr 2015 12:09:27 -0400 (EDT)
Received: from (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by (Postfix) with ESMTPS id 78BE4E2036; Mon, 6 Apr 2015 12:09:27 -0400 (EDT)
Received: (from warlord@localhost) by (8.14.8/8.14.8/Submit) id t36G9Qnk017843; Mon, 6 Apr 2015 12:09:26 -0400
From: Derek Atkins <>
To: "Timothy B. Terriberry" <>
References: <> <> <> <> <> <> <> <> <>
Date: Mon, 06 Apr 2015 12:09:26 -0400
In-Reply-To: <> (Timothy B. Terriberry's message of "Fri, 03 Apr 2015 13:44:12 -0700")
Message-ID: <>
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: <>
Cc: Ben Campbell <>, Jean-Marc Valin <>, "" <>,, "" <>, "" <>, "" <>, "" <>
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Apr 2015 16:09:38 -0000

"Timothy B. Terriberry" <> 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

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

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"?

       Derek Atkins                 617-623-3745   
       Computer and Internet Security Consultant