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

Matthew Kaufman <matthew@matthew.at> Fri, 26 April 2013 04:21 UTC

Return-Path: <matthew@matthew.at>
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 0DFE121E8048 for <rtcweb@ietfa.amsl.com>; Thu, 25 Apr 2013 21:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.43
X-Spam-Level:
X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
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 MscOmkFxTxK3 for <rtcweb@ietfa.amsl.com>; Thu, 25 Apr 2013 21:21:04 -0700 (PDT)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D6821E8045 for <rtcweb@ietf.org>; Thu, 25 Apr 2013 21:21:00 -0700 (PDT)
Received: from [10.10.155.2] (unknown [10.10.155.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 70051230005 for <rtcweb@ietf.org>; Thu, 25 Apr 2013 21:21:00 -0700 (PDT)
Message-ID: <517A00AE.2090804@matthew.at>
Date: Thu, 25 Apr 2013 21:21:02 -0700
From: Matthew Kaufman <matthew@matthew.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <CABkgnnVky++ZF1uaM8p4xtzvDQH7HMCaL8N2ZV3dZDYnv-NvzQ@mail.gmail.com> <CABcZeBOkCC9wn7H7a4U0SYNAfYtNB2w6SvwZi4aL5f9wcwLp+g@mail.gmail.com>
In-Reply-To: <CABcZeBOkCC9wn7H7a4U0SYNAfYtNB2w6SvwZi4aL5f9wcwLp+g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 04:21:05 -0000

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).

Matthew Kaufman