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

Ben Schwartz <bemasc@google.com> Mon, 01 July 2019 15:12 UTC

Return-Path: <bemasc@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473ED1200DE for <tls@ietfa.amsl.com>; Mon, 1 Jul 2019 08:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6ankjvRJQkv for <tls@ietfa.amsl.com>; Mon, 1 Jul 2019 08:12:31 -0700 (PDT)
Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382A21200CC for <tls@ietf.org>; Mon, 1 Jul 2019 08:12:31 -0700 (PDT)
Received: by mail-ua1-x929.google.com with SMTP id 8so5187692uaz.11 for <tls@ietf.org>; Mon, 01 Jul 2019 08:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8a3kk8M6lR1eJd+oluxgODlQiWadQiAXf5RHDuGi9RM=; b=LwmrhLcQFV2WfKR6TuynLTEvOS4JqkdFINKpDRISVt5iTHk/kYyySdMRowjGS7sPoJ TT2qcg0xvW8vdE4dtEtT4i6DAUkP7cmEfNXS8xQfO+rEko2CX4/IWcfUTQBDC25mefaC xZDz9ZmNIQ0azXMcv/5Woi0ED8gAWBHmao+3QZwQD9O/3PyxxNkVcC8NtBOeKwg2GRhs b/U6WfB2kJX2LddrXjJdU3jFfr69TDWvNODTIAziGcdo6YkGe6cvkOzTo+N5ubaVrHW9 SCtDwCUIKIqJypgFJOj35OYHwmzs0WAvxKFv9MEvSwQX850oT+/RFXkd5xg2Hqblg2e9 c6DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8a3kk8M6lR1eJd+oluxgODlQiWadQiAXf5RHDuGi9RM=; b=cSUiIxzpgcL1JcFzyrQJVup+/HA7vIJM6fU/X9YNAW/MZYkP56Q6m0avA/0zvvNZ2h NzHxd0QFt/WocpSiusvJDJHrrC/i+emQfIEJ+7tPodUGgKVXqIRyCfojctKvG79aklQT KJo+CdOlV8A35PNP4/vZemw2i5s5m26CNzp9ta8xAdeBkAGn3FpoOzo5cgoPatPhUQg/ OWezPOpbrPQOU4NpgxfZO/sVtC2JERT4UpHxbNqGNKGjRvp+F7pnT0PH8XMR2jccW+Gr QdgZ00Ul7GKnfSt2U5ddbtS8MKeD5k2cWjrD5V5CmCA/TyNbbEFL+H3dk93lw8CkasRh zSIg==
X-Gm-Message-State: APjAAAVpGmGaTI6aD2GG3tZRHSdtn61V9YO/SmPEFzqQ2sXl7cTPyLzY JNCXaC7BQx6BgRptdaimzUFYQKJbIkuEgCqgQAvetqPSbio=
X-Google-Smtp-Source: APXvYqzu9T8O7U1xrXrqmrIrjs+P7irUtP4OnF//8/M9xpFqyxDjamyUsgXHzAone4QCpI5WjGHGClqiYhDfdluind0=
X-Received: by 2002:ab0:3d2:: with SMTP id 76mr14490485uau.12.1561993949732; Mon, 01 Jul 2019 08:12:29 -0700 (PDT)
MIME-Version: 1.0
References: <156173339678.20700.10472293883370612968.idtracker@ietfa.amsl.com> <CAHbrMsA3zHDQFG-ffZBTFP7be52GKbqcZjcrZzqKHMVFkQ=PNg@mail.gmail.com> <b837aeeb-37cb-4940-b0f0-10ae938905e5@www.fastmail.com>
In-Reply-To: <b837aeeb-37cb-4940-b0f0-10ae938905e5@www.fastmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 1 Jul 2019 11:12:16 -0400
Message-ID: <CAHbrMsAF-8rq2Xbh4n-cJ2UerC5znP0rGNH-VaBENFMEqbyefQ@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000008c241a058ca00e00"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tR-_-C7iELlEOODIGzqzXO10skE>
Subject: Re: [TLS] Fwd: New Version Notification for draft-schwartz-tls-lb-00.txt
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jul 2019 15:12:34 -0000

On Sun, Jun 30, 2019 at 11:36 PM Martin Thomson <mt@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
>