Re: [Unbearable] Dealing with header injection through reverse proxies

Hey Brian,

> I perhaps didn't articulate it well in the meeting yesterday but I'd like to
> reiterate that, in my opinion and I don't think I'm alone, it would be very
> inappropriate for -tokbind-ttrp to define a one-off mechanism for the origin
> server to detect client injection of the headers. The potential problem of
> client header injection is not at all unique to the functionality of that
> draft so the draft shouldn't define a unique solution. It would be useful if
> there were a common standardized mechanism for doing detecting/preventing
> client header injection that the -tokbind-ttrp draft could refer to (the
> generic solution that Ekr mentions in his [1] seems preferable precisely
> because it is generally applicable). In the absence of a generic solution
> existing currently, stripping/sanitizing the headers is the de facto means
> of dealing with the situation in practice today, is sufficient when properly
> implemented, and is normatively required by the text in -tokbind-ttrp. It's
> true that, if the reverse proxy is defective/misconfigured, it doesn't fail
> safe but in the context of -tokbind-ttrp that failure mode is far from
> catastrophic. Such a failure loses the protections afforded by token
> binding, which is not ideal, but it is the current state of just about
> everything on the web today so it's not *that* bad.

I agree. I don't believe that TOKBIND-TTRP draft should be blocked on this.

Best regards,
Piotr Sikora

Received on Tuesday, 18 July 2017 09:24:07 UTC