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

Christian Huitema <huitema@huitema.net> Fri, 21 October 2016 14:59 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 CA62E12952C for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 07:59:09 -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 fCB10Ah8ppBl for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 07:59:08 -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 F1258129529 for <tls@ietf.org>; Fri, 21 Oct 2016 07:59:07 -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 1bxbHl-0002QM-VF for tls@ietf.org; Fri, 21 Oct 2016 16:59:07 +0200
Received: from [10.5.2.17] (helo=xmail07.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 1bxbHh-0004Su-E9 for tls@ietf.org; Fri, 21 Oct 2016 10:59:05 -0400
Received: (qmail 9310 invoked from network); 21 Oct 2016 14:59:00 -0000
Received: from unknown (HELO [100.192.24.228]) (Authenticated-user:_huitema@huitema.net@[172.56.42.110]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 21 Oct 2016 14:59:00 -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: <20161021144238.GA8516@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Fri, 21 Oct 2016 07:58:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <24D2F095-CC7C-4C0F-8501-3467CA5703CD@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>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dP6iToxOOfkkkKBkEi+o3RqBn9PDoOhj/xzb7kHn/aQhIMekNi8AbP1K8LEdFLG4hpdN 8TDNo/7DaoPreqWbH4yb9oylgW8YJxpG8H8ivjVgGlugeeYNRP+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.18)
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KW1it1cxuKUaODgFpvM4Jq_2xws>
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 14:59:10 -0000

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?

-- Christian Huitema 

> On Oct 21, 2016, at 7:42 AM, Ilari Liusvaara <ilariliusvaara@welho.com>; wrote:
> 
>> On Fri, Oct 21, 2016 at 12:38:29PM +1100, Martin Thomson wrote:
>> So I think that the problem could be reduced in complexity.  A little
>> at least.  The obvious consequence of changing SNI is that you end up
>> somewhere different than last time.  But we can still ensure that the
>> connection is to the same peer.
> 
> You _might_ end up somewhere different. And even with the same SNI, you
> can still end up to different server in the same "group". And different
> SNI names can still get you to the same actual place.
> 
>> If the server remembered which certificate it used, and insisted that
>> THAT remain constant, then you could take a different SNI from - for
>> example - a subjectAltName.  Provided that the routing works out, you
>> might still get the same certificate.
>> 
>> I mean, the point of SNI is to route to the right configuration.
>> Changing name messes with resumption in that you want to make sure
>> that you end up in a place that has the resumption secret.  But if you
>> end up at the wrong server, you either fail to resume, or fail to
>> connect on the normal terms of the protocol.
> 
> There are three tasks of SNI:
> 
> - Routing to the correct server. Sometimes this routing is performed by
>  middleboxes (yay, middleboxes!).
> - The certificate selection within the server.
> - Set application instance, if the protocol can't do this in-band (but
>  if it does, applications generally override this with in-band value).
> 
> And I would expect the servers to actually look at the PSKs offered and
> not blindly trying to use one, so if connection is routed wrong, I would
> expect fallback to the usual DH-CERT handshake.
> 
>> The only thing that could screw this all up is if we end up in a
>> situation where one or other peer is confused about either its own
>> identity, the identity of its peer, or the identity (-ies) that it
>> believes it peer has for itself.  However, with certificate stability
>> rather than name stability I don't think we are worse off than with -
>> say - a wildcard cert.
> 
> I would expect such confusion about own identity to be pretty much the
> norm for HTTP servers. And those are frequently used in ways that tend
> to amplify even a small errors to serious attacks.
> 
> For other types of servers, I would expect any confusion resulting in
> security problems to be pretty rare.
> 
> But since HTTP is very important usecase, this impiles that the client
> shouldn't attempt to use PSKs when such confusion could create security
> issues.
> 
>> I agree that the add-a-name stuff makes this harder.  A co-tenanted
>> server with resumption keys across a bunch of names risks confusing
>> itself if it allows resumption across certificates, depending on how
>> much state it carries from the old session.  In doing add-a-name, then
>> we need to be careful about that, but that's a problem for those of us
>> who want to do add-a-name.
> 
> You can already get such confusion with wildcard certificates, no
> changes needed.. 
> 
> 
> -Ilari
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls