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 | |
| Draft 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 | |
| Review |
review-ietf-rtcweb-security-arch-11-secdir-early-gondrom-2015-10-08
|
|
| 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