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

Hannes Tschofenig <> Tue, 05 November 2013 08:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61D5911E824E for <>; Tue, 5 Nov 2013 00:42:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rF5OIWnPAPOQ for <>; Tue, 5 Nov 2013 00:42:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9328721E809C for <>; Tue, 5 Nov 2013 00:42:23 -0800 (PST)
Received: from Masham-MAC.local ([]) by (mrgmx001) with ESMTPSA (Nemesis) id 0MA9Yv-1VSqZB2Iav-00BNIc for <>; Tue, 05 Nov 2013 09:42:22 +0100
Message-ID: <>
Date: Tue, 05 Nov 2013 09:42:15 +0100
From: Hannes Tschofenig <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Colin Perkins <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:RiWCMsX3TO629+08Ncqa2kEOdUgr6cn3zBANluKyrILxDLd1Y+g GdqXe3ELLUWAuPsCI0fqlu3i891Es1elPJIB7O9bT3mD3TikpOva9JOfiGsLUAxwSUOkNrW 1NxS35SyhK4/h3LL8Ly6BZU3Ci8bRD8pVMu3AcwcD67AHG49CS8XPJcoW2mtvIDryEDfdY3 doNUoguAt4B75Yc9ff1kQ==
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: Tue, 05 Nov 2013 08:42:30 -0000

Hi Colin,

I came across this document before and I was really wondering whether 
this is the best story the IETF can come up with.

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.

Have a look at TLS to see an alternative path that one could go instead. 
It mandates a certain ciphersuite and adds the following qualification:

Mandatory Cipher Suites

    In the absence of an application profile standard specifying
    otherwise, a TLS-compliant application MUST implement the cipher
    suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the

If there are deployments or standardization organizations believe that 
they do not require security (because it just runs within their own 
"secure" network* or because it requires a different solution solution, 
like the 3GPP that allows lawful intercept) then that is not a good 
reason for the IETF not mandating something.

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


(*): As we have recently learned these assumptions may well be wrong, 

Am 03.11.13 17:00, schrieb Colin Perkins:
> 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).
> Colin
>> 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
> _______________________________________________
> Audio/Video Transport Core Maintenance