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

Colin Perkins <csp@csperkins.org> Thu, 29 August 2013 12:58 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 5D42911E80F5 for <avt@ietfa.amsl.com>; Thu, 29 Aug 2013 05:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 EWgmoCXI80xu for <avt@ietfa.amsl.com>; Thu, 29 Aug 2013 05:57:55 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3C88A21F9CA8 for <avt@ietf.org>; Thu, 29 Aug 2013 05:57:55 -0700 (PDT)
Received: from [130.209.247.112] (port=54494 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1VF1n3-0000PN-VI; Thu, 29 Aug 2013 13:57:34 +0100
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CAKhHsXGxXpjbdGk7otAqopm7ToPVf7U6X=xnAh-m2O6TdjMgRQ@mail.gmail.com>
Date: Thu, 29 Aug 2013 13:57:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A165299B-ECF8-42A9-A427-38B1283132C2@csperkins.org>
References: <CAKhHsXGxXpjbdGk7otAqopm7ToPVf7U6X=xnAh-m2O6TdjMgRQ@mail.gmail.com>
To: Alan Johnston <alan.b.johnston@gmail.com>
X-Mailer: Apple Mail (2.1508)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
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 12:58:26 -0000

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?

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

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