IETF Logo Mail Archive

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

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 21 October 2016 15:15 UTC

Return-Path: <ilariliusvaara@welho.com>
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 6320412955B for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 08:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] 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 b_OsK4nUGbXj for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 08:14:59 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8201294B2 for <tls@ietf.org>; Fri, 21 Oct 2016 08:14:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 33E7B13966; Fri, 21 Oct 2016 18:14:50 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id qRho6HVAKgU5; Fri, 21 Oct 2016 18:14:50 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id EC62227F; Fri, 21 Oct 2016 18:14:49 +0300 (EEST)
Date: Fri, 21 Oct 2016 18:14:42 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Christian Huitema <huitema@huitema.net>
Message-ID: <20161021151442.GA9003@LK-Perkele-V2.elisa-laajakaista.fi>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <24D2F095-CC7C-4C0F-8501-3467CA5703CD@huitema.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gGnL08fEfSPpC-lKPHaWAHP8_9I>
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:15:02 -0000

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

v2.23.0 | Report a Bug | By Email