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

From: Ben Schwartz <[email-masked]>
Date: Mon, 1 Jul 2019 11:12:16 -0400

On Sun, Jun 30, 2019 at 11:36 PM Martin Thomson <[email-masked]> wrote:

> 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

Thanks for this reference.  I was not aware of it.

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.

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?

> 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 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.

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.

> It can do that for ESNI in the split mode you envisage.
>

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.

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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tls
> >
> > Attachments:
> > * smime.p7s
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 02 Jul 2019 12:38:32 +1000

> suggestion? Or are you suggesting a parallel connection to deliver the 

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.
> > 

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?

Yeah.

> 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.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 2 Jul 2019 07:43:55 +0100

Hiya,

On 02/07/2019 03:38, Martin Thomson wrote:
> 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.
I guess split-mode MTU issues provide another argument
against including padded_length in ESNIKeys on the basis
that including it there with a value of 260 as will likely
be common (in case of wildcard certs) inflates the CH
and that could, though isn't likely to, badly affect the
size of the first packet between the LB and backend.

I don't expect that to be seen as a winning argument for
those who, unlike me, think padded_length is just fine in
ESNIKeys, but we may as well record it in passing :-)

Cheers,
S.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 2 Jul 2019 16:01:51 -0400

Thanks for the suggestions.  I've posted a new version:
https://tools.ietf.org/html/draft-schwartz-tls-lb-01

This version has:
 * a diagram!
 * a security considerations section with the security concerns we've
discussed
 * a different approach to QUIC annotation that avoids increasing the MTU
and addresses ossification more directly

I'm certainly open to totally different architectures, like TLS-in-TLS,
oracles, Cloudflare's Argo, etc.  I just want to make sure that we come
with an answer that (1) serves the listed use cases and (2) is attractive
for widespread deployment.