Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Mon, 04 Mar 2019 20:45:00 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-rtcweb-security-arch-18: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Update: Ignore my comment about t= vs c=0. I had my order crossed; it is
correct in the example.

I'm balloting "yes", but have a few minor comments and editorial comments:

§1:
- (nit) The first sentence will not age well; I gather RTCWEB will close before
long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the
W3C?)

- (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned
in the text. At least, please expand the abbreviation somwhere. (It also shows
up in figure 4.)

(nit) §3.1, first bullet: While I don't normally object (beyond nose holding,
anyway) to the use of first person in RFCs, it seems an odd choice for this
sentence. I assume "we" in this sentence does not refer to the the author or
the WG.

 §4.1:
(nit) - '... button next to Bob’s name which says "Call".':
s/which/that

- "The calling site will also provide some user interface
element (e.g., a button) to allow Bob to answer the call, though this
is most likely not part of the trusted UI."

This is the first mention of "trusted UI". It would be helpful to elaborate on
that prior to this mention.

§5.1.4:
- "In this
case, the established identity SHOULD be applied to existing DTLS
connections as well as new connections established using one of those
fingerprints."

Applied by the recipient? (consider active voice). Also, why not MUST? Don't
unexpected things happen if the recipient doesn't do this?

§6.2:
- "Because HTTP origins cannot be securely established against network
attackers, implementations MUST NOT allow the setting of permanent
access permissions for HTTP origins. Implementations MUST refuse all
permissions grants for HTTP origins."

(nit-ish) - The MUST NOT seems non-constraining considering the last sentence.
Or am I reading that sentence wrong?

(nit) - .E.g., "Call [email-masked]"' : sentence fragment.
(nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural
disagreement (assuming the browsers do not share 1 cert).

(maybe nit) - "Clients MAY permit the formation of data channels without any
direct user approval." Is the switch from talking about "the browser" to
"Clients" intentional?

§6.4:
(nit) - "Note that these requirements are NOT intended..."
"NOT" in all caps is likely to be confused with 2119/8174 language.

§6.5:
 (nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST
implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP
keying. Implementations MUST implement [RFC8261]."

Thank you for using the citation style that doesn't assume everyone has
memorized the RFC numbers. But why not do the same for 8261?

§7.2:
(nit) - First paragraph: Can there be a citation for the W3C API spec?

 (My bad, the draft is correct. Comment removed.) §7.1.4, SDP example:

(nit) §11: The first sentence is a fragment.

§13.1 (normative references)

(nit) - There's a reference to RFC 5234, but it is not cited in the text.

- Is there a reason to reference 5246 rather than 8446, which obsoleted it?

§13.2:
- seems like the jsep reference should be normative.

---

From: Adam Roach <[email-masked]>
Date: Mon, 4 Mar 2019 22:46:59 -0600

> Update: Ignore my comment about t= vs c=0. I had my order crossed; it is

This is true; however, t= versus a= is, indeed, backwards.

/a

---

From: Ben Campbell <[email-masked]>
Date: Mon, 4 Mar 2019 22:48:53 -0600

Yep, ignore my ignoring. I knew something was wrong; I just confused myself :-)

I can see why we keep messing this up, it’s nigh impossible to keep the order in my head more than a few minutes.

> On Mar 4, 2019, at 10:46 PM, Adam Roach <[email-masked]> wrote:
>

---

From: Sean Turner <[email-masked]>
Date: Wed, 27 Mar 2019 11:06:20 +0100

> On Mar 5, 2019, at 13:45, Ben Campbell <[email-masked]> wrote:
> 

Fixed in the following PR:
https://github.com/rtcweb-wg/security-arch/pull/88

> in the text. At least, please expand the abbreviation somwhere. (It also shows

Fixed in the above mentioned PR.

> sentence. I assume "we" in this sentence does not refer to the the author or

I am hoping the RFC editor can help here.  “we” is used a lot in this draft.

> (nit) - '... button next to Bob’s name which says "Call".':

fixed in the above PR

> that prior to this mention.

Fair enough, but there is draft-ietf-rtcweb-security that you also had to read and there’s a lot of discussion there about browsers, sandboxing, etc.

> unexpected things happen if the recipient doesn't do this?

will get back to you on this one. 

> Or am I reading that sentence wrong?

will get back to you on this one.

> disagreement (assuming the browsers do not share 1 cert).

fixed in the above PR

> direct user approval." Is the switch from talking about "the browser" to

fixed in the above PR

> "NOT" in all caps is likely to be confused with 2119/8174 language.

fixed in the above PR

> memorized the RFC numbers. But why not do the same for 8261?

fixed in the above PR

> (nit) - First paragraph: Can there be a citation for the W3C API spec?

There might be, but if you get 

> (nit) §11: The first sentence is a fragment.

It is.

> (nit) - There's a reference to RFC 5234, but it is not cited in the text.

Yep meant to delete that now it’s gone see the earlier PR.

> - Is there a reason to reference 5246 rather than 8446, which obsoleted it?

1.2 is required so we’re pointing there.

> - seems like the jsep reference should be normative.

Well the reference comes from “Note” sentence.  Since you’re really only doing this drfat And, you’re really only doing this draft because you’re doing the JSEP draft

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Mar 2019 14:51:00 +0100

> On Mar 27, 2019, at 11:06, Sean Turner <[email-masked]> wrote:
> 
> 
> 

> will get back to you on this one. 

MT seems to think we can just drop SHOULD and r/SHOULD/can
I reflected that in the PR.

> will get back to you on this one.

Chopped it to:
  Because HTTP origins cannot be securely established against network
  attackers, implementations MUSTrefuse all
  permissions grants for HTTP origins.