Re: [TLS] "Encrypted" SNI

Benjamin Kaduk <bkaduk@akamai.com> Wed, 10 May 2017 19:15 UTC

Return-Path: <bkaduk@akamai.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 0DB3112EA59 for <tls@ietfa.amsl.com>; Wed, 10 May 2017 12:15:05 -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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 Hx-CZ61-lbIh for <tls@ietfa.amsl.com>; Wed, 10 May 2017 12:15:04 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id CFFE112EA74 for <tls@ietf.org>; Wed, 10 May 2017 12:15:03 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 861ED200041; Wed, 10 May 2017 19:15:03 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 66AD7200014; Wed, 10 May 2017 19:15:03 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1494443703; bh=EDBAKLIRl+cTq50pa2dKz98glpwOW4WT+olWCVzS88M=; l=4151; h=To:References:From:Date:In-Reply-To:From; b=YvqqHKkj1Y/CMiyJNoYBzwe0kmgEmmS165rg9pj7dLtln8+hbCavWnRmxqsn7AcvN rydTQBNIBlhLBHdC9ARsWygDOS8N79h0PoW1rmN4mmIefM98VmBmZ1Qw/OWpdBhL5E Fu+psm4K0DhwVpBWLnQ6CqNCtI0LoNKWp80lSTLA=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 1951B98084; Wed, 10 May 2017 19:15:03 +0000 (GMT)
To: Christian Huitema <huitema@huitema.net>, tls@ietf.org
References: <3768598.32hupQ9b2b@pintsize.usersys.redhat.com> <5920A6B3-66F5-44D5-A367-82AD6431A6C4@dukhovni.org> <2478514.aZun5FUmZT@pintsize.usersys.redhat.com> <20865FC2-A021-4EAC-ACDA-E400855B5CE0@dukhovni.org> <b117285e-4820-3ed8-9eb8-0f0d09e17f09@huitema.net>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <326d4637-cb99-4892-4c82-ce5d52b0b4a0@akamai.com>
Date: Wed, 10 May 2017 14:15:01 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <b117285e-4820-3ed8-9eb8-0f0d09e17f09@huitema.net>
Content-Type: multipart/alternative; boundary="------------0B2B124A08EC47BD92585162"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UY4NFBViNRc1PX4UXPxDsVRuJrA>
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:15:05 -0000

On 05/10/2017 02:12 PM, Christian Huitema wrote:
>
> On 5/10/2017 12:04 PM, 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.
>>
>> 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.
> It certainly was. But then the clear text SNI is a gaping privacy hole
> in TLS, the kind of issue that should keep us awake at night until it is
> resolved. We need to make sure that we make progress, rather than rehash
> the old arguments. Maybe we should invest some time and document the
> various proposals in a draft. I am willing to work on that. Any other
> volunteers?
>

It seems like there are a number of ways to encrypt the SNI for the
*second* (and subsequent) exchange with a given server; I have one that
I have some notes on and might try to write up.  But do we think that's
worth doing, or do we want to also provide protection for the initial
contact?  It seems like there is a qualitative difference, there...

-Ben