[secdir] secdir review of draft-ietf-rtcweb-security-arch-11

[Tobias Gondrom <[e-mail]>]

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