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

Ben Schwartz <> Fri, 28 June 2019 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DD5D1200FE for <>; Fri, 28 Jun 2019 11:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ww9QdGLjBmHk for <>; Fri, 28 Jun 2019 11:47:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53A121200F1 for <>; Fri, 28 Jun 2019 11:47:58 -0700 (PDT)
Received: by with SMTP id f20so2574134ual.0 for <>; Fri, 28 Jun 2019 11:47:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T3gpmFcqhVLnDR4S/wPeoz2Oa/VnKgjV1zMhKzeeywI=; b=GqzzHoMROtef/bKYOlMKKKkNvdRHVqAVdPrkKkEjHd7LW+BJgpjva1lZqUrSfUWaoL f4xln6HtHR5UN+JSTCs7k84Sw/2T5feuwq7lhIH9WIQ9o20pawk+b/LBwFslKi1zNnsP 1Piq4y2rIPPPscR3b1jiHkfo6CD0lE232CDwTDqEGuboiWsvuL+51X3uzmHS0a4tlZta Ke8u1Q1FdxStiEubJiBVpY0OTNwNbOxz1uwyTsUoL4QCM/i5exG74ANoNC9l4TXFtKSb zTRYjzBrhG/o1pY8nn9b3hvXyS0Q0jMHdfNiR9oNkGacdPfJoGYmJPz8p1ICI6/lAepb Fu6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T3gpmFcqhVLnDR4S/wPeoz2Oa/VnKgjV1zMhKzeeywI=; b=Y7DpwOhIT/ZhI7UuMVlNPFPs8Bgm9/KPnzt7m4L1y0SKZoODgLWwqZcXvjJigvOW2t PQ8uZxdhJYh6w066rgShzZcdKBW9jhk/dmdHn2Q4tRk5o00uwhSkpkm808tYnt2hyp68 7sZTj2JOS7qHSFM8SH/O5JVxCOnNEOqhbxAjpoHvbzVGDuHstYReSeYFb0rZSFNIzF1f uCIGRW4/QAqrcJU2nVK0+0kFikT1fFfQ7+rwUCi9xAj2sbHKpqHrVXseW6pi4YcgQnKK 4/XmOsxqsCjgS1TxZBpRvSOyOYbncKvW7Qu5/HqOwpKUTq+i/Jx2H0gViSQ7vAkmDjyt 4HEA==
X-Gm-Message-State: APjAAAVmHjWnr+Yn6ZhLbsF06o4f4MPa1jZUYsngTq8QJ6154TqxRyiU 7QRHcar6S00MrVF8TCM0IY6AM37re722i1ZeWwDTrImMvA4=
X-Google-Smtp-Source: APXvYqy1Fw8b5pAyEt6n4EIE+kvxb14befDePPeCJ+0P9u8wyNe7ifwiZELwy2CZJ3wNv9nm/si4bIJs85wq7do4Wds=
X-Received: by 2002:ab0:614d:: with SMTP id w13mr6251917uan.66.1561747677016; Fri, 28 Jun 2019 11:47:57 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Fri, 28 Jun 2019 14:47:45 -0400
Message-ID: <>
To: Stephen Farrell <>
Cc: "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000008ceabb058c66b711"
Archived-At: <>
Subject: Re: [TLS] Fwd: New Version Notification for draft-schwartz-tls-lb-00.txt
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: Fri, 28 Jun 2019 18:48:02 -0000

On Fri, Jun 28, 2019 at 1:34 PM Stephen Farrell <>

> Hi Ben,
> Thanks for posting that - good to see a start on plugging
> that gap.
> On 28/06/2019 17: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.
> I guess an alternative would be to wrap this metadata and
> the TLS session in another possibly long-lived TLS session
> between the LB and backend. That'd have the benefit of not
> requiring a PSK, making correlation of the CH etc from TLS
> client to LB with the LB to backend non-trivial(*), but I
> guess at the cost of more CPU and per-packet overhead.

I agree with this analysis.  There's also a significant memory overhead to
maintain the extra TLS state.

The fact that a network observer can so easily correlate
> the inbound TLS packets to the LB with those outbound seems
> like a fairly major downside of this approach to me.

This seems to me to be a threat modeling question, or maybe a question of
how to trade off an expanded threat model against performance

Overall, my feeling is that
(1) This is an area where performance sensitivity is high (both at the load
balancer and on the backend).
(2) It's worth aiming for wide deployment, because the state of the art is
TLS termination or metadata in plaintext :-(.
(3) The effectiveness of layered encryption against a pervasive passive
adversary is low, as you mention.  Specifically, because
client->load-balancer connection initiation triggers a
load-balancer->backend connection setup, there is only ambiguity among the
few connections that are initiated within milliseconds of each other, and
subsequent traffic patterns are likely to disambiguate them.

If you want to build an anonymizing TLS forwarder it would need long-lived
connections, padding, chaff, and probably multiplexing.  This is all within
the realm of possibility but it seems like a much more difficult

If you just want obfuscation, a possible middle ground would be to
initialize a stream cipher from the PSK and let it run.  For a small CPU
cost and zero size overhead, this would give you defense against basic
byte-matching.  I think this is probably not worth it, but you can propose
it to the group :-).

The PSK would also make it hard to offer ESNI fronting to
> random backends without pre-arrangement between the LB and
> backend, should that be something someone wanted to do. I
> think that would allow less centralised deployment of ESNI,
> which I think is a pretty desirable option to preserve.

This is an interesting observation.  Given that TLS-in-TLS is not TLS, the
backend would still have to opt in to this system, but in principle it
might accept incoming connections from anywhere.  It's not obvious how
clients would learn about these alternative ESNI hosts, but never mind that.

I think this goal is reasonably achievable in the current 00 draft
protocol.  A site that wants to opt in just has to publish a PSK-vending
endpoint wherever they would otherwise opt in.  Then each load balancer can
reach out to acquire a unique PSK.

Also: a diagram would really help make the draft easier to
> grok:-)

Point taken.

> S.
> (*) When I say non-trivial here I don't mean "very hard":-)
> >
> > 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:
> >
> > Status:
> > Htmlized:
> > Htmlized:
> >
> >
> > 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
> >
> > The IETF Secretariat
> >
> >
> > _______________________________________________
> > TLS mailing list
> >
> >
> >