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

Richard Barnes <rlb@ipv.sx> Sun, 03 November 2013 18:18 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 C537B11E82CD for <avt@ietfa.amsl.com>; Sun, 3 Nov 2013 10:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.884
X-Spam-Level:
X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, 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 3cQuavJ7Oz+G for <avt@ietfa.amsl.com>; Sun, 3 Nov 2013 10:18:11 -0800 (PST)
Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9894C11E821E for <avt@ietf.org>; Sun, 3 Nov 2013 10:18:09 -0800 (PST)
Received: by mail-oa0-f54.google.com with SMTP id o20so6371862oag.41 for <avt@ietf.org>; Sun, 03 Nov 2013 10:18:09 -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=tYBdHyR8EpEuu+btApOIOKxMzkyKQFYlzYjSkmar0+c=; b=MSxBtcQwt8FgQni6/3egAmdWvJAzARxYAaLCa7kgLvVW3DK5RS7167YUojbkgRUyXy pmDVDQY2czEJqbE6HGD5N8UUJyjQGDOf2Vs8V3YNoDPtcU7OIzGpHBLfxQ14ciK1NwvI 65x8gv2Y/hF958FgQwz8c/nW+atCJq7XJnPfwOCcg4euJ4ZWcS1ghY/3V5SiimvcPQjO c3Jsol3WV/TUUO9kD4bOQ426otUXWBk5NO7TGxS3WRFNnc+yWOiZKSeC8738nj8XRWNm KP96pgrOWWdkLjbIM4WnVxeXUarjlnYcSroP2IZltiw8s6VGuaWN37wqp6oFvygtjN3q HWCg==
X-Gm-Message-State: ALoCoQnobiYrNITj97pJTfTw+jisDgsyhAWrWgxBmdpb5rtqF2eljhNdleT+qiWssOGVep41jrOt
MIME-Version: 1.0
X-Received: by 10.182.101.134 with SMTP id fg6mr10884352obb.30.1383502689048; Sun, 03 Nov 2013 10:18:09 -0800 (PST)
Received: by 10.60.31.74 with HTTP; Sun, 3 Nov 2013 10:18:08 -0800 (PST)
In-Reply-To: <C9DBB09E-139A-456C-B79B-062AAFA60502@csperkins.org>
References: <CAL02cgRRvx8puZoDRHv39Am+2oHy44iion_x77WfiqW0hEPgxw@mail.gmail.com> <C9DBB09E-139A-456C-B79B-062AAFA60502@csperkins.org>
Date: Sun, 3 Nov 2013 10:18:08 -0800
Message-ID: <CAL02cgRXKvZCzdUu8Chp2J-Y1YnEoWv3A+kUNawrkHwnHq11qQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Colin Perkins <csp@csperkins.org>
Content-Type: multipart/alternative; boundary=e89a8ff250e053ab7f04ea49d2cd
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
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: Sun, 03 Nov 2013 18:18:19 -0000

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/
>
>
>
>