Re: [TLS] New Draft: Using DNS to set the SNI explicitly

mrex@sap.com (Martin Rex) Thu, 09 March 2017 10:52 UTC

Return-Path: <mrex@sap.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 3C34212943F for <tls@ietfa.amsl.com>; Thu, 9 Mar 2017 02:52:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 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, 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 XRdUO9FPAZwC for <tls@ietfa.amsl.com>; Thu, 9 Mar 2017 02:52:10 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438881294FD for <tls@ietf.org>; Thu, 9 Mar 2017 02:52:10 -0800 (PST)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3vf6fJ0mbNz1J3m; Thu, 9 Mar 2017 11:52:08 +0100 (CET)
X-purgate-ID: 152705::1489056728-0000521C-3B25422C/0/0
X-purgate-size: 1000
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3vf6fH5HVBzGpGB; Thu, 9 Mar 2017 11:52:07 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A93041A63F; Thu, 9 Mar 2017 11:52:07 +0100 (CET)
In-Reply-To: <CAHbrMsCpCH2qSG=cZjMMuWbpzCn8dQhvaTDaRc1riwnYiKGjsg@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Date: Thu, 9 Mar 2017 11:52:07 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170309105207.A93041A63F@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BoJAL7R-tdVWcgYZTRPO13ibres>
Cc: tls@ietf.org
Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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, 09 Mar 2017 10:52:12 -0000

Ben Schwartz wrote:
> 
> Like a lot of people here, I'm very interested in ways to reduce the
> leakage of users' destinations in the ClientHello's cleartext SNI.  It
> seems like the past and current proposals to fix the leak are pretty
> difficult, involving a lot of careful cryptography and changes to clients
> and servers.

It is formally provable that there is no solution to the problem
that you're describing.

While you can come up with all kinds of fancy and complicated schemes
that are sufficient to provide you the illusion that you're looking for,
the best you can come up with, will *be* an illusion.  But some of
those illusions will cause lots of pain for implementors and make
the whole thing fragile and cause interop problems.

The situation is pretty similar for the hiding of the ContentType
in TLSv1.3 records.  It is formally provable that this can not provide
value, but it make implementations harder and reliably break some
existing stuff.

-Martin