[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