Re: [Unbearable] More thoughts on reverse-proxies

Bill Cox <waywardgeek@google.com> Thu, 03 August 2017 16:09 UTC

Return-Path: <waywardgeek@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D202132521 for <unbearable@ietfa.amsl.com>; Thu, 3 Aug 2017 09:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 dcuyShiGv7bc for <unbearable@ietfa.amsl.com>; Thu, 3 Aug 2017 09:09:55 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 B3B731324C5 for <unbearable@ietf.org>; Thu, 3 Aug 2017 09:09:55 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id l82so11330267ywc.2 for <unbearable@ietf.org>; Thu, 03 Aug 2017 09:09:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=GFwsOOqTa/tS4sOAZW4a6+wPXH9hiH1vcGChZFFA1Mc=; b=FRI+RwpTp01/kjh0vq1XRchJ8+ChP7LbfDxMCYTE/rrY2cUbU+tXF8a7N6rIlHMAkH xg3RTJvc9PWWYnjNdrKzJ6Rlx7PPUTT0hzQHoHQscxSWflen8w0y4AjYfIXJ01iANvFx EQi7yIYZ6PpRs/rIBVi9i9Zha2WrMX8Sf867IIIchd9mBsBuoMlL49YCnFOBK+XNksvj zmq+kQEd5mrD6NI/7sa/a0EqpYDuu7IfpuvZXPGROS47GTfNpO4J7aPkZ/BhR3J1mRen OOduMEAXbvsCMAdsweD2j41hh/h8rMBR6Mzfb+logJqm1jXI6GtCGxLpQvfUA+J+naSd ezxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=GFwsOOqTa/tS4sOAZW4a6+wPXH9hiH1vcGChZFFA1Mc=; b=JMWRWvZ1yH3bXFjASVUt2NMSnY767mZII6EM1+dbSLa3Dg6fe0VD5Y6LwT594gCxdq Gp7d7qevkeN5Z0J3vQvzAD4MHR1bnnyw0osn38xMNBJCgmdxLTT9AgxSXIfF0R6P1pmd NO03/fJjZY7x3ev8yXPmHUxj+LFHh06FddkNwo9IZnvcutYE8262nVmRD7iIT52psuJT fJcfNrYM1EMhom0c+84KUFTqTErLY2YRiZcGOBfQZqXRwz/4gsCSP6IZkx3sF63Bsgn8 G1UgjXWq7p86b8FinxRB4Kp2SBXfnLL8HN9TAcrnuDs8LxNE4/cJE9KXIFp45ZSMAcKu vihQ==
X-Gm-Message-State: AIVw110n7kF89OeXWCEuFoqFoJoHrRdbjJiouC60ScgvjLsNc6uZkbyQ FkkzQUya+lEp09QLPCUh5ryETDNVOc4LJSU=
X-Received: by 10.13.209.135 with SMTP id t129mr1521667ywd.15.1501776594406; Thu, 03 Aug 2017 09:09:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.222.135 with HTTP; Thu, 3 Aug 2017 09:09:53 -0700 (PDT)
In-Reply-To: <CAH9QtQG_gpeqQD+_6xDMNg6F1RTYOEFXq1nHwnmzMePP4-EKaA@mail.gmail.com>
References: <CAH9QtQG_gpeqQD+_6xDMNg6F1RTYOEFXq1nHwnmzMePP4-EKaA@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
Date: Thu, 3 Aug 2017 09:09:53 -0700
Message-ID: <CAH9QtQH-fd=a1LSPj0avEvcLkwR=BUj-KV0MAWz+fZ9T6-c93Q@mail.gmail.com>
To: Tokbind WG <unbearable@ietf.org>
Content-Type: multipart/alternative; boundary="001a114e58f071b2e30555db9c19"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/ItbTUCZKLp7Y7orhsmgMFkZXuWA>
Subject: Re: [Unbearable] More thoughts on reverse-proxies
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Aug 2017 16:09:57 -0000

Grr... my finger muscle memory expects TAB to indent, not set the focus on
SEND.  This is my #1 gmail complaint.  I can't see what I'm typing very
well, and Chrome does not work with my Linux screen reader (yet - I'm
working on that), so I can't hear it either.  I make this mistake often.
Sorry!

Anyway, the advantages of TB verification in the back-end are:

- The application can continue processing the request in parallel with TB
verification.  If it is done in the front-end, this adds ~120us in series
to every request.
- Requests that don't need TB signature verification don't see the
signature verification overhead.  This can be a high fraction of requests.
- 0-RTT replay protection is very expensive in the proxy, but cheap in the
cookie back-end.  A large organization may have several different types of
reverse proxies, and replay protection has to be developed and maintained
for each.  However, they only need one back-end cache for TB replay
protection.  0-RTT replay protection forces proxies to communicate over an
entire metro area, slowing everything down by maybe 1ms for every
resumption.  This does not happen with replay protection in the TB
verification back-end.

A downside is likely worse protection against cookie theft and reuse.
Applications typically only verify auth cookies for new sessions, IIUC, so
the TB credentials would not be checked.

On Thu, Aug 3, 2017 at 8:47 AM, Bill Cox <waywardgeek@google.com> wrote:

> I like the TTRP spec, but there are at least two other modes of operation
> a reverse proxy might want to use.
>
> The simplest way for an organization that uses NGINX to enable token
> binding is to use Piotr's token-binding module
> <https://github.com/google/ngx_token_binding>.  Piotr did great work on
> that, but there is room for improvement, such as using a more modern and
> shorter MAC appended to the cookie.  Would it make sense to have an RFC for
> this mode of operation?  That way, javascript that manipulates the cookie
> cleartext would be simpler to write: it would only have to look for one
> token-bound cookie format.
>
> The other mode of operation is one I favor for large scale deployments:
> The proxy could compute the EKG value needed for verification and pass this
> in a new header to the back-end.  Then, the cookie server could verify
> cookie TB signatures in the back-end.  This scheme has several advantages:
>
>
>