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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Feb 2014 17:05:27 +0100

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Ted Hardie <[email-masked]>
Date: Thu, 20 Feb 2014 09:13:44 -0800

> outside of the fair share.
Magnus, I'm not sure why you think that issue should be dealt with in this
document.
This document should deal with cases where a malicious script could send
transmissions
that are not intended or not welcome.  Bbut managing network capacity for
*intended*
and *welcome* transmissions is not a security concern.  It's a congestion
management
issue, at least as I see it.

Am I missing something about your concern?

Ted

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Feb 2014 09:08:54 +0100

On 2014-02-20 18:13, Ted Hardie wrote:
> On Thu, Feb 20, 2014 at 8:05 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Hi,
> 
> Magnus, I'm not sure why you think that issue should be dealt with in
> this document.
> that are not intended or not welcome.  Bbut managing network capacity
> for *intended*
> and *welcome* transmissions is not a security concern.  It's a
> congestion management

My concern is that a malicious individual wants to DDoS a particular
network. I buy AD time from on of the network or in any other way ensure
that the mailicious JS identifies when each client is topologically
right for me to connect it to another client to drive traffic through my
targets network. Then I ensure these clients establish a peer connection
and I try to blast as much traffic through the network as possible. From
the point of the attack this doesn't matter if is real-time media or
data traffic. The point is to drive as much traffic into the network as
possible. From that perspective any traffic that is sent in the context
of a peerconnection needs to be congestion controlled. That at least
keeps the traffic down to a "fair" share.

We are mitigating this attack, however what I was really wondering over
is if the security considerations document should make note that lack of
appropriate congestion control is a security vulnerability and enables
certain type of load attacks.

Does this make my concern clearer?

Cheers

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Feb 2014 09:33:57 -0800

> Secondly, it does assume that one MUST use encryption in SRTP.

Yes, with WebAudio, I can construct an SRTP packet that contains
ciphertext that I can control, assuming that I know the session keys
(yes), and I'm prepared to do a lot of work.  SRTP doesn't have the IV
per-packet that DTLS does.  What you can't do is make it look like a
non-SRTP packet, the first byte, length and MAC would be extremely
difficult to control (for the MAC, that's more or less the point...),
if not impossible.

So the question is, is there an intermediary that might be tricked
into interpreting an SRTP packet in a way that might have negative
consequences.  When masking was added to websockets, it was because
the confusion was demonstrated as being possible: intermediaries were
searching for HTTP requests and responses in ways that were easily
exploited and then caching the results.  To a large extent, that
attack relied on the fact that TCP is a stream-based protocol - it
didn't matter where the request appeared.  In this case, the mapping
of SRTP onto UDP doesn't really lead to intermediaries looking for
goodies inside packets.

I'm not going to say that there is a risk, but I think that I'd be
willing to take the risk given the plethora of mitigating
circumstances here.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 Feb 2014 17:02:59 -0800

On Fri, Feb 21, 2014 at 12:08 AM, Magnus Westerlund <
[email-masked]> wrote:

> and I try to blast as much traffic through the network as possible.

Sorry for my apparent failure to understand here, but we're still dealing
with
traffic to which the parties consent, right?  That is, you're thinking of
malicious
JS that sends channels worth of nonsense to blast the network while
something
the user cares about happens? (Two-player flappy bird but with a terrabit
of nonsense
screaming in the background?)

> From
So my take as an individual is that congestion control is a known desirable
property, and that we're addressing its lack as we can.  Adding that note to
the security document doesn't seem to me to add much to this story.

Ted

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Feb 2014 17:14:42 -0800

On 21 February 2014 17:02, Ted Hardie <[email-masked]> wrote:
> the user cares about happens? (Two-player flappy bird but with a terrabit of
> nonsense

Maybe Magnus is looking for the mechanism described in
http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00,
which might allow for control below the limit that the congestion
control permits.  I basically abandoned this, because it's small
potatoes. It's trivial to revoke consent if you notice a misbehaving
peer and then you only have to wait until the consent timer runs out
on the sender.  30s.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 24 Feb 2014 11:05:03 +0100

>> screaming in the background?)

Yes, that would be the attack. And the target of the attack is the
networks in the middle, not the endpoints, they are simply tools for this.

> peer and then you only have to wait until the consent timer runs out

My position is that the above mitigation is unlikely to have significant
impact on this attack. This as it is difficult to know what values to
set. They vary over time and depending on network attachment, what
services the user tries to use etc.

There are two reasons I wanted this attack to be considered. First, it
provides a clear requirement on having congestion control as first level
mitigation.

Secondly, I think this could become a significant issue as data channel
PeerConnections can be opened without user consent. A malicious JS that
is sufficient well spread with a well working find and connect could
establish a large mesh of peer connections that could come close to
saturate each endpoints local access link, resulting in very heavy loads
on the network, even with congestion control. With congestion control
you can likely prevent congestion collapse, but you should be fully
capable of driving a network into a state of "mostly useless",
especially a network suffering from buffer bloat inside of the ingress
nodes.

Cheers

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Feb 2014 10:58:49 -0800

On 24 February 2014 02:05, Magnus Westerlund
<[email-masked]> wrote:
> impact on this attack.

That was my sense too.

> provides a clear requirement on having congestion control as first level

Congestion control.  Check.

> especially a network suffering from buffer bloat inside of the ingress

So the concern is that even with congestion control, a single bad
actor can use more than their "fair" share of network resources.

Sadly, this is already true on the web.

No harm in writing down the potential.  Are you looking for anything
more than that?

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 25 Feb 2014 10:13:52 +0100

> No harm in writing down the potential.  Are you looking for anything

No, I think the main thing is to have something to point at why
congestion control is a MUST. Secondly, at least make people aware that
this mechanism may give a malicious entity more potential for driving
traffic load where they want to cause it than some of the previous
mechanism, due to the ease of finding endpoint and keeping traffic more
localized than in other DDoS attacks. But, sure it will more difficult
to drive the targeted network into completely uselessness.

Cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Tue, 25 Feb 2014 17:22:49 -0500

> especially a network suffering from buffer bloat inside of the ingress

Of course, any smart attacker could do the same today by opening large 
numbers of http or WebSocket connections that cross the same networks, 
especially if the target isn't the remote endpoint but intermediary 
networks as you indicated.  A difference is that it may be harder to 
find destination nodes that will accept such connections and return or 
accept data across the link you want to attack, though the open requests 
themselves can be an attack. However, in real terms, there are usually 
nodes in an access network that return some data to requests (such as 
routers with remote admin turned on, servers (or rogue servers), 
especially on non-standard ports (not 80), etc.  Simply finding routers 
that respond on 80 or 8080, etc and you can send large bogus HTTP 
request to or get to return static images repeatedly might be enough to 
construct an equivalent attack.  (Even more-so perhaps with IW10).

So: congestion control: of course.  Perhaps this makes it a little 
simpler to set up certain types of indirect attacks - but I don't think 
it adds a fundamental class of attacks.

-- 
Randell Jesup -- rjesup a t mozilla d o t com