[secdir] Security Review of draft-ietf-rtcweb-use-cases-and-requirements-14
Ben Laurie <benl@google.com> Fri, 16 May 2014 10:46 UTC
Return-Path: <benl@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A241A0217 for <secdir@ietfa.amsl.com>; Fri, 16 May 2014 03:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG_2K2UI5S0h for <secdir@ietfa.amsl.com>; Fri, 16 May 2014 03:46:35 -0700 (PDT)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40F31A0216 for <secdir@ietf.org>; Fri, 16 May 2014 03:46:33 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id lf12so5924989vcb.15 for <secdir@ietf.org>; Fri, 16 May 2014 03:46:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5GMDom9RKtOeWDQHXi1z3p8V8M3fJ7mhIERBi1ukJr4=; b=bnSgQcomk5YQVtLgtaoofczRC4/oynctHleDi2DFnZ2Xz4tKU1T8jpVTQE9ZE/OWBA 2ro1S7yY7sE4CIE9uiY9gjZpP6yhGNix653YDFElGNn1w2Vyhv5xRGYuhkjoHPHsbvYe GMwU2y05jhXb3TX/fkLYMTEZG+5UztWWN+6eCFBWAW7yxrc1q3MK1afiMC7JGRop3Cvt TzjCaoCPpeJ3NN+iAMvQvdS1+8w7PJHUA8nPDl9Nodj8tbDUxJxzfYdiXkYpjC/m6rcq SYGfyTBNP8SSneqC7lc9PZ4n9gPQxa2kAtnhRoZjxsWHrnLBvvwDmaArQ/HYm0GF6uRH 5Fqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=5GMDom9RKtOeWDQHXi1z3p8V8M3fJ7mhIERBi1ukJr4=; b=Htym0Jik8maLPVsfHGh6GdHV07/iALB0CQ57+Xhbjh9EUx5yUoTbxrSsIMgERWvVsM yCoz9f7y9ZLMGtgdInZZjUE2tBu0YDNxtUbAr7LN2l181zczfzRbE3y4hulpm365Quyv 42SDzrmPh6oKIVqCdgm85AO6H5UW6krVGFRjNj5MhS0sX8DRH/VSy/DkerPmkGIH+Yiv TX2eqmCC65TQ3w50z7BzuJXxKVqCDlf+milpPIG6cPQmDrNu/mrCUS49DqkUNOmcTQaR VxfdH2tGPgPZ3F7ljjNvlKniDPUdiYPiFzhL7Fuk3on75bysDNFCcBlk0nPESi424ljT E9zg==
X-Gm-Message-State: ALoCoQmp0FIkN1hXqvOwsMsa/6wN6Aj/R6Fod5d/sSAA1ZAumoVmh+vKn1P4gpxB0Z1knuVASDhm
MIME-Version: 1.0
X-Received: by 10.58.96.36 with SMTP id dp4mr348489veb.21.1400237186142; Fri, 16 May 2014 03:46:26 -0700 (PDT)
Received: by 10.52.252.97 with HTTP; Fri, 16 May 2014 03:46:26 -0700 (PDT)
Date: Fri, 16 May 2014 11:46:26 +0100
Message-ID: <CABrd9STadDa12YywvNOWPeNjHobT=Eahv7qt6OMJi2=JQhu30g@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-rtcweb-use-cases-and-requirements.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HcMuY4dHCOHGh0BVM9gytAgvdJM
Subject: [secdir] Security Review of draft-ietf-rtcweb-use-cases-and-requirements-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 May 2014 10:46:36 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. >From a security POV this document is mostly ready: it includes as common requirements for all use-cases: F11 It must be possible to protect streams and data from wiretapping [RFC2804]. and F13 The browser must encrypt, authenticate and integrity protect media and data on a per-packet basis, and must drop incoming media and data packets that fail the per-packet integrity check. In addition, the browser must support a mechanism for cryptographically binding media and data security keys to the user identity (see R-ID-BINDING in [RFC5479]). which are nice, _but_ it seems to me that, given that metadata interception is now the norm, that there should be an additional requirement that identity data should not be available to attackers (i.e. that a GPA or a MitM should not be able to determine who the end-points are from data transmitted in the stream). I note that RFC 5479 also does not appear to include this requirement. Also, F11 is perhaps a little weak in that it appears to only require protection from a GPA, not from a MitM. RFC 5479 is a little unclear on this point (it discusses active attackers but doesn't specifically say protocols should defend against them). -- Certificate Transparency is hiring! Let me know if you're interested.