Re: [rtcweb] Consensus call regarding media security

Iñaki Baz Castillo <ibc@aliax.net> Thu, 29 March 2012 17:34 UTC

Return-Path: <ibc@aliax.net>
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 BEE9321F881F for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 10:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.626
X-Spam-Level:
X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 Db1nSM6Y4hyT for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 10:34:36 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D345721E801B for <rtcweb@ietf.org>; Thu, 29 Mar 2012 10:34:35 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1912720vbb.31 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 10:34:35 -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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=yQbPSWCW2BP9XA4hpPfl2kKVJuf/zDnZ8Oi86BcPazc=; b=AHT/AuTtX20UR0X/qsMLdWKHEMt0NeNSOwUlo/ULEZwlbxwfdtf0e8iXxi1GLI7Sdw LZtVMweIwJThV9u1OBbB6tCHC4aoTx7itENcshdPFTABOSbjQneRgUUjK9My0XvCD7Tr J1Vy2oCcCgQoZSCIrk96VLy+lbaU54R2KabuqfszPXlDxzKuwM9+K6jVD0sIzv3fSsPu m0vhd3o4uinG8hjkWYVJhqpn7ehEWNmhpVBgMYb3zEF6HzFrK2NUJtwc9rLMbTrVgrqG 0lC1LFJiECi0YZpHDMkxfPlkJvbSUjeNYgxu8NonPSTYLb+kXl38fJD7qrg6gq55vqaG H/PA==
Received: by 10.52.88.4 with SMTP id bc4mr3547154vdb.51.1333042475358; Thu, 29 Mar 2012 10:34:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 10:34:15 -0700 (PDT)
In-Reply-To: <4F749C82.4070305@infosecurity.ch>
References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> <4F749C82.4070305@infosecurity.ch>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Thu, 29 Mar 2012 19:34:15 +0200
Message-ID: <CALiegfmuKE_fbxg=9AEUNeF-pis5fa-DeGahAfh+0T6aFvvtAw@mail.gmail.com>
To: "Fabio Pietrosanti (naif)" <lists@infosecurity.ch>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmqPNmVmKzJe+v8IeoPh0blFYiroHUjEagnLiu/jpB3zRWjPbkdVlWQ5rrWiCgndYaVeRGZ
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Consensus call regarding media security
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: Thu, 29 Mar 2012 17:34:36 -0000

2012/3/29 Fabio Pietrosanti (naif) <lists@infosecurity.ch>:
> From:
> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/?include_text=1
>
> "   The basic assumption of this architecture is that network resources
>   exist in a hierarchy of trust, rooted in the browser, which serves as
>   the user's TRUSTED COMPUTING BASE (TCB).  Any security property which
>   the user wishes to have enforced must be ultimately guaranteed by the
>   browser (or transitively by some property the browser verifies)."
>
> So, it means that if the browser already have a hierarchy of trust to
> use TLS for HTTPS, then SDES-SRTP will inherit the trust-properties of
> the HTTPS website from which it's loaded.
>
> It seems to me quite easy to fit SDES-SRTP into the browser model, as it
> allow you to assure that the communication path between the client and
> the server is secure.
>
> Do you expect WebRTC to be only peer-to-peer/client-to-client?
>
> I sincerly expect *a lot* of communications to goes trough SIP/RTP media
> proxy for security purpose, for billing purposes, for value added
> service purpose.
>
> SDES-SRTP provide a very reliable and simple way to let a WebRTC peer to
> establish security with the server, assuming that it already have
> established security trough HTTPS/TLS that's a consolidate trust method.

+2  (I don't use "+1" since I don't use Google+).

-- 
Iñaki Baz Castillo
<ibc@aliax.net>