Early Review of draft-ietf-rtcweb-security-arch-11
review-ietf-rtcweb-security-arch-11-secdir-early-gondrom-2015-10-08-00
Request | Review of | draft-ietf-rtcweb-security-arch |
---|---|---|
Requested revision | No specific revision (document currently at 20) | |
Type | Early Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2015-10-08 | |
Requested | 2015-06-26 | |
Authors | Eric Rescorla | |
I-D last updated | 2015-10-08 | |
Completed reviews |
Secdir Early review of -11
by Tobias Gondrom
(diff)
Opsdir Last Call review of -18 by Tim Chown (diff) Genart Last Call review of -18 by Russ Housley (diff) |
|
Assignment | Reviewer | Tobias Gondrom |
State | Completed | |
Request | Early review on draft-ietf-rtcweb-security-arch by Security Area Directorate Assigned | |
Reviewed revision | 11 (document currently at 20) | |
Result | Has issues | |
Completed | 2015-10-08 |
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