Re: [Unbearable] More thoughts on reverse-proxies

[Bill Cox <[e-mail]>]

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 <[e-mail]> 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:
>
>
>