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

Alan Johnston <alan.b.johnston@gmail.com> Wed, 28 August 2013 18:32 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 0080521E8054 for <avt@ietfa.amsl.com>; Wed, 28 Aug 2013 11:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pmT08A5E+rvh for <avt@ietfa.amsl.com>; Wed, 28 Aug 2013 11:32:13 -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 ED5F621E8050 for <avt@ietf.org>; Wed, 28 Aug 2013 11:32:12 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id y10so2045017wgg.3 for <avt@ietf.org>; Wed, 28 Aug 2013 11:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EQperVLgq7IyqU7Jjz3tsEtVGbdiUCNnmSYgyMOisMw=; b=I79at4gnnSzviS392Aub/Zlwr+9iAobZdHQ/yc15Xfygbi7o180BIlndVQtPySgapE Kpc0PmDF/G9IvGC2p8lAeLRyTGS/b8LgtYREbWhjC/bMXWwYqTUYTf5ODHz3iGy/GC3O q+dsKS0pwal2mgeIIrdUTSmufjLVWyYN+0qtf5o0YA374yWw24z8V29NHCdJFwJLaJGt 8svpUKKdvUw9duvrRknkWsA6M9MhqL2SvnsObml80Z8o/COEzUbLFxb5XLqifjdm+XQZ 7DVPeMLn24XH+EZqHUuNMrRWTcUWtl9jntr3J5/jfCaxYQ+kbDn2Rw2Jx8uS2yZVdzFU s/YQ==
MIME-Version: 1.0
X-Received: by with SMTP id de9mr4377937wjb.78.1377714729426; Wed, 28 Aug 2013 11:32:09 -0700 (PDT)
Received: by with HTTP; Wed, 28 Aug 2013 11:32:09 -0700 (PDT)
Date: Wed, 28 Aug 2013 13:32:09 -0500
Message-ID: <CAKhHsXGxXpjbdGk7otAqopm7ToPVf7U6X=xnAh-m2O6TdjMgRQ@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: avt@ietf.org
Content-Type: multipart/alternative; boundary="047d7bb045080ca3ad04e506354f"
Subject: [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: Wed, 28 Aug 2013 18:32:14 -0000

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.


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


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


"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?


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


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.



"it's" -> "its"


"end-points verifiable identity" -> "end-point's verifiable identity"