Re: [TLS] SNI and Resumption/0-RTT

Christian Huitema <huitema@huitema.net> Fri, 21 October 2016 15:43 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F231293E9 for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 08:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq_M8JsCn5tQ for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 08:43:11 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4D11295C9 for <tls@ietf.org>; Fri, 21 Oct 2016 08:43:11 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1bxbyP-00028x-B7 for tls@ietf.org; Fri, 21 Oct 2016 17:43:10 +0200
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1bxbyK-0007YE-UK for tls@ietf.org; Fri, 21 Oct 2016 11:43:08 -0400
Received: (qmail 24165 invoked from network); 21 Oct 2016 15:43:03 -0000
Received: from unknown (HELO [10.10.6.107]) (Authenticated-user:_huitema@huitema.net@[207.170.229.107]) (envelope-sender <huitema@huitema.net>) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 21 Oct 2016 15:43:03 -0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (14A456)
In-Reply-To: <20161021151442.GA9003@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Fri, 21 Oct 2016 08:42:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E570F74-46B8-4B1D-A3FF-951238A3824F@huitema.net>
References: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com> <BY1PR0301MB08382DA7C63232F9DD074D548CD40@BY1PR0301MB0838.namprd03.prod.outlook.com> <CABcZeBO2j+E6MOBQJgpRAcMsLj_72cU-W1q783D9ubZLEPBt=A@mail.gmail.com> <BY1PR0301MB0838DB70AF5B4667F9B1C3E98CD40@BY1PR0301MB0838.namprd03.prod.outlook.com> <CABcZeBMWR7apyb9zMsdOJgrWrdjs7-uKe7hzCgZ97o_VUzSH0w@mail.gmail.com> <CABkgnnUv8d6A47+woqwcvc99fNjXohwsV7kxB=GJyVyqU+Nuyg@mail.gmail.com> <20161021144238.GA8516@LK-Perkele-V2.elisa-laajakaista.fi> <24D2F095-CC7C-4C0F-8501-3467CA5703CD@huitema.net> <20161021151442.GA9003@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dP6iToxOOfkkkKBkEi+o3RqBn9PDoOhj/xzb7kHn/aQhIMekNi8AbP1K8LEdFLG4hjMN uobEWnyCepw9YP8m35ak2VYwN59oO6WH87YCmRSlGlugeeYNRP+TKatltgBEa09tg6wnJ2lrZSUC ZrKFYsHubplnbiDyBMUiEvUZuPnV+6xPoqikFlxGE5ethSvjIJZI+lxcZnIhduMqXEDVCZfDqcig OvSxdRnthmhn8Zn6/mJzKVdFu79dud0anUTz61PsH1QqniimNy9qh2Eko/GUK0vciBekfU6mwXfa SylR/WRbdco3pKNX9x7s84ASzhMKuUeqX+EE9ftsEQ35CMRUE7Q9WvntXa9VPL9K4cA+8t3Xj/Lz Z5s/OJg1L2asZxEp4Bv7TWEUoKzFQfrYUezLRF4P3cD+yYsyYy0PbXJivfXYa4zafYJGo76gRHJN CirkfYeKydSIUY0HOcUIkoQwERtQftX4sSMByQEeoQjUACMyE+XhWF028w059hjlWNOITDa6LxNU +V0EKPyMEBMfFwR5hdoSHsinycGYjNdnlrtXw1c9IHjJjxHw61Bw8RquN6UIEUbDp4qQeYkcvTCl J+6wa7BDiaF6UX6W4Pbk
X-Report-Abuse-To: spam@mx99.antispamcloud.com
X-Originating-IP: 168.144.250.245
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.21)
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CcYIahQd8ZGNeZJBxhqnO6ss4NI>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] SNI and Resumption/0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2016 15:43:12 -0000

I mentioned obfuscation as one possible solution. I know that I can make it work for small scale servers, e.g., up to a few hundreds registered clients. But if we can achieve the same privacy results with some mechanisms using dynamic certificates, that's fine too. My only point is, please don't forbid future privacy enhancement with a hard rule on SNI. Maybe something like "should use the same SNI, but may use different ones if client and server agree on an SNI privacy scheme."

-- Christian Huitema 

> On Oct 21, 2016, at 8:14 AM, Ilari Liusvaara <ilariliusvaara@welho.com>; wrote:
> 
>> On Fri, Oct 21, 2016 at 07:58:57AM -0700, Christian Huitema wrote:
>> I am a bit worried about privacy implications of the SNI. Suppose
>> that we invent an obfuscation mechanism that prevents third parties
>> to track which service corresponds to an SNI string. The SNI would
>> then be different for any connection, including resumptions. Do we
>> want to prevent that with a hard rule in the spec?
> 
> Such mechanism on TLS level would be pretty hard to do. You can't do
> any sort of static encryption or obfustication for instance (because
> that would be trivially attackable).
> 
> 
> Much more feasible to have application layer (with possibly TLS protocol
> support) way of sending new server certificates in the fly (post-
> handshake auth, but with servers).
> 
> (It seems to me that due to the roles of HTTP clients and servers, post-
> handshake server auth is a lot less scary than post-handshake client
> auth).
> 
> 
> -Ilari