Early Review of draft-ietf-rtcweb-security-arch-11
review-ietf-rtcweb-security-arch-11-secdir-early-gondrom-2015-10-08-00

I have reviewed this document as part of the
      security directorate's ongoing effort to review all IETF documents
      being processed by the IESG.  These comments were written
      primarily for the benefit of the security area directors. 
      Document editors and WG chairs should treat these comments just
      like any other last call comments.





      The draft aims for proposed standards and defines the security
      architecture for WebRTC.





      The document appears in reasonably good shape. 


      There are still several open issues (TBDs) in the document that
      need to be completed before publication.





      Below a series of my own comments, discuss elements and questions
      for your consideration. 





      Comment:


      section 3 Trust Model: 


      s/rooted in the browser/rooted in the browser and the underlying
      operating system


      (the requirements for the integrity of the system underneath the
      browser does not go away. Furthermore the browser does rely on
      some trust and crypto functionality provided by the underlying
      OS.)





      Question: what security risks does the connection from Bob to IdP1
      (the IdP from Alice) create? 





      DISCUSS: Section 4.1: 


      "This does not require a security check: JS from any origin is
      allowed to get this far."


      Comment: Maybe the wording is unprecise, or if it is intended as I
      read it than I beg to disagree. There are several security
      concerns if that would be the case. Just a few examples, I am sure
      there are plenty more: 


      1. privacy concerns if you can trigger someone initiating a call


      2. Denial of service scenarios, creation of PeerConnections or the
      scenario of "the great cannon of China" comes to mind, in which
      you can let other people flood a recipient with call requests. 





      COMMENT: Section 4.1. paragraph 6: 


      s/preferably over TLS/it SHOULD use TLS. 


      If possible, I would even go for "MUST", but I am not sure about
      whether there are legitimate use cases that require non-TLS? 


      (e.g. we want avoid resource consuming, spoofing and replay
      attacks)





      COMMENT: Section 4.3. last paragraph: 


      "Even if they do not use an IdP, as long as they have minimal
      trust in the signaling service not to perform a man-in-the-middle
      attack, they know that their communications are secure against the
      signaling service as well (i.e., that the signaling service cannot
      mount a passive attack on the communications)."


      => This reads confusing. IMO if they are not using an IdP, they
      can not assume that their communications are secure against the
      signalling service MitM attack. 





      Question on Section 5.2


      "Requests for one-time camera/microphone access." does the
      "one-time access" have a time-out after some time, or max
      duration? How long would that be? 





      At end of Section 5.2: there is still an open issue to be resolved
      by the WG. Note: It definitely requires a higher / different level
      of explicit consent, as it allows access to a third resource. 





      Question on Section 5.5.: 


      Do we need to assert that the client provide UI information from
      which peer the current stream is coming from? 


      Assuming you have 3 or more peers (A, B and C) in a meeting, can
      you avoid that B replays the voice of A in effect spoofing him to
      C on the application layer? 





      Question on section 5.6.5.: 


      does this naming scheme also consider subdomains? 


      The example in the last paragraph seems to normalize
      identity.example.com to
      

https://example.com/.well-known/idp-proxy/example

? 







Question on section
        5.7.1.: 


        Do you need to support UNICODE characters for identities? 


        Preferably, I would like to avoid such, as that could cause it's
        own set of potential problems with similar looking
        codepoints....





        Section 6: Security Considerations


        refers to draft-ietf-rtcweb-security-08 which is scheduled to be
        reviewed by another member of Secdir. 


        Please note that I have browsed the referred draft but did not
        conduct a deep review of the other ID. Some of my questions
        above might have been addressed there. 





        Comment: 


        Section 6.3. states that "On the other hand, signing the entire
        message severely restricts the capabilities of the calling
        application, so there are difficult tradeoffs here." Actually my
        assumption was that the entire signalling message would be
        signed. What are the implied restrictions that prevent that from
        happening? Is there a way we could allow for that? 





        Question on Section 6.4.2. IdP Well-known URI


        Assuming a server that does not host an IdP nor is aware of the
        special semantics of this "well-known URI". 


        Would an attacker with access to this initially empty structure
        be able to create a working IdP and assert identities for the
        domain of that server that might supersede other 3rd-party IdP
        servers?   





        COMMENT on section 6.4.5.1 and 6.4.5.2: 


        It seems the text is suggestion that popup blocking and third
        party cookie blocking are not compatible with using an IdP. I
        would recommend a statement that sites SHOULD (MUST?) implement
        in a way that they still function with client side popup
        blocking and third party cookie blocking. 







A general question from a risk perspective: 


      I wonder whether an IdP can by providing the identity assertions
      for the users determine a very detailed record of all call
      metadata (time, src, dst, ...) of all communications for a user.
      Are there any abstraction mechanisms we could deploy to limit that
      exposure to the IdP? On the other hand, is the identity assertion
      linked to a system time, to avoid later replay attacks? 





      Thank you and best regards.





      Tobias