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

Richard Barnes <rlb@ipv.sx> Tue, 05 November 2013 17:17 UTC

Return-Path: <rlb@ipv.sx>
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 59EEC21E8137 for <avt@ietfa.amsl.com>; Tue, 5 Nov 2013 09:17:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level:
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 d4T8lcoRGZjR for <avt@ietfa.amsl.com>; Tue, 5 Nov 2013 09:17:30 -0800 (PST)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8355811E817A for <avt@ietf.org>; Tue, 5 Nov 2013 09:17:16 -0800 (PST)
Received: by mail-ob0-f181.google.com with SMTP id wp4so8700858obc.26 for <avt@ietf.org>; Tue, 05 Nov 2013 09:17:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eH6TPJrTg8WfCN2A/pALHqnHo/MtWfyeEY8QLTxKAm0=; b=GK9ToZnxkfLDfOBte1iyDhrTVd+HE6VoxLNBl0+ZQxcaeFYy3F6pzn0/660bScy6fT LNKJpFEqY6B2V4WMSccx79waako6Xh2qR1frkhx+c98cILg8vky3p3t+RRjIrcGR4FsR vD3MopRE5Mou8D54MRBy0yqiH9LVx53lmsmzUjNrJixHkO5WW2Cfrd8mmHfreZeSZOWp ZSSeqxgdSHRGBKiBVJwcsnYxDr/okGLYJL23KsCTCP5IyFEP9WQOPyMnJPKa7ZgAVIs0 r+vmEamFzRF4wx/msX/ayjJvMk27toq6JX4ZLU8E6Js4xjrhLzKd5Ns3TjH5Gvuk7Dbr IvSA==
X-Gm-Message-State: ALoCoQkVCJu6i8y9w8M4qD+6qa8tMeRd1TnLT9AnNpHnhdmfNDuLMylgUVzdAvoTIe5ImCGCfJKO
MIME-Version: 1.0
X-Received: by 10.182.227.136 with SMTP id sa8mr10680607obc.39.1383671834100; Tue, 05 Nov 2013 09:17:14 -0800 (PST)
Received: by 10.60.31.74 with HTTP; Tue, 5 Nov 2013 09:17:14 -0800 (PST)
In-Reply-To: <014501ced8c4$278636e0$7692a4a0$@gmail.com>
References: <CAL02cgRRvx8puZoDRHv39Am+2oHy44iion_x77WfiqW0hEPgxw@mail.gmail.com> <C9DBB09E-139A-456C-B79B-062AAFA60502@csperkins.org> <CAL02cgRXKvZCzdUu8Chp2J-Y1YnEoWv3A+kUNawrkHwnHq11qQ@mail.gmail.com> <014501ced8c4$278636e0$7692a4a0$@gmail.com>
Date: Tue, 5 Nov 2013 09:17:14 -0800
Message-ID: <CAL02cgSEguBA3L8qBtQ0Y=ehzJYx+9TnqYzQ63Mmz4kqoioGbA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Roni Even <ron.even.tlv@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c3035028adf904ea7134c1
Cc: draft-ietf-avtcore-rtp-security-options@tools.ietf.org, draft-ietf-avt-srtp-not-mandatory@tools.ietf.org, Colin Perkins <csp@csperkins.org>, avt@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 17:17:39 -0000

Can we seriously not come up with some general principles here?  There are
already some in the document, e.g., in the IPsec section.

-- In general, SRTP-based solutions are preferable to things that tunnel
RTP over something else, because tunnel solutions have additional
vulnerabilities.
-- In general, mechanisms that provide automated key management are
preferable to things that don't [BCP107]

And it seems like we should clearly deprecate the legacy RTP mechanism
(S3.2), and clearly indicate that new IETF protocols should use DTLS-SRTP
instead of ZRTP (in cases where both are applicable).



On Sun, Nov 3, 2013 at 10:40 AM, Roni Even <ron.even.tlv@gmail.com> wrote:

> 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
>
> Roni
>
>
>
> *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf Of *Richard
> Barnes
> *Sent:* 03 November, 2013 8:18 PM
> *To:* Colin Perkins
> *Cc:* 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
>
>
>
> On Sun, Nov 3, 2013 at 8:00 AM, Colin Perkins <csp@csperkins.org> wrote:
>
> On 2 Nov 2013, at 17:12, Richard Barnes <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".
>
>
>
> 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
> example).
>
>
>
> 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.
>
> --Richard
>
>
> [1] <http://tools.ietf.org/html/bcp107>
>
>
>
>
>
>
> 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
> https://www.ietf.org/mailman/listinfo/avt
>
>
>
>
>
> --
>
> Colin Perkins
>
> http://csperkins.org/
>
>
>
>
>
>
>
>
>