Hiya, On 28/06/2019 19:47, Ben Schwartz wrote: > On Fri, Jun 28, 2019 at 1:34 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> >> 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.
Fair point. > > 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 > 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. That's a reasonable argument. I'm not yet convinced it's where we want to land myself though. > > 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. 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. > > 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 :-). 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. > > 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. 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. > > 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. 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. > > Also: a diagram would really help make the draft easier to >> grok:-) >> > > Point taken. > > Cheers, >> 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: >>> 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 >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
