[rtcweb] Detailed Review of draft-ietf-rtcweb-security-arch-02
Jim McEachern <jmce.ietf@rogers.com> Mon, 16 July 2012 17:53 UTC
Return-Path: <jmce.ietf@rogers.com>
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 9E4D711E825C for <rtcweb@ietfa.amsl.com>; Mon, 16 Jul 2012 10:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_102=0.6]
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 241f4Fl3h2n2 for <rtcweb@ietfa.amsl.com>; Mon, 16 Jul 2012 10:53:36 -0700 (PDT)
Received: from nm13-vm0.bullet.mail.ac4.yahoo.com (nm13-vm0.bullet.mail.ac4.yahoo.com [98.139.52.232]) by ietfa.amsl.com (Postfix) with SMTP id A7F8C11E824E for <rtcweb@ietf.org>; Mon, 16 Jul 2012 10:53:36 -0700 (PDT)
Received: from [98.139.52.195] by nm13.bullet.mail.ac4.yahoo.com with NNFMP; 16 Jul 2012 17:54:17 -0000
Received: from [209.191.108.97] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 16 Jul 2012 17:54:17 -0000
Received: from [66.94.237.100] by t4.bullet.mud.yahoo.com with NNFMP; 16 Jul 2012 17:54:17 -0000
Received: from [127.0.0.1] by omp1005.access.mail.mud.yahoo.com with NNFMP; 16 Jul 2012 17:54:17 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 444415.52080.bm@omp1005.access.mail.mud.yahoo.com
Received: (qmail 4776 invoked by uid 60001); 16 Jul 2012 17:54:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1342461257; bh=LNW2h8PTj1N8bqmzRiqsMPXTiaxiH0cnpZNuFUA0qR4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rFG7lpdKPzXHCf+2GwY3S3H6QpLwKe//VIVrtlvGyL1bHvjMxph77UxlHURJq7gnNCHc/dLNMAL+PBbwj5sZcFlv7MG1A2pUnfYhVICUF7tjAht9v1z0Ob2e8E8nFnFNxD8/ls0gcbHbe+Dg2wO1iR9u7RRHgHeR035W3JNRqic=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pewuk6aU1uMuW3IH0cXnGM5TJt0cs8zWNX/oCkORjJ7pGeULPRVnW9TaPff4Fek9eyYNr5wDHJ5n2NwqUy2Tz58FjpxQpkWEorNZTnO9Wfue/5gJZRhkdV+GFAGkFbRFtOz5icBRHBjfZq9aDzYcScgxqKG2ea9uvI1W0rvzjAM=;
X-YMail-OSG: 66PjcOMVM1lQgtpOYoGla6YwvUive5zEjtH8BqelbiZI.Tr VNHPP5kD0qd8jVlOACLS7Uv7P_RvyW0_O0rISht5iP8uIh7qkipWBPR2NFsW AnmNkqg5yU7ldFoDW.GG6WPMsal3w.SNxyjwq4EEw4homNz8FNcI1dRguH6Q niTjayA_1PTQ.XBv_JoqJofmy_UFeBaAH8b0VrnvbJHS1JZ5ZyXGjBkJ8NyX yabWB.AhX9c1a9DQdjunNsBpBw9.mPUvomZgrXNjUKMASSDSRb22FBDwWRKf _nckw9GLeZGlhT_zF.dpuTcljdC7XYFC04F9G3K48b5BJcbmfdq2tAwlbHeD QQf1TX8qh5u90PPhn1VcaPKm0nA51nTsBJpj.KfPAF6kHtdEdvop5HZYOrFM vkk4gD.JHcYqzLr960PMPZLf5klkt.l4Os7zCEfJi18qOSY69MvQoywTPIUm q
Received: from [99.240.70.9] by web88620.mail.bf1.yahoo.com via HTTP; Mon, 16 Jul 2012 10:54:14 PDT
X-Mailer: YahooMailWebService/0.8.120.356233
References: <1342123062.4892.YahooMailNeo@web88602.mail.bf1.yahoo.com>
Message-ID: <1342461254.1994.YahooMailNeo@web88620.mail.bf1.yahoo.com>
Date: Mon, 16 Jul 2012 10:54:14 -0700
From: Jim McEachern <jmce.ietf@rogers.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
In-Reply-To: <1342123062.4892.YahooMailNeo@web88602.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Subject: [rtcweb] Detailed Review of draft-ietf-rtcweb-security-arch-02
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Jim McEachern <jmce.ietf@rogers.com>
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: Mon, 16 Jul 2012 17:53:37 -0000
I have completed a thorough review of RTCWEB Security Architecturedraft-ietf-rtcweb-security-arch-02, and have the following comments. Section 3.1 Authenticated Entities contains the following description: "Calling services: Web sites whose origin we can verify (optimallyvia HTTPS)." Question. Is there any practical way to verify the origin of the web site other than via HTTPS? If not, then the word "optimally" could be removed. Nit: "...camera an microphone" => "...camera and microphone". Section 4.1 The sixth paragraph has the following sentence, starting at the bottom of page 8 and continuing onto page 9: "In this case, Alice has provided an identity assertion andso Bob’s browser contacts Alice’s identity provider (again, this isdone in a generic way so the browser has no specific knowledge of the IdP) to verity the assertion." This should read ... to "verify" the assertion. Section 4.4. Communications and Consent Freshness, the second paragraph reads: "The one remaining security property we need to establish is "consent freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications. ICE specifies periodic STUN keepalizes but only if media is not flowing. Because the consent issue is more difficult here, we require RTCWeb implementations to periodically send keepalives. If a keepalive fails and no new ICE channels can be established, then the session is terminated." However, draft-ietf-rtcweb-security-03, section 4.2.1 states: "There also needs to be some mechanism for the browser to verify that the target of the traffic continues to wish to receive it. Obviously, some ICE-based mechanism will work here, but it has been observed that because ICE keepalives are indications, they will not work here, so some other mechanism is needed." So unless I am missing something, the current text in draft-ietf-rtcweb-security-arch-02 proposes to use the solution that draft-ietf-rtcweb-security-03 said would not work. Section 5.3 also states the problem with ICE keepalives is that they are one-way, (while draft-ietf-rtcweb-security-03, section 4.2.1 states that it is because they are "indications") and that we therefore must use the consent freshness mechanism [I-D.muthu-behave-consent-freshness]. Consistent language and requirements in these various sections would be helpful. The following proposals may address this: - in draft-ietf-rtcweb-security-03, section 4.2.1 change "indications" to "one-way indications". - in Section 4.4. Communications and Consent Freshness, the second paragraph, add a sentence between the second last sentence, and the last sentence. The end of this paragraph would then read: "Because the consentissue is more difficult here, we require RTCWeb implementations toperiodically send keepalives.These keepalives MUST be based on the consent freshness mechanism specified in [I-D.muthu-behave-consent-freshness]. If a keepalive fails and no new ICEchannels can be established, then the session is terminated." Section 5.2 Device Permissions Model, bottom of page 11, the first API requirement states: "API Requirement: The API MUST provide a mechanism for the requesting JS to indicate which of these forms of permissions it is requesting. This allows the client to know what sort of user interface experience to provide. " Comment: I guess it is implied by this, but it might be worth explicitly stating that one of the motivations behind the "user interface experience"is allowing the browser to know what permissions to ask the user for, and what permissions to enforce later. 5.3. Communications Consent, bottom of page 12 says: "Browser client implementations of RTCWEB MUST implement ICE. Server gateway implementations which operate only at public IP addresses may implement ICE-Lite...." Question: What is the intent here for server gateway implementations? Do we mean that server gateway implementations ... may implement ICE-Lite instead of full ICE, but MUST implement one of them? I assume that is the intent, but I think the current wording does not technically say that. I think the current wording could reasonably be interpreted as saying that server gateway implementations technically don't have to implement either. 5.4. IP Location Privacy The second API requirement might be clearer if it was split into two separate requirements, the first dealing with the requirement to be able to force TURN-only candidates, and the second providing an ability to reconfigure to add non-turn candidates. In addition, the explanation in the second requirement seems incomplete, as it only discusses some of the benefits. It could be expanded, and put as a separate paragraph after the requirements. Here is text that you might consider for this paragraph, building on what is already there: Proposed expanded text: "Taken together, these requirements allow ICE negotiation to start immediately on incoming call notification, thus reducing post-dial delay, but also to avoid disclosing the user’s IP address until they have decided to answer. They also allow users to completely hide their IP address for the duration of the call. Finally, they allow a mechanism for the user to optimize performance by reconfiguring to allow non-turn candidates during an active call if the user decides they no longer need to hide their IP address." The second API requirement in section 5.5 on page 14 is a repeat of the first requirement, and should be deleted. Specifically: "API Requirement: The API MUST provide a mechanism to indicate that a fresh DTLS key pair is to be generated for a specific call. This is intended to allow for unlinkability." In section 5.5, in the list of properties that are likely to require drill-down, at the top of page 15, the first bullet is not listed in the format of a requirement, while the others are. It currently is: "* The cryptographic algorithms in use (For example: "AES-CBC" or "Null Cipher".)" This could be changed to: "* The "security characteristics" MUST indicate the cryptographic algorithms in use (For example: "AES-CBC" or "Null Cipher".)" Nit: 5.6. Web-Based Peer Authentication, second paragraph has mis-placed brackets. (i.e., HTTP/HTTPS identity provider), should be (i.e., HTTP/HTTPS) identity provider... 6.1. Communications Security, end of second paragraph, at the bottom of page 16, has the following sentence: "Users who wish to assure themselves of security against a malicious identity provider MUST verify peer credentials directly, e.g., by checking the peer’s fingerprint against a value delivered out of band." Question: are we really putting MUST requirements on the user? Would it be more accurate to change "MUST verify" to "can only do so by verifying..."? Jim Jim
- [rtcweb] Detailed Review of draft-ietf-rtcweb-sec… Jim McEachern
- [rtcweb] Detailed Review of draft-ietf-rtcweb-sec… Jim McEachern