Re: [Unbearable] More thoughts on reverse-proxies

[John Bradley <[e-mail]>]

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