Subject: [rtcweb] Mirja Kühlewind's No Objection on draft-ietf-rtcweb-security-arch-18: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 28 Feb 2019 10:00:16 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-rtcweb-security-arch-18: No Objection

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

1) This is related to my discuss on draft-ietf-rtcweb-security. I think I don't
fully understand the split between those two documents, as section 4.2 seems to
introduce a normative reference to draft-ietf-rtcweb-security:

  "As described in ([I-D.ietf-rtcweb-security]; Section 4.2) media
   consent verification is provided via ICE. "

However, given that section 6.3 actually normatively (re-)states the ICE
requirements as well, I would maybe recommend to instead say:

  "As described in ([I-D.ietf-rtcweb-security]; Section 4.2) and stated in
  section 6.3 media
   consent verification is provided via ICE. "

and then move the reference to draft-ietf-rtcweb-security to informative.

2) I would have also expected some discussion in the security considerations
sections about the risks to the user if the browser gets corrupted, as
indicated by the trust model presented in sec 3.

3) In Sec 9.2: "Combined WebRTC/Tor
   implementations SHOULD arrange to route the media as well as the
   signaling through Tor. Currently this will produce very suboptimal
   performance."
Maybe make these sentences a bit more general, e.g.
"Combined WebRTC/anonymity service
   implementations SHOULD arrange to route the media as well as the
   signaling through the anonymity network. Currently with e.g. Tor this will
   produce very suboptimal performance.