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

"Roni Even" <> Sun, 03 November 2013 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6506A11E82D4 for <>; Sun, 3 Nov 2013 10:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1X9V4ovKlDWV for <>; Sun, 3 Nov 2013 10:43:42 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4008:c01::22b]) by (Postfix) with ESMTP id 4C08811E82D7 for <>; Sun, 3 Nov 2013 10:43:37 -0800 (PST)
Received: by with SMTP id mz11so2082787bkb.30 for <>; Sun, 03 Nov 2013 10:43:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=M8zhjTD1KZ8giHq7fenEY1jKGbGOeAB0J/Zz5eoAbmQ=; b=B1DX/XKW+G+jkRTZD9k0emafvoQDSVExxaz7F+iVJQn+1NCI9g54usNiWBUv+kHWDo KB9nGU5z8L3QT/NEv7n2gyz2ZicrtNvmz+9cYAX4Gnwab5ORcihmFb2a64Yt3Rh3Vjn2 MglZYthuB1FqRBSJoTmtt0YfYFtcBpO3jM1QglGS2VHXA/TzuIx8Aww6iOkMG8YREkFq LtVat7eaVT+gb1A/i+tZCCFCEU+eX1GFaUey6F8n2t5Q21tY/kFH3gOAMMt5nXCTHvNY P1rBuilEPPvASr6EPNJOuBHb+BBUMr70z9QjJBw9QJhwdnLjhl7YlT5piyO+AQopdxKR mjtg==
X-Received: by with SMTP id pb8mr7229981bkb.16.1383504217011; Sun, 03 Nov 2013 10:43:37 -0800 (PST)
Received: from RoniE ([2001:67c:370:160:7c8c:2661:ea9b:6b8b]) by with ESMTPSA id pu8sm12232470bkb.9.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Nov 2013 10:43:36 -0800 (PST)
From: "Roni Even" <>
To: "'Richard Barnes'" <>, "'Colin Perkins'" <>
References: <> <> <>
In-Reply-To: <>
Date: Sun, 3 Nov 2013 20:40:18 +0200
Message-ID: <014501ced8c4$278636e0$7692a4a0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0146_01CED8D4.EB152160"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEurJVaTP4u+XIFCgCrzt4msSXPsAJdcGJmAVQUdr2bNqJPwA==
Content-Language: en-us
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 18:43:43 -0000

Hi Richard,

I think that the purpose of the security option is as the name says to list
the options and not recommend anything leaving it to the specific deployment
like RTCweb to make recommendation. In this case if we try to recommend
order it may just cause further discussion about the order and priority
which is what we wanted to avoid in this work in the first place



From: [] On Behalf Of
Richard Barnes
Sent: 03 November, 2013 8:18 PM
To: Colin Perkins
Subject: Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and


On Sun, Nov 3, 2013 at 8:00 AM, Colin Perkins <> wrote:

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


I agree.  It helps though, to be able to say "SRTP is not always the answer
... but something in this set of things should be."


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


I agree that if you're going to make detailed recommendations, you need more
specifics.  It seems like you could provide some general guidance though.
Could we something like the following? 

-- Arrange the mechanisms in the document in an ordered list

-- "If more than one mechanism would work for your application, use the
higher-pref one"

-- Throw certain things in a NOT RECOMMENDED bucket, like ZRTP and the
legacy stuff in S3.2


Part of the advice should also be a reference to BCP 107 [1], "Guidelines
for Cryptographic Key Management".  Namely, things that provide automated
key management should be preferred over things that don't.


[1] <>







If the authors could follow up on that one point, we should be able to get
these both into LC soon.



Audio/Video Transport Core Maintenance




Colin Perkins