[rtcweb] Opsdir last call review of draft-ietf-rtcweb-security-11

Joe Clarke <jclarke@cisco.com> Tue, 12 February 2019 19:44 UTC

Return-Path: <jclarke@cisco.com>
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 573E4130DC4; Tue, 12 Feb 2019 11:44:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joe Clarke <jclarke@cisco.com>
To: <ops-dir@ietf.org>
Cc: draft-ietf-rtcweb-security.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155000069929.8344.2037971001030338378@ietfa.amsl.com>
Date: Tue, 12 Feb 2019 11:44:59 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/S09lXd5T_r0Zmy9apoAibgUuCFw>
Subject: [rtcweb] Opsdir last call review of draft-ietf-rtcweb-security-11
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 12 Feb 2019 19:44:59 -0000

Reviewer: Joe Clarke
Review result: Not Ready

I have been assigned to review this document on behalf of the Ops directorate. 
In general, I found the document well-written, but the reason I marked it as
not ready as I was confused as to its standards track trajectory.  I do not see
any kind of inter-operable standard being defined here.  On my reading --
before I noticed it was standards track -- it felt informational.  While it
does set out a threat model for the browser, I struggle to see how that needs
to be standardized.

On that threat model note, the abstract indicates that the WebRTC threat model
will be laid out, but section 3 defines a more general browser threat model.

Beyond those items, I noticed various nits and other small items when reading
the document.  Most broadly, I feel this document would benefit from a
terminology section to define acronyms such as ICE, TURN, STUN, VoIP, etc. 
Additionally, in section 3.1, the document refers to "scripts" in a general
way.  While the implication is JavaScript code that will run in a browser, I
think that kind of context setting might be made more explicit in a terminology
section.

Other nits are mentioned below on a section-by-section basis.

Section 1:

s/implementated/implemented/

===

Section 3.2:

s/provide a escape hatch/provide an escape hatch/

===

Section 4.2:

s/signficant/significant/

===

Section 4.2.3:

s/ threats is less severe/threats are less severe/

===

Section 4.3:

s/ The calling service is is/The calling service is/

===

Section 4.3.2.1:

OLD:

  (a) the browser to trusted UI to provide the name and

I don't grok this sentence fragment.  There seems to be a verb missing, and I'm
not sure what your intent is here.

===

Section 4.3.2.2:

s/e.g., read aloud over the the voice/e.g., read aloud over the voice/

s/However, it it is well-known/However, it is well-known/