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

John Mattsson <> Thu, 07 November 2013 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 984C411E81E2 for <>; Thu, 7 Nov 2013 07:31:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.497
X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[AWL=-1.898, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cHaW9jW24Wii for <>; Thu, 7 Nov 2013 07:31:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 07DBB11E81B6 for <>; Thu, 7 Nov 2013 07:31:44 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-f0-527bb25cbba7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id CC.70.27941.C52BB725; Thu, 7 Nov 2013 16:31:40 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Thu, 7 Nov 2013 16:31:35 +0100
From: John Mattsson <>
To: "" <>
Thread-Topic: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options
Thread-Index: Ac7bzkH82eR3cm0pS/uMxvnCaIwmCw==
Date: Thu, 7 Nov 2013 15:31:35 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+JvjW7Mpuogg8UnLSxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs9JmQU31So2TJjD1MA4Ub6LkZNDQsBEov/cfEYIW0ziwr31 bF2MXBxCAkcYJVbMncAK4SxilJh49jo7SBWbgIHE3D0NbCC2iICiROu1z2DdwgKFEseW32CH iBdJLO+8yAxh60n862kDq2cRUJFYN/8EC4jNK+At8XLaWVYQmxFo8/dTa5hAbGYBcYlbT+Yz QVwkILFkz3lmCFtU4uXjf6wQtpJE45InrBD1ehI3pk5hg7C1JZYtfM0MMV9Q4uTMJywTGIVn IRk7C0nLLCQts5C0LGBkWcXIUZxanJSbbmSwiREYyAe3/LbYwXj5r80hRmkOFiVx3o9vnYOE BNITS1KzU1MLUovii0pzUosPMTJxcEo1MPY3plwzPfD/3eUpcZmHT3z5+F3u1nz/7vXzPc3M rm18l7g29FrS0/hKL/Nnxi+1dV62iTSzGQrOL24s2nm2YV5Q6o/64Ei/aywJClMfeMfxTdff 99b880pXnmfyb1es617OLaDK5GE2oXf1l91fD4nsP/7IOnbfx/J1zr5z/HbOb/TO/P8hapcS S3FGoqEWc1FxIgDtBA+2MgIAAA==
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 15:31:52 -0000

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

>For ZRTP what are your grounds for issuing the NOT RECOMMENDED. I think 
>we accurately describes its status.

Regarding the security aspects, I am not aware of any known weaknesses in ZRTP. In fact, if used in a scenario without prior e2e shared cryptographic secrets (which is probably the most common use case for both ZRTP and DTLS-SRTP) then ZRTP provides e2e authentication by using SAS, while DTLS-SRTP in this scenario only provides opportunistic encryption.


-----Original Message-----
From: [] On Behalf Of Magnus Westerlund
Sent: den 7 november 2013 04:14
To: Richard Barnes; Colin Perkins
Subject: Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options

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

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:

Audio/Video Transport Core Maintenance