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

Dave Garrett <davemgarrett@gmail.com> Fri, 28 August 2015 16:13 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E37EC1A1AA6 for <tls@ietfa.amsl.com>; Fri, 28 Aug 2015 09:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id k8yWwnXMwODW for <tls@ietfa.amsl.com>; Fri, 28 Aug 2015 09:13:06 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CF01A03E3 for <tls@ietf.org>; Fri, 28 Aug 2015 09:13:06 -0700 (PDT)
Received: by qkfh127 with SMTP id h127so31043334qkf.1 for <tls@ietf.org>; Fri, 28 Aug 2015 09:13:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=7NOdRygUsKsYn34zvm4ZM+e3q+xWkNUkl8fcQv0/FMo=; b=W+Tft7i34c9fCEq7eZglZ7rwnrp0OCCBgmkE4tbkGUlB4vQOtMJj118DsvGQJoz8v0 UsJ/bDB6TUlyn4TEviSc3kYc9KRvAjlxEwHGZtMyPOYUM6h8s8X13vmCyWd+21uG+2BE ELv79qBJQ4XDP6oCfa6NPUfyZF1nsHGA6izGJtnaToXVjCLNzFqkzwREc1YxB+gkBbn0 9c5m5LNLjp78H7H5NFHE+mZXbRdLJtUh0nbZ4Pymw8nO/1QheLE6ikxPjF85LHWwJ30s byAGZjstNlL0a0LnuuaDJN6Cy+DX2bMDs74fJyTRYG9OQjbZR6YfMSH91OdAcR5J5E+3 +ihQ==
X-Received: by with SMTP id z76mr17345773qkz.32.1440778385432; Fri, 28 Aug 2015 09:13:05 -0700 (PDT)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. []) by smtp.gmail.com with ESMTPSA id g49sm3693349qgf.29.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 28 Aug 2015 09:13:04 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Fri, 28 Aug 2015 12:13:03 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CAL6x8mchyh2Qpqcd5Rv-rXgZ+1_CAbV7vkib+-yU4DEDFx82Yg@mail.gmail.com> <CAL6x8mfDjYAhOwvBY-tFO-407E9U+SaknJnuh_dCEEUbWJZZWw@mail.gmail.com> <20150828144932.GH9021@mournblade.imrryr.org>
In-Reply-To: <20150828144932.GH9021@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201508281213.03823.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/oqCzWR8N9FIKKltiXfA65W01NGE>
Subject: [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
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:13:08 -0000

On Friday, August 28, 2015 11:08:35 am Salz, Rich wrote:
> Having discussions through github is a really bad idea.

You're right. I posted a stupidly long side-note in there. I intended to bring it to the list too, which I'll do now.

On Friday, August 28, 2015 10:49:33 am Viktor Dukhovni wrote:
> It seems that with TLS 1.3 the client MUST send SNI, presumably in
> the clear.  Typically there's not much else of interest in the
> server certificate to hide.  I don't see a realistic way to hide
> the server identity even from passive wiretap via TLS.

Currently, we're at implementations MUST support (not necessarily send) SNI, servers MAY require it, and servers SHOULD error on such a failed requirement. This doesn't change the status quo much. If servers don't require it, you don't need to send it. HTTP/2 has its own SNI requirement, though, so lots of TLS will be moving in that direction.

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.

The simplest route that would allow for encrypted SNI with 0-RTT application data allowed would be to just add a second long-term DH key to the server config for SNI (and an option for servers to have one do both if they don't need two). Seeing as this would still need to be opt-in via a flag in the config, we could use the same extension ID and just encrypt it using the second key. Servers that provide an SNI key get encrypted; others get clear or none.

If we can also get a way to distribute server config out-of-band, this would even allow initial-connection SNI encryption.

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. Now, with that said, you could just create a way for any client to ask a server for its config without any attempt to connect right away, in which case it can follow up with encrypted SNI at the cost of that 1-RTT (e.g. the QUIC way of doing things). Even if we allow ServerConfiguration to be optional normally, we could add this config request mode and make support for that mandatory (though, potentially with short-lived keys). This route would still require some prior information about this server: knowledge that it could request a key for SNI at all without just getting rejected. Doing so without that would require a multiple attempt check of some kind that's probably a bad idea.