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.