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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 05 November 2013 18:14 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 E301021F9B65; Tue, 5 Nov 2013 10:14:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.463
X-Spam-Level:
X-Spam-Status: No, score=-105.463 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMWBJ2XR+mr0; Tue, 5 Nov 2013 10:14:33 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 104D521F9E95; Tue, 5 Nov 2013 10:14:32 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-ba-5279358722d7
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E0.12.03802.78539725; Tue, 5 Nov 2013 19:14:31 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Tue, 5 Nov 2013 19:14:30 +0100
Message-ID: <527935DF.3070801@ericsson.com>
Date: Tue, 5 Nov 2013 10:15:59 -0800
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Colin Perkins <csp@csperkins.org>
References: <CAL02cgRRvx8puZoDRHv39Am+2oHy44iion_x77WfiqW0hEPgxw@mail.gmail.com> <C9DBB09E-139A-456C-B79B-062AAFA60502@csperkins.org> <5278AF67.1000704@gmx.net>
In-Reply-To: <5278AF67.1000704@gmx.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW67aWWQwdf/8hYve1ayWyx/eYLR YvvulWwWS3f9ZbFYuvMeq8XdSx0sFlP7bB3YPabdv8/msXjTfjaPJUt+MnlM3jiLxePL5c9s AaxRXDYpqTmZZalF+nYJXBmLjx1hLGgSqDg7iaWBsYm3i5GDQ0LARKJ/QVEXIyeQKSZx4d56 ti5GLg4hgUOMEueer2WHcJYxShy/v4UNpIpXQFvi+NvfjCA2i4CKxPYpj1hBbDYBC4mbPxrB akQFgiXOv1rMDlEvKHFy5hMWEFtEIEzi+spzrCBDmQW2Mko8+36IGeQKYYF8ibldkRDLFjBK XL/0nw0kzimgLtF2VR3iUHGJnsYgkDHMAnoSU662MELY8hLNW2czg9hCQKc1NHWwTmAUmoVk 8ywkLbOQtCxgZF7FyJ6bmJmTXm60iREY9Ae3/FbdwXjnnMghRmkOFiVx3g9vnYOEBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MGattbD39Y5bcvBdkuv0+6Gq6SxzT50wCXoUUsNbu2P20ldc Sxp/z+J4pOYf80srX8TxbtMSk759yXJfzSazb5iclirU/i98dsLe/Hlb/QyrHnNySIt6sazM 4H9z2+yv5w3VQ8bHqoXjfxx+NK+AWbH8+pnCw58Cmt/c0Xh18Ny/26xr1t3KeaHEUpyRaKjF XFScCADSFCi8SAIAAA==
Cc: perpass@ietf.org, draft-ietf-avt-srtp-not-mandatory@tools.ietf.org, avt@ietf.org, draft-ietf-avtcore-rtp-security-options@tools.ietf.org
Subject: Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options
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: Tue, 05 Nov 2013 18:14:40 -0000

On 2013-11-05 00:42, Hannes Tschofenig wrote:
> 
> The argument that RTP is used in a number of different environments, as
> a basis for not offering a solid security story is rather weak. The same
> could be said about many other protocols the IETF develops, even about
> TLS itself.
> 

I strongly disagree with that. TLS is a solution you choose to apply or
not. If your RTP application is a multicast one, then we can't do
DTLS-SRTP, because it is can't function in such an environment. Similar
observations can be made about a number of different deployment cases.


> I am wondering what motivated you write the document in this specific
> style. I believe I understand the motivation for Magnus.

My motivation for writing SRTP-not-mandatory document was as WG chair to
not have to argue with the Security ADs each time an RTP document passed
the IESG about the security sections. If you are doing an RTP extensions
you need to discuss what that implies security wise and what security
requirements it has. However, it is not the appropriate place to mandate
a particular solution and key-management.

What have been missing in IETF is to write the different "This is what
you shall do, given that your RTP application class is foo". There is
clearly a need for such a document for SIP established sessions. But I
don't volunteer to write it.

If you look at draft-ietf-mmusic-rfc2326bis, that actually normatively
require anyone supporting RTP with RTSP 2.0 to implement SRTP and MIKEY
based keying because that makes sense for RTSP.

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