Re: [rtcweb] Benjamin Kaduk's Discuss on draft-ietf-rtcweb-security-11: (with DISCUSS and COMMENT)

[Sean Turner <[e-mail]>]

Didn’t get all the way through the comments, but I got a pretty start.  If there’s something else we need to discuss I can organize a time to get folks on a call.

> On Mar 6, 2019, at 14:08, Datatracker on behalf of Benjamin Kaduk <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-rtcweb-security-11: Discuss
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I'd like to have a brief discussion about a few points, though it's not clear that any change
> to the document will be required (details in the COMMENT section for all of these):
> 
> Mutually-verifiable "secure mode" seems to require that the peer's browser be included in
> the TCB, which is a bit hard to swallow.  Are we comfortable wrapping that in alongside
> "we trust the peer to not be malicious"?
> 
> It's not clear how much benefit we can get from *optional* third-party identity providers;
> won't the calling service have the ability to silently downgrade to their non-usage even if
> both calling peers support it?

Looks like you and Adam worked it out and now we need to come up with some text.  A PR to address this is here:

https://github.com/rtcweb-wg/security/pull/17

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

I filled a "comments PR” here:
https://github.com/rtcweb-wg/security/pull/19

> I mostly only have editorial comments, though there are a few that are
> more content-ful.
> 
> Section 1
> 
>                                                                     As
>   with any Web application, the Web server can move logic between the
>   server and JavaScript in the browser, but regardless of where the
>   code is executing, it is ultimately under control of the server.
> 
> The user can observe the javascript running the browser, though maybe
> this distinction is not necessary here.

I re-read this a couple of times and the only thing I could add is what is probably very obvious, i.e., the user is in control of the end-point so it can see anything.  I am too am not sure that’s really worth pointing out here.

> Section 3
> 
>                                                               Huang et
>   al. [huang-w2sp] summarize the core browser security guarantee as:
> 
>      Users can safely visit arbitrary web sites and execute scripts
>      provided by those sites.
> 
> I note that the author of this document is listed as a coauthor on
> huang-w2sp; does the self-cite really add much authority to the
> summary of the guarantee?

Eh ... I can see where maybe not much would be added if there was just one author and the paper hadn’t been accepted by a conference, but there are five and it was accepted.

> The use of ALL-CAPS to call out new terms feels a bit dated.

Haha - I can fix TCB, WEB ATTACKERS, and NETWORK ATTACKERS :). Fixed in this “comments PR”.

>                                                                   Note
>   that for non-HTTPS traffic, a network attacker is also a Web
>   attacker, since it can inject traffic as if it were any non-HTTPS Web
>   site.  Thus, when analyzing HTTP connections, we must assume that
>   traffic is going to the attacker.
> 
> nit: I know this is a web-centric document, but the privileging of https
> as the only "secure" traffic reads a bit oddly to me; something like
> "note that in some cases, a network attacker is also a web attacker,
> since transport protocols that do not provide integrity protection allow
> the network to inject traffic as if they were any communications peer.
> TLS, and HTTPS in particular, prevent against these attacks, but when
> analyzing HTTP connections, we must assume that traffic is going to the
> attacker."  (A thought experiment might be to consider whether wss://
> traffic counts as "HTTPS traffic”.)

It’s include the comment PR noted above.

> Section 3.1
> 
> It might be appropriate to provide some example references in place of
> "extensive research”.

So there’s lots and I’m not even really sure where to start here, but we do reference [cranor-wolf] later so I’ll add that here.

> Section 4.1
> 
>                                                In either case, all the
>   browser is able to do is verify and check authorization for whoever
>   is controlling where the media goes.  [...]
> 
> nit: the wording here is a bit odd, since in case (1) you're verifying
> you're talking to A, but you still control where the media goes (in
> terms of A or not-A; A can of course then forward on the media further).

Maybe “In both cases, ..."

> 00000000000000000000000000000000000000000000000000000000000000000000By
>   contrast, consent to send network traffic is about preventing the
>   user's browser from being used to attack its local network.  [...]
> 
> nit: "local" is perhaps overly restricting, depending on interpretation

I can see striking “local”.

> Section 4.1.1
> 
> Maybe note that the "result" of the cross-site requests that is leaked
> is in the form of pixels and not structured data, but that does not
> change the information content.

Something like: 

  A more sophisticated attack would be open up a
  source view window to a site and use the screen sharing result to
  simply view anti cross-site request forgery tokens which would leak pixels
  and not structured text.

> Section 4.1.3
> 
>   Now that we have seen another use case, we can start to reason about
> 
> nit: I'm confused by "another" here.

I think this should be:

  Now that we have the calling scenarios, we can start to reason about ..

This links this para back to the previous calling scenarios and user expectations.

>                                              While not suitable for all
>   cases, this approach may be useful for some.  If we consider the case
>   of advertising, it's not particularly convenient to require the
>   advertiser to instantiate an iframe on the hosting site just to get
>   permission; a more convenient approach is to cryptographically tie
>   the advertiser's certificate to the communication directly.  We're
> 
> This seems to be relying on the reader to have some background knowledge
> and make some leaps of reasoning that may not be reasonable to expect.

Okay so -04 included a section that was referred to by this section that addressed the “Calling to an AD Target”, but that section was removed because the WG decided not treat the case “specially”.  So yeah there was some more background provided like 6 years ago.  I have to admit I’m not entirely sure I know how to address this comment.

