Subject: [Unbearable] More thoughts on reverse-proxies

From: Bill Cox <[email-masked]>
Date: Thu, 3 Aug 2017 08:47:48 -0700

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:

---

From: John Bradley <[email-masked]>
Date: Thu, 3 Aug 2017 12:09:03 -0400

The version of the spec passed the EKM to the backend.    The WG asked the author to change it to this method.

Both work and have advantages and disadvantages.   One problem with the EKM approach was the possibility of multiple EKM sizes when the original draft was done.   However a separate decision was made to fix the EKM size for this version to a single value making the EKM approach simpler.   In that case it would be the EKM header that would need sanitizing.

I suspect documenting both methods in a spec will just add to the confusion and delay support in products.

Nothing stops someone from implementing both in a product if they see value.

I think there may be an advantage to the EKM method if new token binding types are added( I think MS may be using some but Tony as not provided any details to the WG yet)

With having the TTP validate the provided and referred token binding ID the TTP has to know a lot more and would need to be updated to validate other types.

With the EKM method the proxy is much simpler and jan just extract the EKM and allow the Sec-Token-Binding header to pass through untouched.

The EKM approach is probably best for more sophisticated deployments as alter apps need to validate the token binding.

The validate in TTP method covers all current documented use cases and could be extended in future.  It is much simpler for apps and may be best to drive adoption.

I do think the NGINX approach has value, but question if it really needs standardization and what value that would have.   It is strictly focused on cookies.  I thought NGINX stripped the over signing before it passed the cookie to the app, so that it was transparent.   The only thing that might see the wrapped cookie is the browser and I don’t know that standardizing the wrapping so that browser JS can inspect it has value.

I could perhaps see it if you hat TTP from multiple vendors that all needed to deal with the same cookie.  That might be a reason if someone wanted to write it up as a ID and submit it to the WG.    I don’t know if people would see value in working on it for what might be considered a edge case.

Thanks for the feed back
John B.

> On Aug 3, 2017, at 11:47 AM, Bill Cox <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Bill Cox <[email-masked]>
Date: Thu, 3 Aug 2017 09:09:53 -0700

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 <[email-masked]> wrote:

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

---

From: Brian Campbell <[email-masked]>
Date: Thu, 3 Aug 2017 13:43:44 -0600

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.

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