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 > ---------------------------------------------------------------------- >
- [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-man… internet-drafts
- Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not… Colin Perkins
- Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not… Harald Alvestrand
- Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not… Magnus Westerlund
- Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not… Harald Alvestrand
- Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not… David McGrew (mcgrew)
- Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not… Hannes Tschofenig