>   Another case where media-level cryptographic identity makes sense is
>   when a user really does not trust the calling site.  For instance, I
>   might be worried that the calling service will attempt to bug my
>   computer, but I also want to be able to conveniently call my friends.
> 
> This is especially challenging because if the site (and/or its
> javascript) is in the path for binding a cryptographic identity to a
> real-world identity, then a malicious site can still get whatever keys
> it wants authorized.

yep

> Section 4.1.4
> 
>   3.  The attacker forges the response apparently http://calling-
>       service.example.com/ to inject JS to initiate a call to himself.
> 
> seem to be missing a word or two here.

I think r/apparently/from
fixed in comments PR

>   which contain untrusted content.  If a page from a given origin ever
>   loads JavaScript from an attacker, then it is possible for that
>   attacker to infect the browser's notion of that origin semi-
>   permanently.
> 
> nit: "If any page" is more emphatic, I think.

Yep fixed in comments PR.

> Section 4.2
> 
> Do we want any discussion of the risks when metered bandwidth (pay per
> byte) is in use?

Do you mean concerns that the connection will be closed if your bill isn’t paid up? :)

> Section 4.2.1
> 
> There's probably some room to tighten up the verbiage here; e.g., "the
> site initiating ICE" is referring to a website that is using a browser
> API to request ICE against some remote peer (right?).

Yes, but that’s the whole point of the intro, this is a browser focused world that has a JavaScript API.

>  And "ICE
> keepalives are indications" is using Indication as the technical term
> for a message that doesn't get an ACK response, not in its common
> English usage.

Yes, but those are the actual terms used by ICE, which is referred to in the first sentence in the paragraph.

> Section 4.2.2
> 
> A one- or two-sentence summary of the impact of misinterpretation
> attacks is probably in order, instead of making us follow the reference
> (which isn't a section reference).
> 
>   Where TCP is used the risk is substantial due to the potential
>   presence of transparent proxies and therefore if TCP is to be used,
>   then WebSockets style masking MUST be employed.
> 
> nit: "employed" to obfuscate what, exactly?
> 
> Section 4.2.3
> 
>   refuses to send other traffic until that message has been replied to.
>   The message/reply pair must be generated in such a way that an
>   attacker who controls the Web application cannot forge them,
>   generally by having the message contain some secret value that must
>   be incorporated (e.g., echoed, hashed into, etc.).  Non-ICE
> 
> nit: "incorporated" into what?
> 
> I think I'm a little confused about which legacy actors we're talking
> about.  Are we still considering the broader situation a
> webserver-mediated interaction between two browsers or brower-adjacent
> applications?  (E.g., a WebRTC client calling some other sort of video
> chat system?)
> 
>   leaves.  The appropriate technologies here are fairly similar to
>   those for initial consent, though are perhaps weaker since the
>   threats is less severe.
> 
> nit: "threat is”

It got switched to “are” as a result of some other review.

> Section 4.2.4
> 
>   Note that as soon as the callee sends their ICE candidates, the
>   caller learns the callee's IP addresses.  The callee's server
>   reflexive address reveals a lot of information about the callee's
>   location.  In order to avoid tracking, implementations may wish to
>   suppress the start of ICE negotiation until the callee has answered.
> 
> Is "answered" supposed to be some interaction with the controlling site?
> 
>   In ordinary operation, the site learns the browser's IP address,
>   though it may be hidden via mechanisms like Tor
>   [http://www.torproject.org] or a VPN.  However, because sites can
>   cause the browser to provide IP addresses, this provides a mechanism
>   for sites to learn about the user's network environment even if the
>   user is behind a VPN that masks their IP address.  [...]
> 
> Some rewording for clarity is probably in order; "ordinary operation" is of
> a website without WebRTC; "sites can cause the browser to provide IP
> addresses" is when the site uses the browser API to request ICE
> initiation; etc.
> 
> Section 4.3.1
> 
> [Obligatory note about "Forward Secrecy" vs. "Perfect Forward Secrecy"]
> 
>   to subsequent compromise.  It is this consideration that makes an
>   automatic, public key-based key exchange mechanism imperative for
>   WebRTC (this is a good idea for any communications security system)
>   and this mechanism SHOULD provide perfect forward secrecy (PFS).  The
>   signaling channel/calling service can be used to authenticate this
>   mechanism.
> 
> To be clear, the authentication that the calling service provides is a
> binding between identity and the public keys that are input to the key
> exchange mechanism?
> 
> Section 4.3.2.1
> 
>                                                       Even if the user
>   actually checks the other side's name (which all available evidence
>   indicates is unlikely), this would require (a) the browser to trusted
>   UI to provide the name and (b) the user to not be fooled by similar
>   appearing names.
> 
> nit: "browser to use trusted UI”

Fixed in the comments PR.

> Section 4.3.2.3
> 
> It's not clear that third-party identity providers actually provide
> downgrade-resistance -- can't the site mediating the calls just decline
> to acknowledge that a third-party identity is/was available for the
> peer?
> 
> Section 4.3.2.4
> 
>                                    I.e., I must be able to verify that
>   the person I am calling has engaged a secure media mode (see
>   Section 4.3.3).  In order to achieve this it will be necessary to
>   cryptographically bind an indication of the local media access policy
>   into the cryptographic authentication procedures detailed in the
>   previous sections.
> 
> This seems to require extending the TCB from just the local browser to
> the remote browser as well, which is ... a stretch.
> (Also, do we really need the first person?)

Dropped the first person (I also hope the RFC editor) can help with this elsewhere.

See the comments PR.

> Section 9.2
> 
> The coordinates for [OpenID] don't seem quite right.

The title was off.  Fixed in the comments PR.