[rtcweb] Comments on draft-ietf-rtcweb-security-06

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed Security Considerations for WebRTC
(draft-ietf-rtcweb-security-06) and have some comments.

1. Section 4.2.1:

I noted this:
   There also needs to be some mechanism for the browser to verify that
   the target of the traffic continues to wish to receive it.  Because
   ICE keepalives are indications, they will not work here, so some
   other mechanism is needed as described in
   [I-D.muthu-behave-consent-freshness].

Not that the current information is wrong, except that the reference
should be to the WG version of the draft. However, this I think is the
only part of the document I found which prevents another WG last call on
this document, due to the open issue regarding method of communication
consent refresh.

2. Section 4.2.2.:

First sentence duplicated.

3. Section 4.2.2:

When I read this section, my immediate question was, doesn't RTP need
corresponding protection. To my understanding, the answer would be yes,
but it is more difficult to inject data and get a certain plaintext even
without the SRTP encryption scrambling the payload part. Still, that
assumes that an JS application, can write the payload data itself.
Secondly, it does assume that one MUST use encryption in SRTP.

Thus, I wonder if it is worth spending a paragraph confirming the need,
although reduced for masking also of RTP content, and that the same
requirement exist for RTP.

4. Section 4.3.2.2:
   Once uses have checked the SAS once, key continuity is required to
   avoid them needing to check it on every call.

I believe "uses" in above sentence should be "the user"?

5. Section 6.

Please correct my last name.

6. General:

I think the difficulty with this document is to determine if is missing
something? It is providing the high level system security issues. Have
we caught all relevant ones? I think we need a lot of eyes to check for
that. And that requires thought and not being restricted by the document.

I think a potential issue that isn't discussed in this document is the
security threat of driving data volumes into a network beyond ones
"fair" share. This would simply be to illustrate that communication
consent is not sufficient, to protect other users of a shared network
the WebRTC endpoint MUST prevent transmission of data volumes far
outside of the fair share.

7. General:

I noticed that some of the other WG documents may think they have
outsourced their security consideration to this document. I want to
bring this up as a general question and ensure that we have WG agreement
on this.

This document discusses general system security considerations to ensure
that the whole thing we put together achieve security. Each component of
the solution will have to discuss security considerations details around
their components.

As we plan to WG last call this document as soon as possible, we are
running out of time to lift any security issues to this level.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------