Re: [TLS] "Encrypted" SNI

Brian Sniffen <bsniffen@akamai.com> Thu, 11 May 2017 14:38 UTC

Return-Path: <bsniffen@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 E85B9127B5A for <tls@ietfa.amsl.com>; Thu, 11 May 2017 07:38:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.803
X-Spam-Level:
X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0FLRU_2XI8An for <tls@ietfa.amsl.com>; Thu, 11 May 2017 07:38:09 -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 C775713147C for <tls@ietf.org>; Thu, 11 May 2017 07:31:27 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5A3C4200019; Thu, 11 May 2017 14:31:27 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 43DCA200008; Thu, 11 May 2017 14:31:27 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1494513087; bh=W38lspmMkOzfzN9v7kzes6QJJDrIjis/q3yZ2UG6fNU=; l=1412; h=From:To:In-Reply-To:References:Date:From; b=CFeDV65Pon+P1uiwQlnXXGov9F/PtY0J9OjN3LteN9r5NimQcH2rXPuPhytu/UPfK HaQ5YvWV/nfJG6kUkrnZZZBHRgB1lFtW8fDyzyvTmRXaGajxfbh0ahJwuR7QAuiAJr qQb1q/Tm/2eEvyGDIXCIfemEHEcCe+/781kxDbbg=
Received: from Tereva.local (unknown [172.19.40.142]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id DFE2A1E07C; Thu, 11 May 2017 14:31:26 +0000 (GMT)
From: Brian Sniffen <bsniffen@akamai.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Christian Huitema <huitema@huitema.net>, tls@ietf.org
In-Reply-To: <87ziekihp6.fsf@fifthhorseman.net>
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> <87ziekihp6.fsf@fifthhorseman.net>
Date: Thu, 11 May 2017 10:31:26 -0400
Message-ID: <m28tm34g8x.fsf@abstraction.kendall.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3nb-FIhKXgW2vRnGaGzAV73iROg>
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 14:38:11 -0000

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
>> 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?
>
> I agree with Christian's assessment of the problem, and i'd be
> interested in collaborating on such a draft.

Who's the audience for that draft?  If it's meant to document the blind
alleys we've found, perhaps we could list both alleys, and the walls at
the end:

  - hash the name [adversaries can hash too]
  - hash the name with a salt [adversaries can check the salted hash
    too, as if operating all the banned sites]
  - encrypt the SNI under the pre-shared key

But beware of:

  - the adversary can replay this SNI and see what site he gets
  - DDoS risk: servers can't be try lots of crypto (no asymmetric ops,
    no operations that scale linearly with number of sites hosted)
  - not everybody's going to do this, not even every TLS 1.3 instance
  - if networks can't track activity, some will push users to stay on
    TLS 1.2.

-Brian

-- 
Brian Sniffen
Akamai Technologies