[rtcweb] Areas of security concern

Watson Ladd <watsonbladd@gmail.com> Wed, 12 March 2014 05:11 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7E81A04A3 for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 22:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0leEcJWxqYE for <rtcweb@ietfa.amsl.com>; Tue, 11 Mar 2014 22:11:29 -0700 (PDT)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id C83311A07D5 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 22:11:29 -0700 (PDT)
Received: by mail-yk0-f176.google.com with SMTP id 19so25826403ykq.7 for <rtcweb@ietf.org>; Tue, 11 Mar 2014 22:11:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=N7xhvHqzuFQz867EeiEV79EEBwkj22FfYocjdd9eNQI=; b=wiXgeVsktVGkjwo+8cuNMpTpCvqmHY4vo75nn1vAoJHQRZeVi0cCls9D9CX2lLs24a xAzUjNWl+JLa+rrKXHjcvJrb/O4OUDhw8cxlZQd98rc9rNWrh943T8BxCjfZkTxhSnWV dJqR7nROG4+0KIv0gNnQxGBU7cEm07VzoVujOL1VDk2PnM1Sd6SPozmwyse4/UIxg0aT JnUVUIkm0HMUqWJwxTk0Az7DJrL7H4aaKt8fjWPzPb3ik/JkCTtxf5LiwmGEMqRRTAEh 82DIb39B1yK7cU4Ws5hlNM5bCoCzbzmg7zF9M2HKiZB/s6wVR4PB3IMP7MyDn1Rv/Zah oGeQ==
MIME-Version: 1.0
X-Received: by 10.236.150.68 with SMTP id y44mr114848yhj.113.1394601083762; Tue, 11 Mar 2014 22:11:23 -0700 (PDT)
Received: by 10.170.80.214 with HTTP; Tue, 11 Mar 2014 22:11:23 -0700 (PDT)
Date: Tue, 11 Mar 2014 22:11:23 -0700
Message-ID: <CACsn0cmnf0Lh8JEmwA2mYEg6hOivrpxc9JhFFAKmYcv1NpLfUA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=20cf303a3183337dca04f461deac
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2iF8qIN65vCRqTWDbxNphB9fZgo
Subject: [rtcweb] Areas of security concern
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 05:11:36 -0000

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