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

Bernard Aboba <> Fri, 06 December 2013 15:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CA9EC1ADA5D; Fri, 6 Dec 2013 07:30:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RpmhG07AxGsL; Fri, 6 Dec 2013 07:30:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0562F1AC863; Fri, 6 Dec 2013 07:30:44 -0800 (PST)
Received: from BLU169-W109 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Dec 2013 07:30:41 -0800
X-TMN: [qA/OrMoukjn2OkIYLy57eRgwo6V1fS9T]
X-Originating-Email: []
Message-ID: <BLU169-W109A0CACEE0605DA8F317F893D60@phx.gbl>
Content-Type: multipart/alternative; boundary="_1aaffa13-2edb-403f-975a-771f5ef3d1f3_"
From: Bernard Aboba <>
To: Colin Perkins <>, Cullen Jennings <>
Date: Fri, 6 Dec 2013 07:30:40 -0800
Importance: Normal
In-Reply-To: <>
References: <>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Dec 2013 15:30:41.0010 (UTC) FILETIME=[1F0B2D20:01CEF298]
Cc: "" <>, " 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
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Dec 2013 15:30:47 -0000

Colin said: 
> I'm confused about your objection, since this draft states that we need to do exactly as you propose. 

[BA] I agree with Colin.  The document is consistent with the Danvers Doctrine and more recently expressed sentiments. 
>From Section 6: 
   Given the variability of the classes of application that use
   RTP, and the variety of the currently available security mechanisms
   described in [I-D.ietf-avtcore-rtp-security-options], no one set of
   MTI security options can realistically be specified that apply to all
   classes of RTP applications.

   Documents that define an interoperable class of applications using
   RTP are subject to [RFC3365], and so need to specify MTI security
   mechanisms.  This is because such specifications do fully specify
   interoperable applications that use RTP.  Examples of such documents
   under development in the IETF at the time of this writing are the
   RTCWEB Security Architecture [I-D.ietf-rtcweb-security-arch] and the
   Real Time Streaming Protocol 2.0 (RTSP) [I-D.ietf-mmusic-rfc2326bis].
   It is also expected that a similar document will be produced for
   voice-over-IP applications using SIP and RTP.