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.