IETF Logo Mail Archive

Re: [rtcweb] Telling the user the connection is secure (Re: Resolving RTP/SDES question in Paris)

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Tue, 20 March 2012 15:41 UTC

Return-Path: <igor.faynberg@alcatel-lucent.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 3638A21F85AD for <rtcweb@ietfa.amsl.com>; Tue, 20 Mar 2012 08:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.402
X-Spam-Level:
X-Spam-Status: No, score=-7.402 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 rHTvTmHHKKzo for <rtcweb@ietfa.amsl.com>; Tue, 20 Mar 2012 08:41:49 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 48BF521F85AA for <rtcweb@ietf.org>; Tue, 20 Mar 2012 08:41:49 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2KFfgmk025635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Mar 2012 10:41:43 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2KFfgSv010172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Mar 2012 10:41:42 -0500
Received: from [135.244.33.178] (faynberg.lra.lucent.com [135.244.33.178]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2KFfgO3004532; Tue, 20 Mar 2012 10:41:42 -0500 (CDT)
Message-ID: <4F68A535.8010809@alcatel-lucent.com>
Date: Tue, 20 Mar 2012 11:41:41 -0400
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
References: <4F4759DC.7060303@ericsson.com> <CABkgnnVe-b6Sv=R67bMJk_NQqQwdrRUn6rBm7Gu_CMcfPQwtEg@mail.gmail.com> <CAD5OKxvZbEJ7sV4WPAYoQapzMR_QwAftj-oKg=ioMKHNT792wQ@mail.gmail.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <CALiegf=jtkDCS_D0ZFe9UpbiadQ0vsJ+4MppQSbLr-wbaXNrfQ@mail.gmail.com> <BLU169-W29E5B86F9E2C6F3126961C93420@phx.gbl> <CALiegfk2aT+6Psr4nT-hG1G7eYRBfFCcT+25On2O4HfUXJ6-ng@mail.gmail.com> <CAD6AjGSmi9j+sdGWPts20-iwGvGij05ek0OKYEPULC6B=aFpQg@mail.gmail.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <ADBB75F3-E20C-4EC4-B9C3-EF2E4BFF409C@phonefromhere.com> <CAD5OKxvuEV8Vbq3h7=ZgcKmREjmguvz5n-SpXr2n-EY7a_ddxg@mail.gmail.com> <CALiegfk1ozOKPcDjbd3H_z2Edzh4RcZpYyJSWdw_1DJ04muQXA@mail.gmail.com> <CAD5OKxu8-+0O0=eE7mD1hi=nPUpEXczGj=bRNQCQL1BW8c-c-Q@mail.gmail.com> <4F677F3B.3040407@alcatel-lucent.com> <4F686183.6040201@alvestrand.no>
In-Reply-To: <4F686183.6040201@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Telling the user the connection is secure (Re: Resolving RTP/SDES question in Paris)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
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: Tue, 20 Mar 2012 15:41:50 -0000

+1

Igor

On 3/20/2012 6:52 AM, Harald Alvestrand wrote:
> I believe I have said this before, but...
>
> We should never tell the user the connection is secure.
> We should tell the user when we know he's exposed to risks that he 
> usually isn't.
>
> Thus - we should not give any indication that we're using DTLS-SRTP 
> with verified identities (if that's what we normally support). We 
> SHOULD give a warning saying "hey, since the gateway you've connected 
> to isn't doing normal authentication procedures, but instead insists 
> on exchanging keys on the signalling channel, you are less sure who 
> you're talking to than usual, and there are more boxes that might 
> record your call in the way, but the script kiddie on your hotel WLAN 
> still can't see your packets (translation: legacy SDES key exchange is 
> in use, but SRTP is still on).
>
> All this will of course be iconified into a single cryptic graphic 
> probably involving a padlock :-)
>
> On 03/19/2012 07:47 PM, Igor Faynberg wrote:
>> This is the question that I have been asking for a while...  I don't 
>> expect a complete fireproof answer, of course, and I also understand 
>> that the browser today is telling me a few things about the security 
>> of a site and warns me when "the site is trying to access the data it 
>> should not be accessing."
>>
>> But I  also imagine that a rogue site could display a message 
>> mimicking the security assurance as though it comes from the browser.
>>
>> So it would be good to have a very clear idea when  the determination 
>> about the security of the connection and such is made and how the end 
>> user can verify that it actually comes from the browser.
>>
>> (To this end, the user MUST trust the browser, of course.)
>>
>> Igor
>>
>> On 3/19/2012 2:15 PM, Roman Shpount wrote:
>>> I guess my question is, when are we going to tell the user that 
>>> connection is "secure"?...
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>

v2.23.0 | Report a Bug | By Email