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

"Derek Atkins" <> Wed, 08 April 2015 19:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 685081B3564; Wed, 8 Apr 2015 12:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w5YSvfGtpH3Q; Wed, 8 Apr 2015 12:38:19 -0700 (PDT)
Received: from ( [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12F2A1B3554; Wed, 8 Apr 2015 12:38:19 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 859F6E2036; Wed, 8 Apr 2015 15:38:17 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 11189-08; Wed, 8 Apr 2015 15:38:13 -0400 (EDT)
Received: by (Postfix, from userid 48) id 0CFA3E2038; Wed, 8 Apr 2015 15:38:13 -0400 (EDT)
Received: from (SquirrelMail authenticated user warlord) by with HTTP; Wed, 8 Apr 2015 15:38:13 -0400
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <035501d0711a$7856b0a0$690411e0$> <> <> <> <> <> <> <> <>
Date: Wed, 8 Apr 2015 15:38:13 -0400
From: "Derek Atkins" <>
To: "Ben Campbell" <>
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <>
Cc: "" <>,,, Kathleen Moriarty <>, "" <>,,, Colin Perkins <>
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: Wed, 08 Apr 2015 19:38:21 -0000


On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote:
> 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...

It's technically not a downref because the referred documents are guidance
and not protocols.  So I don't think there would be any issue.  There is
already precedent for that.

> 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.

I'll point out, again, that the original draft *already did this*, so you
should be talking to the working group about that and not to me.  From
where I sit, I saw the "MAY encrypt" and said "please change that from MAY
to SHOULD."  That's where this all started.

Now, you could say (possibly even correctly -- I wont make that judgement
call) that the WG made a mistake putting that sentence into the Security
Considerations at all in the first place, but they did.  Clearly the WG
decided it was worthwhile to mention that; I'm just suggesting to make the
mention stronger than what was there in -08.

> 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.

Are you willing to hold up this document until that work is done so it can
refer to the (yet-to-be-written) protocol security update draft?  I'm fine
with that approach and I'm willing to review whatever draft you guys
produce if that's how you'd like to proceed.

Or you can hold your nose and live with the "UGGH" of it based on what the
WG original created in -08 and move forward for now, knowing that you can
(and should) correct it "right" later.

I have no skin in that decision :)

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