Re: [rtcweb] Areas of security concern
Eric Rescorla <ekr@rtfm.com> Thu, 13 March 2014 15:16 UTC
Return-Path: <ekr@rtfm.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 E8DE61A0A0B for <rtcweb@ietfa.amsl.com>; Thu, 13 Mar 2014 08:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 t6IAnSN6Tqrd for <rtcweb@ietfa.amsl.com>; Thu, 13 Mar 2014 08:16:50 -0700 (PDT)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 235731A09A8 for <rtcweb@ietf.org>; Thu, 13 Mar 2014 08:16:49 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id k14so995612wgh.35 for <rtcweb@ietf.org>; Thu, 13 Mar 2014 08:16:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MJ1KU3DThxVvYO3sRhp0RMJbor4Al7tU395OtZ4PD1A=; b=lFo8LPz9BbHaWBBtUjwG1E1XufRBhpVSLfk3g32RAwE20wu7OXKFbvT8c7i1Kvmy71 68KBAdxZCVkxL48d7x9CSD0eiWO4XGHvHnr06zXpcM8Uwco1M6yLAZLsWZtsx6J0hrJw CDwB5plKrLEEQvrhw9v99RbsjbUxUcgPTKWwqHs8t2uj5WMkwU9mHh+L2YcMg1a9qG3a SvQ85TL1oFShoxXFnwSVvSDEvjR8TQfw8GvWMpVI4a+kLutGs3Jz5MQMfVF7H964KHZX p0rZbiVHbNMoGhnzBJYFnRilZdSgYmOGni91tepr+WduGqPwk2GWJSjVyzGqJd8xqkon 0AnQ==
X-Gm-Message-State: ALoCoQlwpj0Kg8Hobtfye8QIMRIbiimA6ELvgoFDDRVQ7fNpWXEUqHaz8wISKVS1StnJ5OjrZkDq
X-Received: by 10.180.164.174 with SMTP id yr14mr2126315wib.18.1394723801690; Thu, 13 Mar 2014 08:16:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Thu, 13 Mar 2014 08:16:01 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <CACsn0cmnf0Lh8JEmwA2mYEg6hOivrpxc9JhFFAKmYcv1NpLfUA@mail.gmail.com>
References: <CACsn0cmnf0Lh8JEmwA2mYEg6hOivrpxc9JhFFAKmYcv1NpLfUA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 13 Mar 2014 08:16:01 -0700
Message-ID: <CABcZeBPgLYka1OG4aS6o9mAs=UKJm2y1SryL8bi6bA3tzRFSVA@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="00248c0d7914c28bcb04f47e70f0"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5o9RO02_JzhyOawOutI0qvFsA40
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [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: Thu, 13 Mar 2014 15:16:55 -0000
Watson, Thanks for your comments. Responses below. On Tue, Mar 11, 2014 at 10:11 PM, Watson Ladd <watsonbladd@gmail.com> wrote: > > Problem 1: Which John Smith? > > Currently IdPs link attributes to identities. > The identities are phrased as RFC822-style names subordinated beneath the domain name of the IdP (or if the IdP is a universal trust point, then not subordinated). See: http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09#section-5.6.5.3.3.1 There used to be a human-readable display-name property as well but that's gone as of this version, precisely because of concerns of this type. Perhaps you are reading a pre-09 version? > 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. > We certainly considered this, but that would basically amount to choosing a specific identity system or standardizing our own, neither of which seems totally awesome. Incidentally, cryptography isn't actually required here (though it's probably the method of choice). The IdP could also just store all the identity assertions it generates in a database and retrieve it on demand. 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. > I'm certainly aware of this paper --- though as you know it just came out recently --- but it's not clear to me how applicable it is, since the client-authentication version of the attack (which I believe is the appropriate one here) depends on the TLS server changing its identity during the session, and RFC5763 requires that the certificates presented during the DTLS handshake match the fingerprints in the SDP: o The certificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. The security properties of this mechanism are described in Section 8. RFC 5763 doesn't explicitly talk about renegotiation, so we probably could add something about handling renegotiation. If you think of some way in which the mechanisms above aren't sufficient please drop me a private e-mail so we can discuss. 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. > As far as I know, HMAC-SHA1 is sufficiently secure for this purpose. Three notes about this: 1. We are discussing audio and video packets so there are a lot of them but modifying any particular one doesn't generally get you much. 2. The MACs are truncated to 80 or 32 bits. 3. There are GCM ciphersuites in the pipeline but they haven't landed yet. This is really an issue for the IETF AVTCORE WG, however, since it applies to all of SRTP, not just rtcweb. > 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. > We certainly know about this form of attack. For instance, you can just pretend to operate a calling service but instead of showing the remote video you can just embed a YouTube video. There are effectively two cases here: - The call is not using isolated streams in which case you didn't have any protection for the media from the site anyway. - The call is using isolated streams in which case the site will have no access to the true media and so can only blindly inject their own. Obviously this isn't ideal but it's pretty hard to get rid of since the Web already includes video and even without WebRTC, it's trivial for a site to play any video it wants to you. We've talked about having some sort of UI for showing each video element and its provenance, but it's a hard UX problem. > 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. > Yes, we are aware of this. Not sure there's much to do about it. > 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. > Yeah, this is also a known issue. See RFC 6562 for some recommendations on how to address this. If you want to work on this issue, you should probably take it to the AVTCORE WG. -Ekr
- [rtcweb] Areas of security concern Watson Ladd
- Re: [rtcweb] Areas of security concern Colin Perkins
- Re: [rtcweb] Areas of security concern John Mattsson
- Re: [rtcweb] Areas of security concern Eric Rescorla
- Re: [rtcweb] Areas of security concern Watson Ladd