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

Sean Turner <sean@sn3rd.com> Thu, 14 February 2019 19:24 UTC

Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <155000069929.8344.2037971001030338378@ietfa.amsl.com>
Date: Thu, 14 Feb 2019 14:23:56 -0500
Cc: ops-dir@ietf.org, draft-ietf-rtcweb-security.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C77E79CD-478D-4EF8-8C5A-59A33832580D@sn3rd.com>
References: <155000069929.8344.2037971001030338378@ietfa.amsl.com>
To: Joe Clarke <jclarke@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/YvRPiDCsN4Doc-CLnhZu6KT1F8s>
Subject: Re: [rtcweb] Opsdir last call review of draft-ietf-rtcweb-security-11
Precedence: list

Hi! Doc Shepherd here ;)

> On Feb 12, 2019, at 14:44, Joe Clarke <jclarke@cisco.com> wrote:
> 
> 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.

The rationale I provided in the Shepherd write was this:
   This draft is bound standards track because it includes all of the WebRTC
   security considerations and will referred to from all WebRTC WG drafts.

There are also 8 2119-MUSTs/MUST NOTs is the document that affect browser behavior, which (I think) gets it over the informational level hurdle.

> 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.

It does, but the 1st sentence explains why they are the same.  I guess we could rename the section, but it’s just a layer of indirection.

> 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.

I addressed these in the following PR:
https://github.com/rtcweb-wg/security/pull/13

> 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.

I suggest “the browser has trusted UI …”. if that’s wrong I can amend the PR.

> ===
> 
> 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/

[rtcweb] Opsdir last call review of draft-ietf-rt… Joe Clarke
Re: [rtcweb] Opsdir last call review of draft-iet… Sean Turner
Re: [rtcweb] Opsdir last call review of draft-iet… Joe Clarke