Re: [TLS] Alternative ESNI?
Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 18 December 2018 02:47 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 B978F130FD0 for <tls@ietfa.amsl.com>; Mon, 17 Dec 2018 18:47:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 C2ndU03Ox5Fx for <tls@ietfa.amsl.com>; Mon, 17 Dec 2018 18:47:25 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796B8130FC7 for <tls@ietf.org>; Mon, 17 Dec 2018 18:47:25 -0800 (PST)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 4288B159D6 for <tls@ietf.org>; Mon, 17 Dec 2018 21:47:24 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <3e297d53-9125-98f8-e4db-ef82640e91de@cs.tcd.ie>
Date: Mon, 17 Dec 2018 21:47:22 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: IETF TLS WG <tls@ietf.org>
Message-Id: <6710FEFC-8632-400E-A03B-0140724361C8@dukhovni.org>
References: <20181215025346.GJ15561@localhost> <d297696e-5199-779a-697c-a5c3249555f2@cs.tcd.ie> <20181217233313.GL15561@localhost> <3e297d53-9125-98f8-e4db-ef82640e91de@cs.tcd.ie>
To: IETF TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HXUaUOUJA28rbOxFjKTixGBG92s>
Subject: Re: [TLS] Alternative ESNI?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 18 Dec 2018 02:47:28 -0000
> On Dec 17, 2018, at 8:58 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > That said, I'd bet we're all generally unkeen on "do both" but > maybe the above-mentioned PR avoids that by casting the HRR-mode > as way to better handle a likely operational failure mode. I guess the reason I started thinking along the lines of the alternative proposal is because it would doing it *at all* might be too complex for many sites, and privacy protection that is mostly not deployed is then not very effective. Thus, instead of trying to work around glitches caused by key management glitches, my thinking was to avoid them entirely, by using ephemeral keys. I don't dispute the obstacles: * Additional round-trip for full handshakes. * Possible middle-box concerns that I can't speak to. The potential upside is: * Supports stable local policy (no keys, means client used by users with critical need can have a static fronting server config). * Better forward secrecy. * Much simpler operationally, so could have much broader deployment. I'll take a look at David Benjamin's PR, to see whether it resolves any of the motivating reasons for the alternative... -- Viktor.
- [TLS] Alternative ESNI? Nico Williams
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Nico Williams
- Re: [TLS] Alternative ESNI? Stephen Farrell
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Viktor Dukhovni
- Re: [TLS] Alternative ESNI? Stephen Farrell
- Re: [TLS] Alternative ESNI? Viktor Dukhovni
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Paul Wouters
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Nico Williams
- Re: [TLS] Alternative ESNI? Stephen Farrell
- Re: [TLS] Alternative ESNI? Viktor Dukhovni
- Re: [TLS] Alternative ESNI? Nico Williams
- Re: [TLS] Alternative ESNI? Nico Williams
- Re: [TLS] Alternative ESNI? Kathleen Moriarty
- Re: [TLS] Alternative ESNI? Eric Rescorla
- Re: [TLS] Alternative ESNI? Viktor Dukhovni
- Re: [TLS] Alternative ESNI? Kathleen Moriarty