Re: [TLS] Fwd: New Version Notification for draft-schwartz-tls-lb-00.txt

"Martin Thomson" <mt@lowentropy.net> Mon, 01 July 2019 03:36 UTC

Return-Path: <mt@lowentropy.net>
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 D7D431201F8 for <tls@ietfa.amsl.com>; Sun, 30 Jun 2019 20:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=MEy/+7mv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=m40ZH6nU
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 MrKnWsiKtanm for <tls@ietfa.amsl.com>; Sun, 30 Jun 2019 20:36:12 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA8112019D for <tls@ietf.org>; Sun, 30 Jun 2019 20:36:12 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A8B6F34B for <tls@ietf.org>; Sun, 30 Jun 2019 23:36:11 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 30 Jun 2019 23:36:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=HEDrVoCxIv+rJTTxc+4erqjkCMGC+O2 lxy9XPqP2bS4=; b=MEy/+7mvJwmjorvTylwuaoLhmOCosKKNbNuCw4esocuPFSn /w8VX7uj/Oj+2j5yrOilAwo2UnSkzTanlGVLuLZNJpsVkPNzrEvvFSyoM4jafqaO L4nZNB699K+WWOPx/F0NfGCpWUIcY6Z4dcAQt9ITd4a3fMrSCN6q5kvUA062Dj9o mAPVHk174brIlMBJJ66sKpxuJ5npqdeSocWGHcUW84LfnY1lWW0fudg4Ss7yQNyJ 22AMF1ez/a0sukyqVHzo5B07juWnDCpp6t3m4/vhUIDlSSF5RCviXFZ6aoxalHhu c03AmMkMn0/634Xd/mwqUGBhhq5aFEiGloSenIw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=HEDrVo CxIv+rJTTxc+4erqjkCMGC+O2lxy9XPqP2bS4=; b=m40ZH6nUril7E/mbU9vNl1 53AeSLT4zMqgzpIAUJ6QnxYi11rfQ5PtmeI7TM1YwWNuhs+XKuA4xkgTCsw4KogB sL6VIHI/Sot8tY7KLpQmiim2pLbyT+qZoSJWsWOJWtHi36YwIqS/haK1LrWg7SkC qFtxIWyXfX4GAlQO+RDI7A7ZorvWF4Nga2v4FLzudwBwzx2mvvgq4/eSSsO+3tQ0 gr92jjmyqQSpbJX/8m+YHK/qSZp/Uja80Qb3zWka+JaoYr9G1HZlsrbZIgNpXRLn B9vaDpeM89IgQnmQ1l7Fr7lPq3y8yivbE/eyuTyLfdiFQmylNmRYt1+tDbGODG5Q ==
X-ME-Sender: <xms:qn8ZXeIlKeRiT_DurbhzmjBEKaoAWCN3w4mihYwh9zhOOerxFSw-dQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdehgdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt
X-ME-Proxy: <xmx:qn8ZXacYfqOG8dG_3kAuiWIDzS7f0IkzOoFq44-L89ehQW2A3O19kQ> <xmx:qn8ZXd07X04gw8lDZ9ct6Qij3KHlab9Hs-X6IPQ1n1UI1vqyZrYHMQ> <xmx:qn8ZXbgC43X_k0fUxvpygrx7yVRlQ8nu-qQCCW4PUdvsk567rayzTw> <xmx:q38ZXZAZ6OtWktmBpkjz-MUyMzvhUIW4ExZzg5-vzt_lZHTq9QH_kA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9DF79E00A2; Sun, 30 Jun 2019 23:36:10 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1
Mime-Version: 1.0
Message-Id: <b837aeeb-37cb-4940-b0f0-10ae938905e5@www.fastmail.com>
In-Reply-To: <CAHbrMsA3zHDQFG-ffZBTFP7be52GKbqcZjcrZzqKHMVFkQ=PNg@mail.gmail.com>
References: <156173339678.20700.10472293883370612968.idtracker@ietfa.amsl.com> <CAHbrMsA3zHDQFG-ffZBTFP7be52GKbqcZjcrZzqKHMVFkQ=PNg@mail.gmail.com>
Date: Mon, 01 Jul 2019 13:36:13 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/igqcUc6dzqviCKfpKvXYyUzwxo8>
Subject: Re: [TLS] Fwd: New Version Notification for draft-schwartz-tls-lb-00.txt
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: Mon, 01 Jul 2019 03:36:15 -0000

You might like to coordinate with Martin Duke, who is doing similar (but different) things with QUIC:

https://tools.ietf.org/html/draft-duke-quic-load-balancers-04

Personally, I find this sort of thing difficult to reason about.  I would rather have a separate TLS connection with each backend than to overload or annotate connections.  Cramming stuff ahead of the real connection is awkward, but I can see how that might be necessary in order to get back-end systems ready for the new connection.  That won't be sufficient for QUIC though. 

As an aside, the proposed design for QUIC is a very good way to ossify the QUIC handshake.  I don't think that's a good way to do this, even if I believed that the potential growth in MTU was not a problem.

I would have thought it easier to use an exporter (plus one to provide a key identifier) to get shared keys -- if you need them.  I don't think that you do though.

If you look at Martin Duke's design, the load balancer acts as an oracle.  It can do that for ESNI in the split mode you envisage.

On Sat, Jun 29, 2019, at 02:52, Ben Schwartz wrote:
> Hi TLS,
> 
> This is a proposal for a very simple new protocol whose main purpose is 
> to enable ESNI "split mode". Ultimately, I hope that this protocol can 
> also enable more end-to-end TLS, by reducing the need for 
> load-balancers to terminate TLS.
> 
> Please discuss.
> 
> Thanks,
> Ben Schwartz
> 
> ---------- Forwarded message ---------
> 
>  A new version of I-D, draft-schwartz-tls-lb-00.txt
>  has been successfully submitted by Benjamin M. Schwartz and posted to the
>  IETF repository.
> 
>  Name: draft-schwartz-tls-lb
>  Revision: 00
>  Title: TLS Metadata for Load Balancers
>  Document date: 2019-06-28
>  Group: Individual Submission
>  Pages: 8
>  URL: https://www.ietf.org/internet-drafts/draft-schwartz-tls-lb-00.txt
>  Status: https://datatracker.ietf.org/doc/draft-schwartz-tls-lb/
>  Htmlized: https://tools.ietf.org/html/draft-schwartz-tls-lb-00
>  Htmlized: https://datatracker.ietf.org/doc/html/draft-schwartz-tls-lb
> 
> 
>  Abstract:
>  A load balancer that does not terminate TLS may wish to provide some
>  information to the backend server, in addition to forwarding TLS
>  data. This draft proposes a protocol between load balancers and
>  backends that enables secure, efficient delivery of TLS with
>  additional information. The need for such a protocol has recently
>  become apparent in the context of split mode ESNI.
> 
> 
> 
> 
>  Please note that it may take a couple of minutes from the time of submission
>  until the htmlized version and diff are available at tools.ietf.org.
> 
>  The IETF Secretariat
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> Attachments:
> * smime.p7s