Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

Eric Rescorla <ekr@rtfm.com> Fri, 26 April 2013 06:09 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9CB21F97AF for <rtcweb@ietfa.amsl.com>; Thu, 25 Apr 2013 23:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.525
X-Spam-Level:
X-Spam-Status: No, score=-96.525 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, RELAY_IS_220=2.118, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-m7EQ1PGnjm for <rtcweb@ietfa.amsl.com>; Thu, 25 Apr 2013 23:09:12 -0700 (PDT)
Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id BEE8821F8EF7 for <rtcweb@ietf.org>; Thu, 25 Apr 2013 23:09:11 -0700 (PDT)
Received: by mail-vb0-f41.google.com with SMTP id f12so1332471vbg.28 for <rtcweb@ietf.org>; Thu, 25 Apr 2013 23:09:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=nGpsngy0HHt3V+eB+3ivWPII5rllMJCrq1MNcD4wzKM=; b=AZpkZHD8oJyrabRWwN74th6lmU/Y5o32sYm3nseHfjxBCeOITEbKQFHfs3/6+8/5Xv 4kC2kjEshsgyS9ctQ3vP0z5LIm+PVBiRXzxDBEr+zXPteyVi/F/IplKzGgIUM1KzqGKd vnywZCLj2czNklq6Si4m2gejyyx6vZkgMrqYru/TyCKkCTrA5EdKwNA45nsUkcd6lEfW kSvF+TGEy6B5+KzIUukqxzNKVlQfIJsKlvszYskT549YHeFCUVmdJ5gp+HXys9edmKIP lzV9Iy1iN2k/m+j4NzS8GCnxfaNZsuY/raScgJcuolDh8SV+TBMNVkZrWZUvjGuL4vks 1+6g==
X-Received: by 10.58.220.129 with SMTP id pw1mr28635153vec.32.1366956551116; Thu, 25 Apr 2013 23:09:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.161.71 with HTTP; Thu, 25 Apr 2013 23:08:31 -0700 (PDT)
X-Originating-IP: [220.136.2.221]
In-Reply-To: <517A00AE.2090804@matthew.at>
References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <CABkgnnVky++ZF1uaM8p4xtzvDQH7HMCaL8N2ZV3dZDYnv-NvzQ@mail.gmail.com> <CABcZeBOkCC9wn7H7a4U0SYNAfYtNB2w6SvwZi4aL5f9wcwLp+g@mail.gmail.com> <517A00AE.2090804@matthew.at>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 25 Apr 2013 23:08:31 -0700
Message-ID: <CABcZeBPtKMxOx5DH0HJgb6hq8qCfJfJqbAVbtq3aip1w=VDirA@mail.gmail.com>
To: Matthew Kaufman <matthew@matthew.at>
Content-Type: multipart/alternative; boundary="047d7bd6a8cea75d1404db3d5f23"
X-Gm-Message-State: ALoCoQkMw3huNIHCdQa2UYZMeoWHPZzTH6l8/D3OziGqxK/dBvginq+tP1Vt0PO+V0NV+pBrK0Xx
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 26 Apr 2013 06:09:12 -0000

On Thu, Apr 25, 2013 at 9:21 PM, Matthew Kaufman <matthew@matthew.at> wrote:

> On 4/25/2013 4:19 PM, Eric Rescorla wrote:
>
>>
>> It's certainly true that the site has access to the media with DTLS if you
>> don't use identity assertions/isolated streams. However, what it doesn't
>> have is *invisible* access. I.e., it must do something that is user
>> visible,
>> which allows for the detection of cheating by the site. By contrast, if
>> SDES is used
>> then the site can simply passively monitor all your traffic, or at least
>> any that goes through its network and you can't detect it.
>>
>>
> That really depends on what you mean by "user visible" doesn't it? If you
> mean "the user is watching to see that all their packets go to what they
> know is the verified IP address of their buddy" then sure. But if you mean
> "the user is looking at their web browser user interface" or even "the user
> was worried mid-call so checked to see where the packets were going" then I
> think not, as all that needs to happen is for the call to be set up with a
> middlebox in the path that the site claims is necessary for the call to
> work (meets the UI test), keys set with EKT, and then a little ICE
> renegotiation and the middlebox goes away from the path (meets even the
> second test).


What I mean is that you can use fingerprint checks (admittedly
inconvenient) to
detect active attacks. Obviously, current browser UIs don't support that,
but
I expect them to eventually.

-Ekr