Re: [rtcweb] #30: Wiretapping
Harald Alvestrand <harald@alvestrand.no> Fri, 13 September 2013 07:15 UTC
Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD311E8153 for <rtcweb@ietfa.amsl.com>; Fri, 13 Sep 2013 00:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 YNhUs9o70SBR for <rtcweb@ietfa.amsl.com>; Fri, 13 Sep 2013 00:15:28 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A64D821E8051 for <rtcweb@ietf.org>; Fri, 13 Sep 2013 00:15:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39FCB39E202 for <rtcweb@ietf.org>; Fri, 13 Sep 2013 09:15:20 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO8rhp+DBKEN for <rtcweb@ietf.org>; Fri, 13 Sep 2013 09:15:19 +0200 (CEST)
Received: from [172.30.42.84] (unknown [62.109.39.85]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1E2BC39E03B for <rtcweb@ietf.org>; Fri, 13 Sep 2013 09:15:19 +0200 (CEST)
Message-ID: <5232BB86.5010202@alvestrand.no>
Date: Fri, 13 Sep 2013 09:15:18 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <066.e4120f60682a48aa7753e29f3071d4d8@trac.tools.ietf.org>
In-Reply-To: <066.e4120f60682a48aa7753e29f3071d4d8@trac.tools.ietf.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] #30: Wiretapping
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2013 07:15:35 -0000
On 09/13/2013 02:08 AM, rtcweb issue tracker wrote: > #30: Wiretapping > > In several sections of the document, the phrase "It is essential > that the communication cannot be wiretapped [RFC2804]" is used. > The phrase is used in Sections 3.2.1.1, 3.2.11.1, 3.2.12.1, 3.2.13.1, > 3.3.1.1 and 3.2.3.1, but not in 3.2.14.1 (which also does not > reference F20). > > Given the recent revelations, and the discussion of SRTP/SDES at > IETF 87, I would suggest the following: > > a. Use of more precise terminology than what is in F20. For example, > I think what we are asking for in many of the F20 scenarios is > per-packet encryption and integrity protection of media, > utilizing keys known only by the endpoints, as well as support > for perfect forward secrecy. I think this is a too low level of detail for an use cases document. It does belong in the security / security-arch document, where we detail both what the requirement implies and how the requirement is implemented. If we want to add details here, I suggest adding "against an adversary that has access to the signalling path and/or access to one of the end systems after the communication has occured" (which would lead to a requirement for DTLS key exchange and PFS). > > b. Inclusion of a reference to F20 in Section 3.2.14.1 (Distributed > Music Band). Not sure why protection against snooping wouldn't be > relevant in this use case (there are countries where musicians > have been severely punished). > > c. Consideration of the requirement in gateway scenarios. For gateway > scenarios such as 3.3.1.1, the e2e key management > requirement probably isn't realistic, so maybe we need to > just cite F35/F36 for that case. > If we use the language I suggested above, noting that this spec can do nothing to secure things beyond the gateway is probably enough ("e2e" key management in this case would mean "end to gateway" - it's up to the gateway and what's beyond it to protect the keys after that). -- Surveillance is pervasive. Go Dark.
- Re: [rtcweb] #30: Wiretapping Harald Alvestrand
- [rtcweb] #30: Wiretapping rtcweb issue tracker
- Re: [rtcweb] #30: Wiretapping rtcweb issue tracker
- Re: [rtcweb] #30: Wiretapping rtcweb issue tracker