Re: [rtcweb] Encryption consideration: SDES and TLS-SRP

Harald Alvestrand <harald@alvestrand.no> Sun, 25 March 2012 20:12 UTC

Return-Path: <harald@alvestrand.no>
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 0D9E421E8015 for <rtcweb@ietfa.amsl.com>; Sun, 25 Mar 2012 13:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 k4Cr3NxDfgl0 for <rtcweb@ietfa.amsl.com>; Sun, 25 Mar 2012 13:12:08 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D8A1E21E800C for <rtcweb@ietf.org>; Sun, 25 Mar 2012 13:12:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83AA739E180; Sun, 25 Mar 2012 22:12:06 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leXLfiBUmQ2o; Sun, 25 Mar 2012 22:11:45 +0200 (CEST)
Received: from [10.216.6.96] (unknown [93.158.42.180]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2B77F39E04C; Sun, 25 Mar 2012 22:11:44 +0200 (CEST)
Message-ID: <4F6F7C01.8050709@alvestrand.no>
Date: Sun, 25 Mar 2012 22:11:45 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: "Fabio Pietrosanti (naif)" <lists@infosecurity.ch>
References: <4F6E4D8A.60402@infosecurity.ch>
In-Reply-To: <4F6E4D8A.60402@infosecurity.ch>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [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: Sun, 25 Mar 2012 20:12:09 -0000

Please read draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch.

I'm sorry, but not even checking the names of drafts the working group 
is working on before asking questions is below the minimum bar we expect 
of participants posting long emails.

                 Harald

On 03/24/2012 11:41 PM, Fabio Pietrosanti (naif) wrote:
> 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.
>
> Today:
> - 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.
>
> [1]
> http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-7.pdf
> [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.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>