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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 05 November 2013 08:42 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D5911E824E for <avt@ietfa.amsl.com>; Tue, 5 Nov 2013 00:42:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF5OIWnPAPOQ for <avt@ietfa.amsl.com>; Tue, 5 Nov 2013 00:42:25 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9328721E809C for <avt@ietf.org>; Tue, 5 Nov 2013 00:42:23 -0800 (PST)
Received: from Masham-MAC.local ([91.179.228.44]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MA9Yv-1VSqZB2Iav-00BNIc for <avt@ietf.org>; Tue, 05 Nov 2013 09:42:22 +0100
Message-ID: <5278AF67.1000704@gmx.net>
Date: Tue, 05 Nov 2013 09:42:15 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
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 <csp@csperkins.org>
References: <CAL02cgRRvx8puZoDRHv39Am+2oHy44iion_x77WfiqW0hEPgxw@mail.gmail.com> <C9DBB09E-139A-456C-B79B-062AAFA60502@csperkins.org>
In-Reply-To: <C9DBB09E-139A-456C-B79B-062AAFA60502@csperkins.org>
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==
Cc: draft-ietf-avtcore-rtp-security-options@tools.ietf.org, perpass@ietf.org, avt@ietf.org, draft-ietf-avt-srtp-not-mandatory@tools.ietf.org
Subject: Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
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: 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
    definition).
"

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.

Ciao
Hannes

(*): As we have recently learned these assumptions may well be wrong, 
see: 
http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html 


Am 03.11.13 17:00, schrieb Colin Perkins:
> On 2 Nov 2013, at 17:12, Richard Barnes <rlb@ipv.sx <mailto:rlb@ipv.sx>>
> 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
>> avt@ietf.org <mailto:avt@ietf.org>
>> https://www.ietf.org/mailman/listinfo/avt
>
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>