IETF Logo Mail Archive

[TLS] "Encrypted" SNI

Hubert Kario <hkario@redhat.com> Wed, 10 May 2017 17:29 UTC

Return-Path: <hkario@redhat.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 A144C129461 for <tls@ietfa.amsl.com>; Wed, 10 May 2017 10:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level:
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 ibEJcOnpntF5 for <tls@ietfa.amsl.com>; Wed, 10 May 2017 10:29:00 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC3212420B for <tls@ietf.org>; Wed, 10 May 2017 10:29:00 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DA75063142 for <tls@ietf.org>; Wed, 10 May 2017 17:28:59 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DA75063142
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DA75063142
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A75CE17962 for <tls@ietf.org>; Wed, 10 May 2017 17:28:59 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Wed, 10 May 2017 19:28:51 +0200
Message-ID: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2545833.bSing3hz15"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 10 May 2017 17:29:00 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1teN2SJiyTa-JimfcOFgPlCaMQ0>
Subject: [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 17:29:02 -0000

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)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

v2.23.0 | Report a Bug | By Email