Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 28 August 2015 16:22 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037751A1B8B for <tls@ietfa.amsl.com>; Fri, 28 Aug 2015 09:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 rs0Lhb5Jbkp0 for <tls@ietfa.amsl.com>; Fri, 28 Aug 2015 09:22:53 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB931A1B88 for <tls@ietf.org>; Fri, 28 Aug 2015 09:22:53 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1BE33284D24; Fri, 28 Aug 2015 16:22:52 +0000 (UTC)
Date: Fri, 28 Aug 2015 16:22:52 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150828162251.GM9021@mournblade.imrryr.org>
References: <CAL6x8mchyh2Qpqcd5Rv-rXgZ+1_CAbV7vkib+-yU4DEDFx82Yg@mail.gmail.com> <CAL6x8mfDjYAhOwvBY-tFO-407E9U+SaknJnuh_dCEEUbWJZZWw@mail.gmail.com> <20150828144932.GH9021@mournblade.imrryr.org> <201508281213.03823.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201508281213.03823.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qWj9hthxAzuXodulqRj3_NrgiUo>
Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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, 28 Aug 2015 16:22:55 -0000

On Fri, Aug 28, 2015 at 12:13:03PM -0400, Dave Garrett wrote:

> The idea I had the other day is that we can technically do SNI encryption
> with the current TLS 1.3 draft, as-is. All that needs to really be done
> is stick it in a 0-RTT EncryptedExtensions, preferably only when the server
> specifies that it is allowed via adding a flag to server config. This
> would require the actual server share the 0-RTT DH key across the virtual
> servers it's picking via SNI, so early data probably should be off in this
> instance for many use-cases.

So the client would now need to cache some session data by transport
address, and other data by name and port.  That's rather complex.
And how often will the same client visit multiple servers at the
same transport address?

I don't really see this as viable or worth the effort.

> I don't think encrypted SNI to servers without any prior information is
> really that viable, and that's been said before by others on this list.

I don't think SNI hiding is viable without encryption at the
transport or network layers.  And there's still a metadata leak
via DNS which may prove difficult to address.

-- 
	Viktor.