IETF Logo Mail Archive

Re: [TLS] "Encrypted" SNI

Hubert Kario <hkario@redhat.com> Thu, 11 May 2017 11:11 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 6CC4512EC3D for <tls@ietfa.amsl.com>; Thu, 11 May 2017 04:11:06 -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 ch43Yd9XJq8R for <tls@ietfa.amsl.com>; Thu, 11 May 2017 04:11:05 -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 60B8F12EC40 for <tls@ietf.org>; Thu, 11 May 2017 04:08:48 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 480427F7AE; Thu, 11 May 2017 10:58:29 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 480427F7AE
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 480427F7AE
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 F05125C8AE; Thu, 11 May 2017 10:58:28 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Thu, 11 May 2017 12:58:21 +0200
Message-ID: <2045926.sutFeuuH9X@pintsize.usersys.redhat.com>
In-Reply-To: <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <2478514.aZun5FUmZT@pintsize.usersys.redhat.com> <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart14513970.6hmDUg8LNm"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 11 May 2017 10:58:29 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Z6nvSlCSu03gOZdUOn0nXP8BldM>
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: Thu, 11 May 2017 11:11:07 -0000

On Wednesday, 10 May 2017 21:04:53 CEST Viktor Dukhovni wrote:
> > On May 10, 2017, at 2:47 PM, Hubert Kario <hkario@redhat.com> wrote:
> > 
> > But in general, I wonder if we didn't approach the SNI from the wrong side
> > - as I said, we may not need to encrypt it, we just make sure that client
> > and server agree on the virtual host the connection is going to.
> 
> They can do that with a name in the clear.  If the name is to be hidden
> from passive observers, then you do need encryption so that only the
> client and server, and not the passive observers, can recover the name.

You are going in the exact direction I'm saying we should not go, for the same 
reason you said:

> I do believe this was discussed at some length previously.

There are multiple schemes that allow the peers to make sure that both of them 
mean X without outright saying "X". Salting and hashing is one, including it 
in key exchange, (SRP style) is another.
-- 
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