Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.txt

Harald Alvestrand <harald@alvestrand.no> Mon, 26 November 2012 08:49 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205CC21F8482 for <avt@ietfa.amsl.com>; Mon, 26 Nov 2012 00:49:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqpStXZWoY7N for <avt@ietfa.amsl.com>; Mon, 26 Nov 2012 00:49:30 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6B31721F855D for <avt@ietf.org>; Mon, 26 Nov 2012 00:49:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3231A39E13F; Mon, 26 Nov 2012 09:49:26 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIrBhAj04PRi; Mon, 26 Nov 2012 09:49:25 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 08CE039E01E; Mon, 26 Nov 2012 09:49:24 +0100 (CET)
Message-ID: <50B32D14.2030409@alvestrand.no>
Date: Mon, 26 Nov 2012 09:49:24 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <20121119225137.6740.64413.idtracker@ietfa.amsl.com> <5119018B-F424-4F1A-AE37-8840169E499C@csperkins.org> <50B15C45.8050600@alvestrand.no> <50B32362.6090005@ericsson.com>
In-Reply-To: <50B32362.6090005@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: avt@ietf.org
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Nov 2012 08:49:31 -0000

On 11/26/2012 09:08 AM, Magnus Westerlund wrote:
> Hi Harald,
>
>
> On 2012-11-25 00:46, Harald Alvestrand wrote:
>> On 11/19/2012 11:59 PM, Colin Perkins wrote:
>> One thing I did not understand about the new section 6 ....
>> It describes RTP/AVPF as a profile that is an example of where a single
>> security mechanism is not reasonable to mandate, because it's used in
>> many other contexts.
>> I think that's OK - but isn't it true that RTP/AVPF *disallows* the use
>> of SRTP, since it would then be RTP/SAVPF?
>>
>> This can be confusing to the reader - it may be clearer if one mentions
>> explicitly that the RTP/AVPF, which is a set of building blocks that
>> don't need a security mandate, is used to build RTP/SAVPF, which *is* a
>> security mandate.
>>
>> Or am I the one confused?
> I guess you are getting tripped up on this sentence:
>
>     In other cases, though,
>     an RTP profile is applicable to such a wide range of applications
>     that it would not make sense for that profile to mandate particular
>     security building blocks be used (the RTP/AVPF profile [RFC4585] is
>     an example of this type of RTP profile, since it provides building
>     blocks that can be used in different styles of application).
>
> This is an example why RTP profiles, independent of which profile it may
> be is not the appropriate level of putting in the mandatory to implement
> security solution alternative. And frankly SAVPF and SAVP is only half a
> security mandate, they lack key-management and without a mandatory to
> implement key-management solution they do not specify a MTI security
> solution.
Yes, my opinion of the usefulness of the RTP "profile" field is 
sometimes acerbic.
SAVP(F) mandates use of SRTP, but that gets you only some of the way.
>
> And if I count correctly in draft-ietf-avtcore-rtp-security-options
> there are at least 11 options for keying SRTP.
Sigh.
>
> Cheers
>
> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>