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

From: Ben Schwartz <[email-masked]>
Date: Fri, 28 Jun 2019 12:52:10 -0400

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Jun 2019 18:34:11 +0100

Hi Ben,

Thanks for posting that - good to see a start on plugging
that gap.

> enable more end-to-end TLS, by reducing the need for load-balancers to

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.

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.

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.

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

Cheers,
S.

(*) When I say non-trivial here I don't mean "very hard":-)

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 28 Jun 2019 14:47:45 -0400

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

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

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

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

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

> grok:-)

Point taken.

Cheers,
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-schwartz-tls-lb
> >
> >
> > Abstract:

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Jun 2019 20:22:36 +0100

Hiya,

> maintain the extra TLS state.

Fair point.

> subsequent traffic patterns are likely to disambiguate them.

That's a reasonable argument. I'm not yet convinced it's
where we want to land myself though.

> the realm of possibility but it seems like a much more difficult

Right. A TLS-in-TLS approach to split mode ESNI could be a
step on that road. I'm not arguing that's a winning argument
but I do think we ought tease it out. If we go back 2 or 3
years we concluded ESNI wasn't doable, but turns out it was.
Not sure if there's anything practical we can do about the
correlation problem in split-mode ESNI but we should think
about it, and recognise it as a real issue.

That reminds me: if you put out a -01, describing all that
in the (missing:-) security considerations section would be
a fine thing.

> byte-matching.  I think this is probably not worth it, but you can propose

Nah, don't think I'd go for that either. Either a light-weight
prepend-stuff approach like yours (but with better than a PSK),
or else a TLS-in-TLS with the associated costs and benefits
seem like the options here.

> clients would learn about these alternative ESNI hosts, but never mind that.

Not a problem. The LB/fronter just has to publish it's ESNIKeys
and then the backend publishes that RR value in the DNS. So
the TLS client doesn't need to know that the LB/public_name
and backend do/don't have a prearranged deal.

> reach out to acquire a unique PSK.

Not sure I get what you mean there, but yes, if we follow the
approach taken in your I-D, I would argue that such a key
establishment mechanism would be needed, and I'd be shocked
if that wasn't based on TLS:-)

Cheers,
S.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 01 Jul 2019 13:36:13 +1000

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
> 
>  URL: https://www.ietf.org/internet-drafts/draft-schwartz-tls-lb-00.txt
> Attachments:
> * smime.p7s