IETF Logo Mail Archive

Re: [TLS] "Encrypted" SNI

Roland Zink <roland@zinks.de> Wed, 10 May 2017 21:40 UTC

Return-Path: <roland@zinks.de>
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 0452C1294AB for <tls@ietfa.amsl.com>; Wed, 10 May 2017 14:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level:
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 nXsmxvnXal_a for <tls@ietfa.amsl.com>; Wed, 10 May 2017 14:40:18 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (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 6B25C128DF3 for <tls@ietf.org>; Wed, 10 May 2017 14:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494452416; l=3533; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=l0kUKntxWwDXkkAsjuFGtqnwTM8eAxq4tkOQrgZUJkE=; b=W3DhWT4Tdz7USPPm1Juy5itkFbsWlWH8VRpUp88NFlQybyxZLWNf/4dqJtbNFAiZRv ioUT6M8bQiYJnU/Y5F9eFulkqWzAohZypTBtzPpD4dyfGYIHPQNgsUCoqvdX/4We3l/t 1SQ1uCt8RGE/Je32cFKM/3C3fi1po08GWwNgw=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyIweUns/Oqm8M2XeLgRv9qu3DB7g==
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2001:4dd0:ff67:0:9c05:2dc6:bb3c:d4e3] ([2001:4dd0:ff67:0:9c05:2dc6:bb3c:d4e3]) by smtp.strato.de (RZmta 40.6 AUTH) with ESMTPSA id 608061t4ALeFUvU (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <tls@ietf.org>; Wed, 10 May 2017 23:40:15 +0200 (CEST)
To: tls@ietf.org
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <a6029246-46f6-d698-983f-b668d70e2780@zinks.de>
Date: Wed, 10 May 2017 23:40:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>
Content-Type: multipart/alternative; boundary="------------2FE4FA50E007C1BDCD8DF731"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DRRsSPZVF1eQ0v7s17YOVKIzIGc>
Subject: Re: [TLS] "Encrypted" SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 10 May 2017 21:40:21 -0000

The SNI extension is optional, so you don't have to send the literal 
value. Indeed quite some number of apps do not send it. Browsers 
currently can't know if the SNI is required by the origin servers and 
usually send this, but there could be some signal to not send it. One 
example could be a HTTP header to tell the browser that SNI should be 
send and if it isn't present then no SNI is send. Unfortunately this 
would break current sites but still it can be done the other way around 
e.g. send a header to not send SNI.

Regards,

Roland


Am 10.05.2017 um 19:28 schrieb Hubert Kario:
> Yes, encrypted SNI was discussed and ultimately rejected.
>
> But do we really have to send the literal value? Don't we need to just make
> sure that the client and server agree on the host that the client wants to
> connect?
>
> Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending
> the salt and the resulting hash, making the server calculate the same hash
> with each of the virtual host names it supports and comparing with the client
> provided value?
>
> (apologies if that was already proposed and rejected)
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email