Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies

[Piotr Sikora <[e-mail]>]

Well, it's kind of given that requests are sent only to backends that
are configured for a particular domain. That applies to whole
requests, and not only to Provided-Token-Binding-ID header, so I think
this is unnecessary restriction that will only confuse readers.

Best regards,
Piotr Sikora

On Mon, Jul 17, 2017 at 2:29 PM, Brian Campbell
<[e-mail]> wrote:
> For any given domain, a CDN would know the origin server(s) where it should
> forward requests it cannot fulfill, right?
>
> That's what I was trying to get at in the statement in the draft - that the
> reverse proxy only dispatch requests to origin sever(s) known/configured to
> be associated with the domain of the original request. Perhaps "trust" isn't
> the right word and that sentence can be reworded to be more reflective of
> that? Or is such a restriction/requirement so implicit in the deployment of
> any reverse proxy so doesn't need any treatment in this document?
>
> On Mon, Jul 17, 2017 at 1:18 PM, Piotr Sikora <[e-mail]>
> wrote:
>>
>> Hey Brian,
>> from the CDN point of view, all backend servers are untrusted, but I
>> don't see any reason why CDNs shouldn't forward
>> Provided-Token-Binding-ID to the origin servers.
>>
>> Also, Token Binding is supposed to protect Cookies (among other
>> things), which don't have such restriction, so this seems unnecessary.
>>
>> Best regards,
>> Piotr Sikora
>>
>> On Mon, Jul 17, 2017 at 12:53 PM, Brian Campbell
>> <[e-mail]> wrote:
>> > To be honest, I didn't have a specific attack vector or security/privacy
>> > implication in mind around that. It just seemed like something that
>> > should
>> > generally be part of reverse proxy set up. Do you think it's too
>> > restrictive/perspective? Or do you know of some use-case where a reverse
>> > proxy wouldn't know/trust the servers that it sits in front of?
>> >
>> > On Mon, Jul 17, 2017 at 12:37 PM, Piotr Sikora <[e-mail]>
>> > wrote:
>> >>
>> >> Hey Brian,
>> >> looks good, thanks for working on that!
>> >>
>> >> One question:
>> >>
>> >> >   Reverse proxies SHOULD only add the headers to requests that are
>> >> >   forwarded to trusted backend servers.
>> >>
>> >> Why? What's the attack vector, security and/or privacy implications
>> >> here?
>> >>
>> >> Best regards,
>> >> Piotr Sikora
>> >>
>> >> On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell
>> >> <[e-mail]> wrote:
>> >> > Just a not-so-subtle reminder that HTTPS Token Binding with TLS
>> >> > Terminating
>> >> > Reverse Proxies is one of the agenda items for Monday's meeting in
>> >> > Prague
>> >> > and it would be great if there was some familiarity with it going
>> >> > into
>> >> > the
>> >> > meeting. It's relativity short as drafts go, if you're looking for
>> >> > something
>> >> > to read en route to the meeting:
>> >> > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00
>> >> >
>> >> > 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.
>> >> > _______________________________________________
>> >> > 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.
>
>
>
> 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.