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

["Martin Thomson" <[e-mail]>]

On Tue, Jul 2, 2019, at 01:12, Ben Schwartz wrote:
> 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?

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

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.

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

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.