Re: [AVTCORE] Last Call: <draft-ietf-avt-srtp-not-mandatory-14.txt> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution) to Informational RFC

"Roni Even" <ron.even.tlv@gmail.com> Thu, 05 December 2013 23:15 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECF71AE17E; Thu, 5 Dec 2013 15:15:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBxU2k6uyx6x; Thu, 5 Dec 2013 15:15:47 -0800 (PST)
Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 725A31AE11D; Thu, 5 Dec 2013 15:15:46 -0800 (PST)
Received: by mail-ee0-f49.google.com with SMTP id c41so3511540eek.36 for <multiple recipients>; Thu, 05 Dec 2013 15:15:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=aoL6pzHBKmts58ZYsFGuHg8uXO85fu6Ee+eO+5d6zGQ=; b=nPfHKmIw0Xho6WXLj+uLfJrqc5gmIM9SfQUVi3kQGOqVCuv+QGz1ZI6jfpWcmHApkg sJrQQoibdV7xXMDWfSJDpiRoL8CntqLKDiLsExdN9+OFFGtItnMQmhSd2f/1gkjoyn0a cYxwg9Hn+QCQbFyXoyPgOQnJ626h+OQFaH62hX0bbN3hHgYqVF1jRN7ROyk5dBJnOJHQ Il/XhzDETcAQ2r9V7t2YmfS8gGWLzi+xfQMVc56lp0rfAYHizi0cHNjvL0ph2oaKlz/D KWwzSOwQ+Oylw6xF0/TlnOHRerUnWFHjyWFMjtmHpumvx6jJz/iefjohNKUy5hREk+xz ZjKQ==
X-Received: by 10.14.69.200 with SMTP id n48mr226736eed.54.1386285342568; Thu, 05 Dec 2013 15:15:42 -0800 (PST)
Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id h48sm110892169eev.3.2013.12.05.15.15.38 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Dec 2013 15:15:41 -0800 (PST)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Cullen Jennings \(fluffy\)'" <fluffy@cisco.com>, <ietf@ietf.org>
References: <20131122220752.31098.83432.idtracker@ietfa.amsl.com> <1286562B-6C43-4ADC-8999-C70CA356F587@cisco.com>
In-Reply-To: <1286562B-6C43-4ADC-8999-C70CA356F587@cisco.com>
Date: Fri, 6 Dec 2013 01:12:10 +0200
Message-ID: <017801cef20f$6f82aff0$4e880fd0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIN2m3x3ejERQ3kSYuKg2EXPhgFzwOCOPRCmaxWjAA=
Content-Language: en-us
Cc: avt@ietf.org
Subject: Re: [AVTCORE] Last Call: <draft-ietf-avt-srtp-not-mandatory-14.txt> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution) to Informational RFC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Dec 2013 23:15:50 -0000

Cullen,
Let's say hypothetically that the AVTcore WG will propose and get consensus
that for RTCweb usage the security mechanism MUST use SDES for key exchange,
do you see this as a binding recommendation for RTCweb? The selection was
done by RTCweb and not by AVTcore.

The document does not say that there should be no security but says that it
is up to the usage or a for a decision. The security option document provide
the information about the different security options available and where
they are used.

Roni Even

> -----Original Message-----
> From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Cullen Jennings
(fluffy)
> Sent: 05 December, 2013 6:57 PM
> To: ietf@ietf.org
> Cc: avt@ietf.org WG
> Subject: Re: [AVTCORE] Last Call:
<draft-ietf-avt-srtp-not-mandatory-14.txt>
> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single
> Media Security Solution) to Informational RFC
> 
> 
> Given the hum in the IETF plenary at the last IETF, I no longer think this
> document represents IETF consensus. Given the hum in RTCWeb working group,
> I doubt this represents the consensus of the RAI area either.
> 
> I think I would be tempted to resolve this by saying for each different
scenario
> RTP is used in (SIP, RTSP, Mulitcast etc) exactly how it needs to be
secured and
> for scenarios not listed such as new usages, what the requirements are.
For
> something like SIP, having just one way to secure RTP is much better than
> having many ways.
> 
> 
> 
> On Nov 22, 2013, at 3:07 PM, The IESG <iesg-secretary@ietf.org> wrote:
> 
> >
> > The IESG has received a request from the Audio/Video Transport Core
> > Maintenance WG (avtcore) to consider the following document:
> > - 'Securing the RTP Protocol Framework: Why RTP Does Not Mandate a
Single
> >   Media Security Solution'
> >  <draft-ietf-avt-srtp-not-mandatory-14.txt> as Informational RFC
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action. Please send substantive comments to the
> > ietf@ietf.org mailing lists by 2013-12-06. Exceptionally, comments may
> > be sent to iesg@ietf.org instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >   This memo discusses the problem of securing real-time multimedia
> >   sessions, and explains why the Real-time Transport Protocol (RTP),
> >   and the associated RTP Control Protocol (RTCP), do not mandate a
> >   single media security mechanism.  Guidelines for designers and
> >   reviewers of future RTP extensions are provided, to ensure that
> >   appropriate security mechanisms are mandated, and that any such
> >   mechanisms are specified in a manner that conforms with the RTP
> >   architecture.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/ball
> > ot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt