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

"Martin Thomson" <> Tue, 02 July 2019 02:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 789C11201AF for <>; Mon, 1 Jul 2019 19:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
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: (amavisd-new); dkim=pass (2048-bit key) header.b=Ok5BH0+z; dkim=pass (2048-bit key) header.b=Sn/moVzx
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R-3yr9Tke5vx for <>; Mon, 1 Jul 2019 19:38:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80B491200D7 for <>; Mon, 1 Jul 2019 19:38:33 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 8F83C5AE; Mon, 1 Jul 2019 22:38:32 -0400 (EDT)
Received: from imap2 ([]) by compute1.internal (MEProxy); Mon, 01 Jul 2019 22:38:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=/LrRXgyEF11cTAhdiMdCe4OP/aqw ywbXpDs63ogJ4Fo=; b=Ok5BH0+zuZiLcMpx+OwzO1IT/qSHMc1YOK8p4CqbPigb rQ5gVpFklFZiCakjxqlGKREzh4f6/ueXj6CDaZ6MFea3zBWuB5St3UyVLSPVOPQM lxmA5RdG/4TipDKPRomcpWSPgemC3n5zan0pDH9KOZD6S4W2ebXmoNsMwvAJnDrJ eViobVU7gEbTC9I1XLVj8pLbSH4PwYtoDu2zxESLvpFKhukwk5HNV2rjpRk3L6K1 jgACJcdzbqzbX0mjsYzch73/K3OHd/vc07dY7gNcr+ABaufNoNmhG1t0avCqMPml PIy3UavIaK32BMlH0d1CBw8TMpt13qj69SZQqfOOZg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc: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=/LrRXg yEF11cTAhdiMdCe4OP/aqwywbXpDs63ogJ4Fo=; b=Sn/moVzxYJFhTDItZ8UiKi LKlxkvRQgDD9K/FvySEGY9qhvaG482N9dOhRmiFNgvcUcR7JpUA2El28LE4PF7or 5aVMxaXd/Dfthdjp3tncB7Q70do+KK/QJxjPBNI4XIdv57kgE3774US3/a5/+w15 H70IOvsveLjEDnbbGyUvhBTLTAYsrjw7eqAUsMniGX2FRf2rSXZbh6/MhPV1tTfT td0/zaIZffOu7EH7AQou/JHGSI92p92TkWR6hBnI17XbTnwcwOGoIsVakS7YEuNh A0OUDqFqLMA4Jk196tewC0nSfHz/UYyhGo2qphL9NS+kYvuvsyQcmFHvmy0IltdA ==
X-ME-Sender: <xms:p8MaXZFvlEc8WsxVIk98ui8AxDKn8gN6T9rU3lkySSxYsKoJvxR01A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdejgdehlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:qMMaXQR1NcgVtRSjpXwSea3521b95tzaTWFlwhrPLkX1ACH6znlkFg> <xmx:qMMaXVheGk0CQUwgdUxTzI1HMI7S1euWS1TtSBHoh0UX8vc1TQREvA> <xmx:qMMaXcZhj7GnL137U2XbOpzUgednKjzF_GYYNBT4oAhRNRGM6evKrw> <xmx:qMMaXThGyr8W3kF6bYfTCi_nCEREDxa_u5NxYpFODVlhKMH8fi9w2w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C332DE00A2; Mon, 1 Jul 2019 22:38:31 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 02 Jul 2019 12:38:32 +1000
From: "Martin Thomson" <>
To: "Ben Schwartz" <>
Cc: "<>" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-schwar?= =?utf-8?q?tz-tls-lb-00=2Etxt?=
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jul 2019 02:38:36 -0000

On Tue, Jul 2, 2019, at 01:12, Ben Schwartz wrote:
> To be clear, are you suggesting TLS-in-TLS, similar to Stephen's 
> suggestion? Or are you suggesting a parallel connection to deliver the 
> metadata?

I'm thinking that a parallel connection for metadata is going to be more efficient in the general case.  If you need specialized things (like getting metadata in ahead of the first packet on a new connection), then you can use exporters and protect special messages, all based on that shared context.

> I don't believe this design introduces any ossification risk beyond 
> that inherent in split-mode ESNI. Split-mode ESNI inherently requires 
> that the load balancer be able to read the ClientHello out of the 
> packet it arrives in, and that is also the only requirement here.

You are baking assumptions about the format of the Initial packet into your protocol.  That tends to ossify things.

> >  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 does? I don't see any oracular behavior. The cryptography appears to 
> consist of a single PSK that is shared by the load balancer and all its 
> servers, and is passed between them in cleartext.

Ugh, the draft changed again.  Nevermind.  I think that it should act as an oracle, but that's not what it says.

> I can certainly imagine an ESNI oracle, at the cost of a delay while 
> the backend queries the oracle. Is that what you're imagining?


> If we assume working 0-RTT, TLS-in-TLS might have less latency overhead 
> than an oracle. Alternatively, we could imagine a "push oracle", at the 
> cost of potentially severe implementation complexity to handle 
> reorderings, failures, etc.

Keep in mind that you are going to be racing anyway, unless you are lucky enough to have a protocol that leaves enough space in the MTU for all your extra stuff.