[rtcweb] Final plea about SRTP

Roman Shpount <roman@telurix.com> Wed, 02 May 2012 16:03 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AF21121E803C for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 09:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.809
X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yMnQ8tT9x+Nk for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 09:03:49 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7867221E802D for <rtcweb@ietf.org>; Wed, 2 May 2012 09:03:49 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so552561wgb.13 for <rtcweb@ietf.org>; Wed, 02 May 2012 09:03:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=QPayWklhfveb86GJLRS5x2Y9MUQaKtgP0It9+agKgiE=; b=ZC8X3SRfTb+bj0xXKBgyHeGd1FPkpATrnrzsqm89aH2pEoCUuV4oexpmI3CdK1lJem 8GTop+n3gPUGUsEB2xvzwzH12WR9AsmqXd/cvUXyCqyRS14APBewKZA++70bmW6B8Hkw ty/Y8h47NZk3CmCVhTAE+EWCbfkcdikU+56QyNCpnvfF8YeCCiorXtWQhJrpT6UGTRNg 3GQJC/qNJZ3dBET4YcMjsNnlY3rRJXqu1ozrMQgOBWK86lsZh+XZwMLUkb3hwHA9yYb8 1L62vEZo/zsEmlyx3IxfRyTyeEfXnmKXr28xd1ZEbL6iiSROjacbUEDBG7qfhZvR/t7x 4enw==
Received: by with SMTP id cy7mr17246121wib.3.1335974628655; Wed, 02 May 2012 09:03:48 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com []) by mx.google.com with ESMTPS id o2sm7859008wiv.11.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 09:03:47 -0700 (PDT)
Received: by bkty8 with SMTP id y8so746240bkt.31 for <rtcweb@ietf.org>; Wed, 02 May 2012 09:03:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id b16mr6145835bkx.12.1335974626224; Wed, 02 May 2012 09:03:46 -0700 (PDT)
Received: by with HTTP; Wed, 2 May 2012 09:03:46 -0700 (PDT)
Date: Wed, 02 May 2012 12:03:46 -0400
Message-ID: <CAD5OKxtSvdu9gMqfb3ptw5aQJt1NZKLJ1UB_vKRWDXCZurD+1w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="0015175cd0da06691004bf0fd55e"
X-Gm-Message-State: ALoCoQkRuDeLE+tmfoIjuTSGqMN25uTBR90PusvIMrfEL8uIt9kmYwdYP6hNXHr0XlxSTXshmlGH
Subject: [rtcweb] Final plea about SRTP
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: Wed, 02 May 2012 16:03:50 -0000

I know there was a consensus call on this list that SRTP shall be used for
all the calls in WebRTC, but I still do not understand the justification
for this requirement for WebRTC applications delivered over HTTP with no
identity. For such scenarios SRTP (even DTLS-SRTP) serves almost no
purpose. If application is delivered over HTTP attacker can spoof the
entire web site. It is trivial if the attacker is on the communications
path. If attacker is seating in the airport using the same network, it can
put itself on the communications path using arp cache poisoning. Once the
web site is spoofed, any type of man in the middle attack can be
implemented. If DTLS-SRTP is used user can detect the attack by checking
the key signature, but in reality very few people will do this.

The main argument to require SRTP everywhere was that it does not break
anything. But neither would naming all the API methods in High Elfish.
Either requirement does not break things, but make working with WebRTC
harder then it should. At the same time both of those requirements are
completely unjustified.

Furthermore, assumption on this list that most of the WebRTC use would be
peer-to-peer communications between browsers with all the rest of the
communication modes, such as calling automated services or PSTN being
insignificant. I simply do not agree to this point of view. I expect that
communication with automated services, such as video greeting cards or
voice blogging, would be a significant portion of WebRTC user base. If such
automated service is deployed as a plain HTTP web site, it should be able
to communicate with web browsers using RTP. SRTP in such case would serve
no purpose.

Finally, requiring secure communications for everything is going against
the way most of the web works. Most of it is not secured and only requires
secure communications when secure (HTTPS) web site is accessed. I think it
should be the same for WebRTC, with DTLS-SRTP required when connected to
HTTPS web site and plain RTP allowed when connected to plan HTTP.
Roman Shpount