Re: [AVTCORE] Review of draft-ietf-avtcore-rtp-security-options-04

Alan Johnston <alan.b.johnston@gmail.com> Thu, 29 August 2013 13:48 UTC

Return-Path: <alan.b.johnston@gmail.com>
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 3733E21F9E83 for <avt@ietfa.amsl.com>; Thu, 29 Aug 2013 06:48:02 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 79-z2isxoS6e for <avt@ietfa.amsl.com>; Thu, 29 Aug 2013 06:48:01 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id CF52221F9E44 for <avt@ietf.org>; Thu, 29 Aug 2013 06:48:00 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id c11so435439wgh.27 for <avt@ietf.org>; Thu, 29 Aug 2013 06:47:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qUHeSOzs2SNfHAcvyRoGSx0zr4jTQssVtk5IuMVQz+U=; b=LlFwg+1yGairZcTlFqZ7VSz63Y9tKsI66HnN7WaIBWzLOeczBEyGHWz3vCOCPCNIWE WdMZxaPRt2ZRKOZ9SX3RSU+ppXdRxA6YaUFpxm1BaIpGWUqTI4wcp6r1A8miyYy7Qn9l x/yov3gBUQP2XfQjVcUNaGMQ/vfwFrFMq/S9hPLoy6KICaQKtyQxKLql7uEVGGW166yY iTkLdy0Nwnxxu3jqIo/f//jBfMJGXW8ldRRWZoIP5SO8J2JNcXgkkCpCwFFSqTByUXZ2 SjEnNkSJZQvxclAXf5xoQ1lrzNvzmndAegPpNWgKZZdpvXDgLct1Ve15ykhwNNNwimO4 lrHQ==
MIME-Version: 1.0
X-Received: by 10.180.77.163 with SMTP id t3mr87310wiw.24.1377784077422; Thu, 29 Aug 2013 06:47:57 -0700 (PDT)
Received: by 10.216.93.4 with HTTP; Thu, 29 Aug 2013 06:47:57 -0700 (PDT)
In-Reply-To: <A165299B-ECF8-42A9-A427-38B1283132C2@csperkins.org>
References: <CAKhHsXGxXpjbdGk7otAqopm7ToPVf7U6X=xnAh-m2O6TdjMgRQ@mail.gmail.com> <A165299B-ECF8-42A9-A427-38B1283132C2@csperkins.org>
Date: Thu, 29 Aug 2013 08:47:57 -0500
Message-ID: <CAKhHsXGytyA9v-F6B6Gj8qVxNPH7i8e1QvU+cn-71T2qjqhGoA@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: Colin Perkins <csp@csperkins.org>
Content-Type: multipart/alternative; boundary=f46d043bdfde83189104e5165a7c
Cc: avt@ietf.org
Subject: Re: [AVTCORE] Review of draft-ietf-avtcore-rtp-security-options-04
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: Thu, 29 Aug 2013 13:48:02 -0000

Colin,

Thanks for making the changes.  A few comments below.

- Alan -


On Thu, Aug 29, 2013 at 7:57 AM, Colin Perkins <csp@csperkins.org> wrote:

> Alan,
>
> Thank you for the review. Some comments inline.
>
> Cheers,
> Colin
>
>
>
> On 28 Aug 2013, at 19:32, Alan Johnston <alan.b.johnston@gmail.com> wrote:
> > Here's my review of draft-ietf-avtcore-rtp-security-options-04.
> >
> > Summary:  The document is well-written and useful.  There are a few
> technical issues to resolve but is otherwise ready to progress.
> >
> > - Alan -
> >
> > Numbers refer to sections in the document.
> >
> > 3.1.1:
> >
> > It is surprising no mention is made of RFC 4474 in this section (or in
> the whole document) as DTLS-SRTP keying relies on an integrity protected
> signaling channel provided by RFC 4474.  When mentioning RFC 4474, it needs
> to be pointed out that RFC 4474 is effectively being deprecated by the STIR
> work and has proved to be undeployable and also ineffective for E.164
> identities.
>
> I have added a reference to RFC 4474 in Sections 4.1.3 and 4.1.4 as a
> result of Dan Wing's comments. I'm not familiar with the STIR work, or the
> other issues, can you suggest text for Section 3.1.1?
>

Here's the proposed charter for STIR:
http://datatracker.ietf.org/wg/stir/charter/

draft-jennings-dispatch-rfc4474bis discusses the problems with RFC 4474 and
some proposed changes.

I would suggest text in this section mention that DTLS-SRTP relies on an
integrity protected signaling channel based on RFC 4474, but that there is
proposed underway in the IETF to try to make this workable.


>
> > 3.1.5:
> >
> > Might be worth a single sentence about what makes ZRTP unique, such as:
> >  "ZRTP provides best effort encryption independent of the signaling
> > protocol and utilizes key continuity, Short Authentication Strings, or a
> PKI for authentication."
>
> Done.
>
> > 5.1:
> >
> > "There also exists a solution that enables the fingerprints to be bound
> to identities established by the first proxy for each user [RFC4916]."  I
> don't see how SIP connected identity relates at all to this.  Is this
> perhaps meant to reference RFC 4474?
>
> Yes, I think so.
>
> > 5.2:
> >
> > "But, unless the application and its server is intending to compromise
> the communication security, they can provide a secure and
> integrity-protected exchange of the certificate hashes thus preventing any
> man-in-the-middle (MITM) from inserting itself in the key-exchange."  This
> is possible, but not trivial, and I doubt few WebRTC signaling channels
> will provide this. This statement needs some support for it to be included.
>
> Dan Wing had comments on that section also, and it's been rewritten in the
> -05 version of the draft. That specific text has been removed, but that's
> not the only change, and I'd appreciate review to see if the new text makes
> sense.
>

I will look it over when -05 is out.



>
> > 5.2:
> >
> > Might also be worth a mention that ZRTP can be used to verify the
> > DTLS-SRTP fingerprints used without relying on any third parties as
> > described in draft-johnston-rtcweb-zrtp.
>
> I added a mention of ZRTP here.
>
> > Nits:
> >
> > 2:
> >
> > "it's" -> "its"
> >
> > 2.1:
> >
> > "end-points verifiable identity" -> "end-point's verifiable identity"
>
> Fixed.
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
>