Subject: [rtcweb] Comments on draft-ietf-rtcweb-security-arch-11

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Mar 2015 14:36:11 -0500

Hi,

I have reviewed draft-ietf-rtcweb-security-arch-11:

1. Section 5.2: The screen sharing Open issue must go away. I am fine
with the general direction proposed yesterday.

2. Section 5.4:

I wonder if there are actually needs to be a consideration on the WebRTC
implementation to have a user knob that forces it into TURN only mode,
so that one can't use the browser to get the local IP. Otherwise there
is no way for the user to preserve their IP addresses against a
malicious JS that like to find a browser hiding behind a proxy or other
address hiding mechanism.

3. Section 5.5:

   All implementations MUST implement DTLS 1.0, with the cipher suite
   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection
   profile SRTP_AES128_CM_HMAC_SHA1_80.  Implementations SHOULD
   implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   cipher suite.  Implementations SHOULD favor cipher suites which
   support PFS over non-PFS cipher suites and GCM over CBC cipher
   suites.  [[OPEN ISSUE: Should we require ECDSA?  Waiting for WG
   Consensus.]]

This open issue must be resolved.

4. Section 5.5:

      *  The "security characteristics" MUST include an indication as to
         whether the cryptographic keys were delivered out-of-band (from
         a server) or were generated as a result of a pairwise
         negotiation.

Are we actually allowing any method that would allow out-of-band
provisioning. If not should this be removed.

5. Section 5.5:

      *  The "security characteristics" MUST indicate the cryptographic
         algorithms in use (For example: "AES-CBC" or "Null Cipher".)
         However, if Null ciphers are used, that MUST be presented to
         the user at the top-level UI.

I thought Null cipher was forbidden, does it makes sense to keep that
example?

6. Section 5.6.4.2:

   identity-attribute  = "identity:" identity-assertion
                         [ SP identity-extension
                           *(";" [ SP ] identity-extension) ]
   identity-assertion  = base64
   base64              = 1*(ALPHA / DIGIT / "+" / "/" / "=" )
   identity-extension  = extension-att-name [ "=" extension-att-value ]
   extension-att-name  = token
   extension-att-value = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff)
                         ; byte-string from [RFC4566] omitting ";"

These two lines requires references for base64 and token:

identity-assertion  = base64
extension-att-name  = token

7. Section 6.1:
   While this document favors DTLS-SRTP, it permits a variety of
   communications security mechanisms and thus the level of
   communications security actually provided varies considerably.

I think this is also a remnant of the time before we restricted the
keying to DTLS-SRTP for SRTP?

8. Section 6.1:

In order to protect against malicious content JavaScript, that
   JavaScript MUST NOT be allowed to have direct access to---or perform
   computations with---DTLS keys.

There are decorations in the text that are not standard ASCII.

9. Section 6.3:

   [I-D.ietf-rtcweb-rtp-usage] Section 13 documents a number of
   potential RTCP-based DoS attacks and countermeasures.

Those security considerations in RTP usage are not only RTCP based,
there is both discussion of the VBR threat as well as header extension
encryption. I wonder if the reference to this documents security issues
needs to be expanded.

10. Section 6.4.1:

   In order to prevent this attack, we require that all signatures be
   tied to a specific origin ("rtcweb://...") which cannot be produced
   by content JavaScript.

I have seen no indication that this scheme is being registered. Because,
it looks like it needs to be registered to ensure that it doesn't start
being used in another context.

11. Section 8:

S/Magnus Westerland/Magnus Westerlund

12. Reference section, please update.

   [I-D.ietf-avtcore-6222bis]
              Begen, A., Perkins, C., Wing, D., and E. Rescorla,
              "Guidelines for Choosing RTP Control Protocol (RTCP)
              Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
              (work in progress), July 2013.

This is RFC 7022.

   [I-D.muthu-behave-consent-freshness]
              Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage
              for Consent Freshness", draft-muthu-behave-consent-
              freshness-04 (work in progress), July 2013.

This is draft-ietf-rtcweb-stun-consent-freshness-11

13. Appendix A:

[[TODO: These still need some cleanup.]]

Please perform what ever this todo means and then remove it.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------