Re: [Unbearable] More thoughts on reverse-proxies

Brian Campbell <bcampbell@pingidentity.com> Thu, 03 August 2017 19:44 UTC

Return-Path: <bcampbell@pingidentity.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 E22F91317C1 for <unbearable@ietfa.amsl.com>; Thu, 3 Aug 2017 12:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 Vx-RXkoCQQVl for <unbearable@ietfa.amsl.com>; Thu, 3 Aug 2017 12:44:16 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 DFFC7129B26 for <unbearable@ietf.org>; Thu, 3 Aug 2017 12:44:15 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id v189so10073436pgd.2 for <unbearable@ietf.org>; Thu, 03 Aug 2017 12:44:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FQwitYw84J4oFAn/pH0q3fbHTPXz1qJPX9aVb2b+oIk=; b=MB0Wvuw6lvnhvbT4kGYKfE57gEmhCPZCrAooDHq5Wx/MsgQfK+qbsbCSEma6WXOFwN za7QYhExL+erl448sgZGlMM96ug92DI/abLakeH882pGLS6RathXPI65xV/jgJM3QiNp AqYmdmlL/XbH9Hv1CQ8GxeeDzIjvxRHPAvBjM=
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:cc; bh=FQwitYw84J4oFAn/pH0q3fbHTPXz1qJPX9aVb2b+oIk=; b=uiikjk/1AGiLKmdCpilIPEe+4bhmRtavL2YHOR/mAdhFn33cuKmTUJ5YMXOV9eEUhb a9mMjgzoWHZzfMtP8jCT+HVdxXhQYVb0hde1nycvyQfKHrn7E7RWJCs2dw8AxjhcSvlh jo9Y6cMKf6wSfjIattagup0UZxIr1R3XUDmehdyH+YBlJJdDxn0Lj4EvtEacyJMT8SoW P8qVBijwb62g+JM57xKXnrKbB4GSPqo94PMxiFbma2/GhS5aipgz+LtOpx6MOueLgkgb +/IurD0H8TOKH6KAaGSJdruazhr5vifELCoq7kFEbuUfj3vK38M74e0n6hbTptr0nKv2 MFHw==
X-Gm-Message-State: AIVw110RDnVu48hdRpqtOXTaI2avyjZegm8kvP/Dczn/unMD7LvsvBsz NNlbGmPvgBtO3TH7i9T2yICnmwDEVTRZfbxCcZ49E4I4LNhR+ze7OPJ0EmtKRFRNaQkLb7fyoWf HFcjqGAmQ4sg=
X-Received: by 10.84.236.4 with SMTP id q4mr3045019plk.423.1501789455389; Thu, 03 Aug 2017 12:44:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.182.230 with HTTP; Thu, 3 Aug 2017 12:43:44 -0700 (PDT)
In-Reply-To: <CAH9QtQH-fd=a1LSPj0avEvcLkwR=BUj-KV0MAWz+fZ9T6-c93Q@mail.gmail.com>
References: <CAH9QtQG_gpeqQD+_6xDMNg6F1RTYOEFXq1nHwnmzMePP4-EKaA@mail.gmail.com> <CAH9QtQH-fd=a1LSPj0avEvcLkwR=BUj-KV0MAWz+fZ9T6-c93Q@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 3 Aug 2017 13:43:44 -0600
Message-ID: <CA+k3eCQhbk4gxa1e3m9xBYmMq++qyJ9F-K3Px_t-7_ayq40mUw@mail.gmail.com>
To: Bill Cox <waywardgeek@google.com>
Cc: Tokbind WG <unbearable@ietf.org>
Content-Type: multipart/alternative; boundary="f403045fe2d40430b90555de9bee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/OUKrz2aDn5-huTQalQnfWoh71Fg>
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 19:44:18 -0000

Yeah, there are advantages and disadvantages to both approaches. The
approach of providing the EKM to the back-end was what I wrote up in my
first cut individual draft. But as John mentioned, the winds of WG
consensus moved to the other approach being written up and adopted as a WG
item.

>From a standardization standpoint, I believe that documenting only a single
approach is important to avoid confusion and facilitate interop and
adoption. But nothing is requiring anyone to follow the (hopefully someday)
RFC approach - it is intended for off-the-shelf products (including open
source) and services that need to be mixed and matched in deployments and
work together. A large scale deployment that owns all the infrastructure
is, of course, free to do it however is deemed most appropriate. Similarly,
the approach the NGINX module uses has value and will be appropriate for
some deployments. But I don't see value in standardization of it.





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

> 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:
>>
>>
>>
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*