[rtcweb] Areas of security concern

[Watson Ladd <[e-mail]>]

Dear all,
I've jotted down the following notes when reading the drafts from here and
the W3C as potential problem areas. Maybe there are things I've missed in
the drafts that address them, but I think they are still worth thinking
about. Some of these are more W3C, but we seem to be in charge of the
security. These issues vary widely in seriousness. One of them is a
demonstrated break of confidentiality, while several are open questions
about how we communicate to users.

Problem 1: Which John Smith?

Currently IdPs link attributes to identities. But the way in which
identities are presented to the user can be misleading. Names are not
unique. Do we need a way for an IdP to indicate more about the identity?
Should IdPs be allowed to use social graph information, e.g. prevent me
from calling people who I don't "friend" on a social network, and thus
avoid the wrong John Smith? How does this information get handled? Who
decides what policy is being used?

Problem 2: IdP pointy bits

An IdP has to cryptographically bind a username to some data. It would be
nice if we could come up with a secure method to do this, and have the
browser take care of it for the identity provider as much as possible,
instead of everyone having to do it themselves in likely wrong ways. The
webcrypto API has been roundly critiqued as being too low-level.

Problem 3: Renegotiation

The DTLS handshake being used is specified in RFC 4347. In particular, I
don't see anything about the renegotiation bug being fixed. This enables an
unknown key-share attack in which A thinks they are transmitting video to
B, but really are transmitting it to C who knows that they are talking to A.

Problem 4: HMAC-SHA1 in SRTP

If I've chased the chain of references correctly this is the sole MAC
provided. Is it okay? I have no idea: SHA-1 has been significantly weakened
in recent years.

Problem 5: What you see is not what I sent

This is an area that is somewhat underspecified, depending as it does on
the media API's capabilities. The video frame could be silently replaced by
a different video frame with rather different contents. Any authentication
of the contents of the video frame would not carry over, but if the
contents were sufficiently shocking/subtle this might not be noticed.
Authentication independent of the website offering the video chat makes
this attack worse, because users will trust what they see more. Isolation
doesn't help because this is wholesale replacement, not editing.

Most uses of this attack are for puerile purposes. I don't think it's a big
concern. Then again I could be very, very wrong.

Problem 6: General UI issues

Currently quite a bit of the security model depends on UI presentations of
subtly different states. I don't know how well users will understand this,
or how well the UI will work. Past experience suggests not well. Luckily we
can mostly change this later/it isn't part of standardisation.

Problem 7: VBR privacy leaks

I can do no better then to refer to the paper.
http://www.infsec.cs.uni-saarland.de/teaching/WS08/Seminar/reports/yes-we-can.pdfSpoken
phrases could be identified from encrypted data alone, using a
Hidden Markov Model when the length of packets was preserved by the
encryption.

Conclusion:
Some of these issues result from well-known problems in older protocols.
Others are longstanding difficult problems that have to be solved. Some are
quite dangerous, while others will only permit the occasional prank.
However, it is not enough to fix these specifically. Large areas of the
proposal have not been explored by me. If I had to rate these by
seriousness, problem 3 and 7 are the worst. They are luckily the easiest to
fix.

Sincerely,
Watson Ladd