Re: [Unbearable] More thoughts on reverse-proxies

[Brian Campbell <[e-mail]>]

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

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