Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-security-arch

From: Magnus Westerlund <[email-masked]>
Date: Sat, 9 Mar 2013 08:41:28 +0100

EKR, WG,

I have made an individual review of the security architecture document
version 6 and have the following comments.

1. In title and in other places, should we use WebRTC as the handle to
the complete solution?

2. Section 7.2 is wrongly labeled, I assume it is -04 version

3. Section 4:
As is conventional in the Web, all identities are
   ultimately rooted that system.

I guess this should be ... rooted in that system?

4. Figure 4. The arrow between Bob's browser and Bob's IdP is missalinged.

5. Section 4.1:
Because this is an audio/video call, it creates
   two MediaStreams, one connected to an audio input and one connected
   to a video input.

I think this normally would be one mediaStream but with two
MediaStreamTracks.

6. Section 4.1:
If Bob agrees [I am ignoring early media for now], a PeerConnection
   is instantiated with the message from Alice's side.

I think you can remove the parenthesis. First of all I don't think it
relavant in the paragraph. Secondly, early media doesn't exist in the
context of a single peerConnection.

7. Section 4.3

If Alice and Bob authenticated via their IdPs,
   then they also know that the signaling service is not mounting a man-
   in-the-middle attack on theor traffic.

theor / their?

8. Section 5.1:

It is RECOMMENDED that browsers which allow
   active mixed content nevertheless disable RTCWEB functionality in
   mixed content settings. [[ OPEN ISSUE:  Should this be a 2119 MUST?
   It's not clear what set of conditions would make this OK, other than
   that browser manufacturers have traditionally been permissive here
   here.]]

I am actually quite worried about not making this a MUST. Mixed content
clearly causes significant security holes that I think really should be
avoided.

9. Section 5.1, similarly I think this applies to the second open issue
in this section.

10. Section 5.3:

[Note:
   this document takes no position on the split between ICE in JS and
   ICE in the browser.  The above text is written the way it is for
   editorial convenience and will be modified appropriately if the WG
   decides on ICE in the JS.]  The JS MUST NOT be permitted to control
   the local ufrag and password, though it of course knows it.

I think you can clean up this statement as there is consensus to leave
ICE in the browser.

11. Section 5.3:
A separate document will profile the ICE
   timers to be used; see [I-D.muthu-behave-consent-freshness].

We should clarify the WG consensus on this document and the scope the
document has.

12. Section 5.4:

   API Requirement:  The API MUST provide a mechanism for the calling
      application JS to indicate that only TURN candidates are to be
      used.  This prevents the peer from learning one's IP address at
      all.

What about the ICE candidates related address information, that should
be mentioned I think also as possible risk of leaking and what to set it to.

13. I am missing a discussion on how to avoid the linkage issues. I
think we need to point out the known sources to linkage that WebRTC
adds. I am aware of RTCP CNAMEs and as well as the certificate used in
DTLS(-SRTP). Their should be recommendations on how to avoid these issues.

14. Section 5.5
   [OPEN ISSUE:  What should the settings be here?  MUST?]
   Implementations MAY support SDES for media traffic for backward
   compatibility purposes.

This needs to be resolved. I see no issues with retaining the
possibility for SDES and other schemes. I think however, the downgrade
issues may need more discussion here. This is a somewhat discussed in
the security considerations section later.

15. Section 5.5
   API Requirement:  The API MUST provide a mechanism to indicate that a
      fresh DTLS key pair is to be generated for a specific call.  This
      is intended to allow for unlinkability.  Note that there are also
      settings where it is attractive to use the same keying material
      repeatedly, especially those with key continuity-based
      authentication.

I think this has to do with 13. For example should really the same
certificate be used with different origins, unless it is a intentionally
added endpoint certificate that provide verifiable source?

16. Section 5.5
[largely derived from
      [I-D.kaufman-rtcweb-security-ui]

Maybe this is more suitable in a contributors section instead of inline
in text.

17. Section 5.5:

      *  The "security characteristics" MUST indicate the cryptographic
         algorithms in use (For example:  "AES-CBC" or "Null Cipher".)

Does there need to be additional discussion or clarifications on high
level indications when one uses NULL cipher that doesn't provide
confidentiality?

18. Section 5.6.2:

The details of the mechanism are described in the W3C API
   specification,

I think a reference needs to be added here.

19. Section 5.6.3
Todo REF!

20. Section 5.6.4.1:

   The "algorithm" and digest values correspond directly to the
   algorithm and digest in the a=fingerprint line of the SDP.

Should there be a reference to where a=fingerprint is defined here?

Also, does it need to be clarified what "algorithm" and digest
reference, the ABNF contructs or value for those parameters.

21. Section 5.6.4.2:
This SDP attribute is underspecified. No clear definition of what is
allowed, no IANA consideration section registering it.

Also, should this SDP attribute also carry the origin of the IdP? I just
wonder how a non browser can determine which IdP has been providing the
assertion.

22. Section 5.6.5.1 and following.

I would like that all these JSON objects would have a bit more crisp
definitions. Sure, the JSON has certain limiations in what values can be
used, but it is unclear if the full UTF-8 values can be used in all
cases, or if there is restrictions on the URL provided, or if it should
be URI's in fact?

23. I am missing a security discussion around the fact that I can claim
to have an IdP and load whatever JS code into the proxy. What security
implications deos this have. Section 5.6.5.2 does provide some basic
restrictions here. Are more needed?

24. Section 5.6.5.2.2:

   idp:  A dictionary containing the domain name of the provider and the
      protocol string

What is the definition of dictionary here?

25. Are there any time limits on responding to SIGN or Verify, or can
you get applications to hand simply by not responding to a IdP message?

26. Section 5.6.5.2.3:

Are the fields required to be included or not. This is a bit unclear.

Section 27. Section 5.6.5.2.3:
Open issue to resolve. Please try to resolve this issue by talking to
some people.

27. Section 5.6.5.2.3.1

Open issue needing resolution. No opinion.

28. Section 5.7.2:

Missing the linkability issues discussion here.

29. Section 5.7.2:

Combined RTCWEB/Tor
   implementations SHOULD arrange to route the media as well as the
   signaling through Tor. [Currently this will produce very suboptimal
   performance.]

I think you can remove the parenthis but keep the text here.

30. Page 40 SDP example looks strange with no a=idenity attribute,
instead just the JSON object.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------