Re: [rtcweb] Encryption mandate

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 08 September 2011 16:00 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 A544B21F87D9 for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 09:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level:
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599]
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 sblfvu7h8584 for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 09:00:26 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id C02C021F85BB for <rtcweb@ietf.org>; Thu, 8 Sep 2011 09:00:25 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta10.westchester.pa.mail.comcast.net with comcast id WFs01h0040SCNGk5AG2JfH; Thu, 08 Sep 2011 16:02:19 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta09.westchester.pa.mail.comcast.net with comcast id WG2H1h00D0tdiYw3VG2H5a; Thu, 08 Sep 2011 16:02:18 +0000
Message-ID: <4E68E72C.3080403@alum.mit.edu>
Date: Thu, 08 Sep 2011 12:02:52 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <E4EC1B17-0CC4-4F79-96DD-84E589FCC4F0@edvina.net> <4E67C3F7.7020304@jesup.org> <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> <4E67F296.3020007@jesup.org> <E2918193-C792-4701-9838-0739D7CA0FD3@edvina.net> <4E685ED0.3010602@jesup.org>
In-Reply-To: <4E685ED0.3010602@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Encryption mandate
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, 08 Sep 2011 16:00:26 -0000

On 9/8/11 2:21 AM, Randell Jesup wrote:
> On 9/8/2011 1:43 AM, Olle E. Johansson wrote:
>>
>>>> 7 sep 2011 kl. 21:20 skrev Randell Jesup:
>>>>
>>>>> Signalling is secure, so it could even use a direct optional
>>>>> downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp
>>>>> draft)
>>>> How can you assert that signalling is secure? When, how?
>>> I'm assuming the signalling is occurring as SIP over an HTTPS
>>> connection to the server, or SIP-over-TLS - haven't really given it a
>>> lot of thought other than this connection is securable is we start
>>> with an HTTPS connection to the server.
>> That only guarantees confidentiality the first hop of signalling,
>> provided that the TLS certificates was properly verified. That's a
>> long way from assuming that signalling is secure.
>>
>
> Well, as this is rtcweb, the application knows it's talking to the
> service associated with the app directly, so there should be no
> intermediaries in the SIP fashion between the app and the service it
> provides. I hadn't meant to have my statement apply to "federated"
> connections between services, which is where your objection would
> primarily come in.

How would a user know whether the service he is using is federated or not?

E.g. it may be possible for one user of a service to configure "call 
forwarding" using federation. Other users of the service will not 
necessarily know if they are talking to a user that has federation enabled.

	Thanks,
	Paul


  (There is the issue of "can someone spoof
> https://foo.com/"quot;; the answer *should* be no, and if so then that first
> hop is secure).
>
> But this may be moot anyways given my response to Jonathan Lennox on
> this topic about Cap-Neg (shudder).
>