Re: [rtcweb] Encryption mandate

Randell Jesup <randell-ietf@jesup.org> Thu, 08 September 2011 06:22 UTC

Return-Path: <randell-ietf@jesup.org>
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 97A5921F8C40 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 23:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4B3fj+5dTznH for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 23:22:08 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C40EB21F8C11 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 23:22:08 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R1Y1n-0005eK-5D; Thu, 08 Sep 2011 01:23:59 -0500
Message-ID: <4E685ED0.3010602@jesup.org>
Date: Thu, 08 Sep 2011 02:21:04 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: "Olle E. Johansson" <oej@edvina.net>
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>
In-Reply-To: <E2918193-C792-4701-9838-0739D7CA0FD3@edvina.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: rtcweb@ietf.org
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 06:22:09 -0000

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.  (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).

-- 
Randell Jesup
randell-ietf@jesup.org