Re: [rtcweb] Consensus call regarding media security

Roman Shpount <roman@telurix.com> Thu, 29 March 2012 15:15 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 061CA21E81ED for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 08:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.834
X-Spam-Level:
X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=0.142, 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 epnJzQExRdwO for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 08:15:23 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 465CC21E81E5 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 08:15:23 -0700 (PDT)
Received: by qaea16 with SMTP id a16so154947qae.10 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 08:15:22 -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 :x-gm-message-state:content-type; bh=sBznaPT0Jz3fjab7QV11EJgfgYqU5SVc78mRSDDpcOU=; b=bohRg879JB1AHB8rfWY+NjNU/55hfmM0TytdUC6r2kwj/Dkk9TSnN5jfvVcXr9N0C9 j0ytcmCDzM3OoO3/imu3XB2STCcRj+zbGxH/rFMvMQ0c1OlaxDWLVXeyZipS5bheAQHt M687zSXMHocJ6l7qyXbSnKfQsfJ19Zn9ZJgFGgh9QADPJZnpyY6ZwCORE9y5IPGGkWfP 8Zaxh3Iv/yjyiGQ0h8vTaZVQa+F/WtW2LhdkFmqEBIqXqmIqJCsyUSP0MYfWU/7IIwkW BtYT0ELaHJICB7vynK7C8/YxGrn8mn+yi5pOBntI4cakco365Img7tbtHyxCJCiRxJB8 adZw==
Received: by 10.224.174.72 with SMTP id s8mr580271qaz.67.1333034122790; Thu, 29 Mar 2012 08:15:22 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id dm8sm12851220qab.18.2012.03.29.08.15.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 08:15:22 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so1722537ghb.31 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 08:15:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.230.99 with SMTP id sx3mr704450pbc.55.1333034121152; Thu, 29 Mar 2012 08:15:21 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Thu, 29 Mar 2012 08:15:21 -0700 (PDT)
In-Reply-To: <CALiegf=gZs_h4SqvQgwrb1Nec7TZZ6rpHRHgyKGVYtvED78jpw@mail.gmail.com>
References: <4F732531.2030208@ericsson.com> <CAD5OKxs6NHha2egNSTumEaHYJ0bB6qu_nfshmBM6dntx2n49HQ@mail.gmail.com> <CALiegfn4MZYb-qCnM62T7w4EgWqrC5baN+pAYBZF84kEA7Ko6A@mail.gmail.com> <CAD5OKxtDED1vSFrw4V9TKkUzdSSXNg+S_WBrxmnFo21hjJvqMA@mail.gmail.com> <CALiegfkmckSar175LDYouvPkp0Vm1QCKhmTuiGNnD62QTDhamg@mail.gmail.com> <CAD5OKxur4FKAw8PprjfxLQVekmOWGuQegqN02mHsP+Hr-k_UNg@mail.gmail.com> <CALiegf=gZs_h4SqvQgwrb1Nec7TZZ6rpHRHgyKGVYtvED78jpw@mail.gmail.com>
Date: Thu, 29 Mar 2012 11:15:21 -0400
Message-ID: <CAD5OKxs+ijUt6pXz7OEAtQEyAwZ54rHmJFwnMg5BmL9zYCiOEQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Gm-Message-State: ALoCoQkK3J8tI8Iw0JivRtMi2F3SMdx2L461OwYVm7XZkqdi22cdUaWbGPSnUXQaXIQeckpQW6ye
Content-Type: multipart/alternative; boundary=047d7b2edf0343c72004bc633144
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 15:15:24 -0000

I wanted to clarify what i actually want to see as security/encryption
policy for WebRTC.

1. SRTP-DTLS is required to be supported and is offered by default with no
option to bid down to anything else.
2. From HTTPS session SDES SRTP can be enabled via an API method
3. From HTTP session RTP can be enabled via an API method

I only want to allow RTP from HTTP initiated session, since I see no
benefit of supporting SDES SRTP there. I only want to allow SDES SRTP from
HTTPS initiated sessions, since SDES SRTP provides no security benefits
when session description is transmitted over clear channel.

With my proposal, if an application provider does not care about security,
they will use HTTP/RTP. If they care about security, they will use
HTTPS/DTLS-SRTP or SDES-SRTP, if interop or weather forces them to do so.
Also, this way we do not provide false sense of security if someone decides
to start SDES-SRTP session from HTTP.

Is someone can explain to me how this is less secure, even in the airport
wifi comparing to SDES-RTP from HTTP session, please do so.

P.S. I do know why this is less secure then DTLS-SRTP only option.
_____________
Roman Shpount