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, 09 Mar 2017 11:52:07 +0100
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
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
- [TLS] New Draft: Using DNS to set the SNI explici… Ben Schwartz
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ilari Liusvaara
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Salz, Rich
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ben Schwartz
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ben Schwartz
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Christian Huitema
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Salz, Rich
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ben Schwartz
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Yoav Nir
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Richard Barnes
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ben Schwartz
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ben Schwartz
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ben Schwartz
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Martin Rex
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ben Schwartz
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Martin Rex
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ilari Liusvaara
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Martin Rex
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ryan Sleevi
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Ilari Liusvaara
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Viktor Dukhovni
- Re: [TLS] New Draft: Using DNS to set the SNI exp… Dave Garrett