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

Colin Perkins <> Sun, 03 November 2013 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C6DA11E813F for <>; Sun, 3 Nov 2013 08:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g-C4xP5n+iSb for <>; Sun, 3 Nov 2013 08:01:06 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) by (Postfix) with ESMTP id BA0B111E82B0 for <>; Sun, 3 Nov 2013 08:01:04 -0800 (PST)
Received: from [] (port=59500 helo=[]) by with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Vd06m-0005uC-Qp; Sun, 03 Nov 2013 16:01:02 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_992C7D9F-81BF-4B02-B89F-6F874088521B"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Sun, 3 Nov 2013 08:00:57 -0800
Message-Id: <>
References: <>
To: Richard Barnes <>
X-Mailer: Apple Mail (2.1510)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Subject: Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Nov 2013 16:01:07 -0000

On 2 Nov 2013, at 17:12, Richard Barnes <> wrote:
> On draft-ietf-avt-srtp-not-mandatory:
> I have reviewed this draft in preparation for IETF Last Call and IESG processing.  Clearly, this is not the best moment in history to be making this sort of argument, given the increased focus on .  However, I think this document makes the case pretty clearly.  It helps to have draft-ietf-avtcore-rtp-security-options as a positive statement to go alongside this document.

Note that the srtp-not-mandatory draft is explicitly not saying "strong security is not mandatory", rather it's saying that "strong security is mandatory, but the appropriate way of providing it depends on the context, and SRTP is not always the answer".

> On draft-ietf-avtcore-rtp-security-options:
> I have reviewed this draft in preparation for IETF Last Call and IESG processing.  One question to discuss briefly before IETF LC:  My major concern is that it seems like there's a lot of old stuff in here.  Has the WG considered explicitly marking each of the mechanisms with some sort of recommendation level?  I would like to avoid having someone choose SDES in a case where they could use DTLS-SRTP, for example.

Such recommendations would be very helpful, but depend on the scenario. Section 5 gives some pointers, but really we need security architecture drafts for particular use cases of RTP (like the WebRTC security arch, for example).


> If the authors could follow up on that one point, we should be able to get these both into LC soon.
> Thanks,
> --Richard
> _______________________________________________
> Audio/Video Transport Core Maintenance

Colin Perkins