IETF Logo Mail Archive

Re: [rtcweb] Resolving RTP/SDES question in Paris

Roman Shpount <roman@telurix.com> Tue, 20 March 2012 13:40 UTC

Return-Path: <roman@telurix.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 E52F221F871A for <rtcweb@ietfa.amsl.com>; Tue, 20 Mar 2012 06:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.769
X-Spam-Level:
X-Spam-Status: No, score=-2.769 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 SK9dZAhtv72j for <rtcweb@ietfa.amsl.com>; Tue, 20 Mar 2012 06:40:40 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 23B7C21F8643 for <rtcweb@ietf.org>; Tue, 20 Mar 2012 06:40:40 -0700 (PDT)
Received: by dakl33 with SMTP id l33so43983dak.31 for <rtcweb@ietf.org>; Tue, 20 Mar 2012 06:40:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=o+71R0qa0pr+3AAGr3dbDCtdjImTsHyKpLAmHBPtxw4=; b=I9i0hCnWkL38LMxW3J6/1nbaQg2hoyugsPDHDXNoVv2dckgo5E0F6aJbYyisoC/35g fQMrfh2CbV5q7oXHTuKajX4T9gPcN5BtbnEOmNUiG9f7VkrXSjdkf7DJnV/tvzJHquXv oN5vlH4slxa1M3LqdIMV2D8N9rVB3SvWRne3cXwskyaJ+9k4RTXo0+sfhN0ts/li+dwG 2hlaAjTgDMlMXkN/400k+051l/3XGnvYBx1HwXy+xjVUXiC6rr5oftZ415gb8YtThzyH 2/jwrtCgQMGOGNNUm5l5KWJgFaBWRVNdCpK4pOnKvmiBPlPuFOjDkttksK5+gRblLjhu cwoA==
Received: by 10.68.136.228 with SMTP id qd4mr1167743pbb.141.1332250839917; Tue, 20 Mar 2012 06:40:39 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id o2sm1334989pbb.45.2012.03.20.06.40.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 06:40:39 -0700 (PDT)
Received: by dakl33 with SMTP id l33so43927dak.31 for <rtcweb@ietf.org>; Tue, 20 Mar 2012 06:40:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.40 with SMTP id pp8mr1502217pbb.13.1332250837423; Tue, 20 Mar 2012 06:40:37 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Tue, 20 Mar 2012 06:40:37 -0700 (PDT)
In-Reply-To: <4F685ED9.2050109@alvestrand.no>
References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <CALiegfnkYVEpmPV-zSL_4wOY-HiFZN-qJCQCiioaS=5NaqhLZw@mail.gmail.com> <CAD5OKxvtOAxMBx6xDnyfTnEq76oDEm6uj1xL6wGjjrtKUAHy3g@mail.gmail.com> <CABcZeBNZiotPmCfT53uEo+O0xw4xv6tXW1M_G-3A5BHuncsduA@mail.gmail.com> <CAD5OKxvYOY5JZ2mYNGiH1poUBQkyOOycePFijH5H+SxtcdqujQ@mail.gmail.com> <CABkgnnVe-b6Sv=R67bMJk_NQqQwdrRUn6rBm7Gu_CMcfPQwtEg@mail.gmail.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no>
Date: Tue, 20 Mar 2012 09:40:37 -0400
Message-ID: <CAD5OKxsVp7px9bHAgxgdqPMxRgppcVUDKt8JHBhyq9qqW3pAMg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary="047d7b10d17bea946f04bbacd1bd"
X-Gm-Message-State: ALoCoQnHumhiXVRBjgOIBF3USNt3ratrTIunyJufIdZlnvHOfExjj2h7gpUe11tEIt+yw4J2MutQ
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
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: Tue, 20 Mar 2012 13:40:41 -0000

Once again, I understand how this helps in case of HTTPS, but how would
this help in case of WebRTC? Media description is carried in some sort of
application defined protocol (can even be transmitted over an encrypted
SCTP data channel or encrypted in javaScript), so monitoring proxy cannot
reliably modify it. I understand how it can be allowed to fake the
signature on modified SDP by inserting a certificate in the browser, but
how would the proxy get to the SDP in the first place?
_____________
Roman Shpount


On Tue, Mar 20, 2012 at 6:41 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> **
> On 03/17/2012 10:14 PM, Igor Faynberg wrote:
>
> ..
>
> On 3/17/2012 4:45 PM, Martin Thomson wrote:
>
> ... Then I explicitly place a trust anchor for that
> certificate in your browser.
>
>
> How?  I thought the browser would never allow that to happen. (I assumed
> it would come provisioned with anchors,  or would allow anchor provision
> through some different channel.)
>
>  Igor,
>
> in Chrome, go to chrome://settings/certificates, choose the "authorities"
> tab, and note the presence of the "import" button.
>
> All browsers (as far as I know) have similar mechanisms.
> "Owning" your computer will achieve this goal both in its corporate
> meaning and in its hacker meaning.
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

v2.23.0 | Report a Bug | By Email