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

Ben Schwartz <> Tue, 02 July 2019 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82CC51206FA for <>; Tue, 2 Jul 2019 13:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jTMZpTYfshHE for <>; Tue, 2 Jul 2019 13:02:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F06D1206CB for <>; Tue, 2 Jul 2019 13:02:06 -0700 (PDT)
Received: by with SMTP id u13so40116289iop.0 for <>; Tue, 02 Jul 2019 13:02:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fuauNRSN/L9MAYUeHmPQG05HfL9acEHJH38ceiknwZk=; b=thW14RdYfdT5iR/qsq8o8TcESasbzuUc3IJywKpgkMD6esnQJ3LEGosqC3mqWrjLXd 8SwhXIYlLQXaNKGJEKKKUpjdr+YjmBKZNGZGTvcd0oV7YKQjLsYg5G5dzBvK8TXZmLO3 bwvB3MZgiVXCXxz2Gjumg/GB9A6kehN7Ez4Cdy3xKqRYuKyF4osMzK1g37+FZ/wFhsrB s7Uo/uH+U9GcbROpTW7PV5zYTzYXBwzWbz+eNwagfPs8epO1E3vchAOsTYFVcz7Kl6pn wYoQHFRzGrzALqRzdlYDla0K8XRSaTpdJTj6SdNhJ2+gE54P/YLeLid74LTe0hNeJRax /WsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fuauNRSN/L9MAYUeHmPQG05HfL9acEHJH38ceiknwZk=; b=HSbjywhDYZnQit7sgrt32ql0IU8fzOeQ8xIxxCWY01Sb4UmvXjNahTQW9WYlxSvP50 GDfbxPdwoRfkUUse1VAZqgoWdRD4k8XVIO94zlTgbrNUVlu6HyLcF947014xc1bcsEGf 9lZR9yJxfnhYrJSQZISKFeN3VaBjWoVzB+PWqoCN2NLKUEyd2xQ7oTXW/PK3/ojqN5u4 ipKRb7Jgy8/sEh8/h9l77liasnr0Czx2pPQO3QZq4qEaeSx2Q/FMdlzJ1Lqww/VTaQ4u 3bmw7A4Ghq8xH37EcJ6j2xoDUGQ5TG0wpu3FjH5bBQkujsSDMhiJkaGolaKgjEsd3mKM 3ttw==
X-Gm-Message-State: APjAAAVU7TZ5DJpzbd24KFMlN0WECTW4++cC0mBtMqK/GcHOv1WD73Iy uNoRM7IIQrNyFPT/60T97c8bt06oHRvTSrIGzmWpEzDlxkU=
X-Google-Smtp-Source: APXvYqxT4TCS3kVKHB/VbVhRessyQ/R/pXADw3cqOZLsC3qv6YOfA9ZL23Dyicrnt2Fl26nbhuk+fQ1TwmlyPgdQMv8=
X-Received: by 2002:a05:6638:201:: with SMTP id e1mr36949086jaq.45.1562097724941; Tue, 02 Jul 2019 13:02:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 2 Jul 2019 16:01:51 -0400
Message-ID: <>
To: Stephen Farrell <>
Cc: Martin Thomson <>, "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000092960058cb8381e"
Archived-At: <>
Subject: Re: [TLS] Fwd: New Version Notification for draft-schwartz-tls-lb-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jul 2019 20:02:08 -0000

Thanks for the suggestions.  I've posted a new version:

This version has:
 * a diagram!
 * a security considerations section with the security concerns we've
 * 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 <>

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