IETF Logo Mail Archive

Re: [TLS] "Encrypted" SNI

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 10 May 2017 19:04 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 26BC3126C23 for <tls@ietfa.amsl.com>; Wed, 10 May 2017 12:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 W3TJrckPISTZ for <tls@ietfa.amsl.com>; Wed, 10 May 2017 12:04:55 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BC91267BB for <tls@ietf.org>; Wed, 10 May 2017 12:04:54 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 1314A7A32F1 for <tls@ietf.org>; Wed, 10 May 2017 19:04:54 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <2478514.aZun5FUmZT@pintsize.usersys.redhat.com>
Date: Wed, 10 May 2017 15:04:53 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org>
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org> <2478514.aZun5FUmZT@pintsize.usersys.redhat.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/py3iND5r4fmgBEIRXrP69B94PO8>
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 19:04:56 -0000

> 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.

Encryption means key agreement, and requires delaying SNI by a round-trip,
or having published DH shares in DNS, which of course also needs privacy
protection for SNI encryption to matter.

I do believe this was discussed at some length previously.

-- 
-- 
	Viktor.

v2.23.0 | Report a Bug | By Email