[rtcweb] Encryption consideration: SDES and TLS-SRP

"Fabio Pietrosanti (naif)" <lists@infosecurity.ch> Sat, 24 March 2012 22:41 UTC

Return-Path: <lists@infosecurity.ch>
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 BC31E21F8489 for <rtcweb@ietfa.amsl.com>; Sat, 24 Mar 2012 15:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jxbbFYco2RWD for <rtcweb@ietfa.amsl.com>; Sat, 24 Mar 2012 15:41:18 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 951F021F8478 for <rtcweb@ietf.org>; Sat, 24 Mar 2012 15:41:18 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so2561358wib.13 for <rtcweb@ietf.org>; Sat, 24 Mar 2012 15:41:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding :x-gm-message-state; bh=I1HjTYVyiaPpUBL/nYjhZpilXXA0PThke+sfdEUG/Xo=; b=aG6GTHFYQPqgTBmhNQK87OV71sMD+YcQ6WJaHGZZiypxjtZL5+LcW3ZS3zpqdK9BoO tqzE25HpLvY1GMOL1IESCv7etbG7wEYFNVr77FEgYL7b4tKadN3gOBK9K1VCEIoo1g8R sWZi95h72D9qWVXmm2k5RphPhg1bWejjzoRyhe1gZ1h6mBTTHbk0LYaK2psGtISRslom ULfdteBDoljhMLxuG0q6xuguTb69zX6XTlNiVGsI4qVRk24htsG8qb4uf4s/yDsSoSI8 LCg17GekhdE0elAvCqNjKSzW0K2MhkGjs2flkG4YthSIaJlFqD0dU5CEGr1VB4eRYpEi Wlkw==
Received: by with SMTP id bk9mr7342808wib.11.1332628877542; Sat, 24 Mar 2012 15:41:17 -0700 (PDT)
Received: from sonyvaiop13.local (93-32-159-172.ip34.fastwebnet.it. []) by mx.google.com with ESMTPS id ff2sm43556484wib.9.2012. (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 15:41:16 -0700 (PDT)
Sender: Fabio Pietrosanti <naif@infosecurity.ch>
Message-ID: <4F6E4D8A.60402@infosecurity.ch>
Date: Sat, 24 Mar 2012 23:41:14 +0100
From: "Fabio Pietrosanti (naif)" <lists@infosecurity.ch>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlm5gXh6zto3pV+1A1l1mbMmBGawO/jQqmAkCMxrKIugUaMRjPlhomx+FoMHll1Wyef/Twb
Subject: [rtcweb] Encryption consideration: SDES and TLS-SRP
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: Sat, 24 Mar 2012 22:41:32 -0000

Hi all,

i wanted to ask the WG opinion on the encryption framework for the RTCWEB.

In particular as we know today there is a strong need to have an
encryption-by-default on most new protocols.

- Email provider encryption by default traffic
- Mobile operators encrypt by default traffic
- Almost all web transaction use encryption

So it's realistic and practical to think that VoIP future is
encrypted-by-default to at least basically protect against the casual
wiretapper. (Can we evaluate this assumption?)

In that case we may have different threat scenario:
- Eavesdropping by third party with access to user's communication line
- Eavesdropping by who is providing the telephony service

A simpler protection scenario would at least provide protection against
third party with access to user's communication line.
A stronger protection scenario would also provide protection against who
is providing the service.

Here we should consider the security of:
- Signaling
- Media

Signaling has to be protected with TLS.
Media has to be protected with SRTP that rely on DTLS or on the new
proposal to use SDES [1] (idea that i like).

So basically in both cases there is the need to rely on a TLS-secured
channel and here we should evaluate the possible weak points.

As you know the TLS based trust model based on "Browser/OS Pre-loaded
Trusted CA" revealed serious risks posed to internet trust model [2] .

So, because we are defining a stack that should look forward the future,
we cannot not-consider seriously the serious issues related with TLS and
way to manage it.

An idea that came to my mind is that the specification, to face a
future-proof approach to the internet trust issues, could mandate to
support the implementation of TLS-SRP.

TLS-SRP is a new standard that let the TLS key exchange be authenticated
by a login/password with no need to trust a specific CA.
Status of implementation of RFC5054 http://tools.ietf.org/html/rfc5054
is available on http://trustedhttp.org/wiki/Main_Page .

If we embrace SDES key exchange and TLS-SRP authentication the overall
protocol stack would be simpler than having to deal with DTLS and
relying only on Trusted-CA architectures.

[2] http://ritter.vg/p/2012-TLS-Survey.pdf

p.s. I'm quite new to the list, so i may repeat some discussion
elements. In that case i kindly ask to leave to archive pointer to
already made discussion.