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

Colin Perkins <csp@csperkins.org> Tue, 05 November 2013 16:02 UTC

Return-Path: <csp@csperkins.org>
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 D495421E811C; Tue, 5 Nov 2013 08:02:32 -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=[AWL=0.001, 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 UoG8z5sNJnMY; Tue, 5 Nov 2013 08:02:30 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A3C11E82EE; Tue, 5 Nov 2013 08:01:52 -0800 (PST)
Received: from [207.194.238.3] (port=65530 helo=[198.18.18.248]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1Vdj4a-0007EZ-PZ; Tue, 05 Nov 2013 16:01:46 +0000
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <5278AF67.1000704@gmx.net>
Date: Tue, 5 Nov 2013 08:01:41 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CCEDF41-F28D-4F67-95B1-AE7E6765B61E@csperkins.org>
References: <CAL02cgRRvx8puZoDRHv39Am+2oHy44iion_x77WfiqW0hEPgxw@mail.gmail.com> <C9DBB09E-139A-456C-B79B-062AAFA60502@csperkins.org> <5278AF67.1000704@gmx.net>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1510)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: perpass@ietf.org, draft-ietf-avt-srtp-not-mandatory@tools.ietf.org, avt@ietf.org, draft-ietf-avtcore-rtp-security-options@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 16:02:33 -0000

Hannes,

The goal of the draft is not to justify a lack of strong security. It is to explain why SRTP is not an appropriate mechanism for providing strong security for all use cases of RTP, and highlight that some scenarios need alternative strong security mechanisms. The rtp-security-options draft talks about what those options might be. If there are sections in the draft that don't make that clear, please let me know, and we can try to improve the text. 

The draft says nothing about the cipher suites to be used. Both SRTP and the other security options mandate strong cipher suites, and there are no proposals to change that.

Colin


On 5 Nov 2013, at 00:42, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
> 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
>> 
> 



-- 
Colin Perkins
http://csperkins.org/