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

[Ben Schwartz <[e-mail]>]

On Sun, Jun 30, 2019 at 11:36 PM Martin Thomson <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
> > Attachments:
> > * smime.p7s
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>