On Sun, Jun 30, 2019 at 11:36 PM Martin Thomson <m...@lowentropy.net> 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 > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > Attachments: > > * smime.p7s > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
