Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options

Magnus Westerlund <> Thu, 07 November 2013 03:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8061321E8131 for <>; Wed, 6 Nov 2013 19:13:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.541
X-Spam-Status: No, score=-105.541 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EyOq+HQKXc21 for <>; Wed, 6 Nov 2013 19:12:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6F43D21E81CA for <>; Wed, 6 Nov 2013 19:12:09 -0800 (PST)
X-AuditID: c1b4fb30-b7eff8e000006d14-77-527b0507966b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 41.D9.27924.7050B725; Thu, 7 Nov 2013 04:12:07 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.328.9; Thu, 7 Nov 2013 04:12:06 +0100
Message-ID: <>
Date: Wed, 6 Nov 2013 19:13:43 -0800
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Richard Barnes <>, Colin Perkins <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+JvjS47a3WQQe8FPYuXPSvZLZa/PMFo sX33SjaLpbv+slhM7bN1YPWYdv8+m8eSJT+ZPCZvnMXi8eXyZ7YAligum5TUnMyy1CJ9uwSu jPnXvjAW/JCpaJrbz9jAeFusi5GDQ0LARGJ2R1wXIyeQKSZx4d56ti5GLg4hgUOMEu8unWCB cJYxSvRfPMQEUsUroC1xav9rZhCbRUBFYvvRZ6wgNpuAhcTNH41sILaoQLDE+VeL2SHqBSVO znzCAmKLCDhJdD3vZQQZyizQBDT0ah87yBXCAvkSc7siIZadYpTY+HAx2FBOgUCJq09+sEFc Ki7R0xgEEmYW0JOYcrWFEcKWl2jeOhvsHiGg2xqaOlgnMArNQrJ6FpKWWUhaFjAyr2Jkz03M zEkvN9/ECAztg1t+G+xg3HRf7BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4 pRoY41fdl+8tatM7tNPhzaoZOV3BpeFXjSpiTh0u0Zvzb0NKqGxGldzN3ckfdW8f4GFZE5j+ c3LEWZ7tzy9Nmv12ycaaf3WHJOW35mqrsmtd3p116F/rV6PrcoLyBiEGy87+PPXunAbPjqii 2wlxRrFZGzk0JgbfWblk9+5bphGx73/ukju01Df2uhJLcUaioRZzUXEiAC/X39k7AgAA
Subject: Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Nov 2013 03:13:23 -0000

Richard and WG,

See inline

On 2013-11-03 10:18, Richard Barnes wrote:
> On Sun, Nov 3, 2013 at 8:00 AM, Colin Perkins <
> <>> wrote:
>     Note that the srtp-not-mandatory draft is explicitly not saying
>     "strong security is not mandatory", rather it's saying that "strong
>     security is mandatory, but the appropriate way of providing it
>     depends on the context, and SRTP is not always the answer".
> I agree.  It helps though, to be able to say "SRTP is not always the
> answer ... but something in this set of things should be."

I think you need to say, hopefully something in this set should be. It
is not certain that we actually have the security mechanism required for
a particular application context.

>>     On draft-ietf-avtcore-rtp-security-options:
>>     I have reviewed this draft in preparation for IETF Last Call and
>>     IESG processing.  One question to discuss briefly before IETF LC: 
>>     My major concern is that it seems like there's a lot of old stuff
>>     in here.  Has the WG considered explicitly marking each of the
>>     mechanisms with some sort of recommendation level?  I would like
>>     to avoid having someone choose SDES in a case where they could use
>>     DTLS-SRTP, for example.
>     Such recommendations would be very helpful, but depend on the
>     scenario. Section 5 gives some pointers, but really we need security
>     architecture drafts for particular use cases of RTP (like the WebRTC
>     security arch, for example).
> I agree that if you're going to make detailed recommendations, you need
> more specifics.  It seems like you could provide some general guidance
> though.  Could we something like the following?

First of all this is an informational document, it was not written as a
recommendation document. It is a survey with some general guidelines.

> -- Arrange the mechanisms in the document in an ordered list

According to which application context should that list be arranged for?

> -- "If more than one mechanism would work for your application, use the
> higher-pref one"

The issue is that one mechanism is more suitable in the context of
multicast but, maybe another is more suitable in another application
context. And there are relative ordering will vary.

> -- Throw certain things in a NOT RECOMMENDED bucket, like ZRTP and the
> legacy stuff in S3.2

Section 3.2 says:

   method can provide confidentiality but, as discussed in Section 9 of
   [RFC3550], it has extremely weak security properties and is not to be

Isn't this clear enough? I don't want to use RFC 2119 language in an
Informational document that is a description, and not a recommendation

For ZRTP what are your grounds for issuing the NOT RECOMMENDED. I think
we accurately describes its status.
> Part of the advice should also be a reference to BCP 107 [1],
> "Guidelines for Cryptographic Key Management".  Namely, things that
> provide automated key management should be preferred over things that don't.

Yes, this we can add to section 4. Securing RTP Applications.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: