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

[Ben Schwartz <[e-mail]>]

Thanks for the suggestions.  I've posted a new version:
https://tools.ietf.org/html/draft-schwartz-tls-lb-01

This version has:
 * a diagram!
 * a security considerations section with the security concerns we've
discussed
 * a different approach to QUIC annotation that avoids increasing the MTU
and addresses ossification more directly

I'm certainly open to totally different architectures, like TLS-in-TLS,
oracles, Cloudflare's Argo, etc.  I just want to make sure that we come
with an answer that (1) serves the listed use cases and (2) is attractive
for widespread deployment.

On Tue, Jul 2, 2019 at 2:44 AM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 02/07/2019 03:38, Martin Thomson wrote:
> > 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.
> I guess split-mode MTU issues provide another argument
> against including padded_length in ESNIKeys on the basis
> that including it there with a value of 260 as will likely
> be common (in case of wildcard certs) inflates the CH
> and that could, though isn't likely to, badly affect the
> size of the first packet between the LB and backend.
>
> I don't expect that to be seen as a winning argument for
> those who, unlike me, think padded_length is just fine in
> ESNIKeys, but we may as well record it in passing :-)
>
> Cheers,
> S.
>