Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

[John Bradley <[e-mail]>]

If it is negotiating token binding with the server then it can’t pass along the original token binding in the same header without significant confusion I suspect.

The bigger short term question is what should a proxy that doesn’t understand token binding do.  If token binding is signalled from the user agent as hop by hop then it should drop the header.

I think it is better for the server to get no token binding header than one from a client that thinks it has negotiated token binding but it cant validate.

The Include-Referred-Token-Binding-ID header should be end to end and not removed by proxies.

John B.

> On Feb 9, 2017, at 3:48 PM, Andrei Popov <[e-mail]> wrote:
> 
> Ø  I dont know that a proxy that doesn’t understand token binding should forward the header especially in the forward case.
> Ø   
> Ø  What if the forward proxy is negotiating it’s own token binding  to the server?  (should a forward proxy proxy do that is perhaps another question)
>  
> Would you agree that if a proxy is negotiating its own TB to the server, then this proxy is TB-aware, and knows what to do about the client’s TB header?
>  
> From: John Bradley [mailto:[e-mail]] 
> Sent: Thursday, February 9, 2017 10:41 AM
> To: Andrei Popov <[e-mail]>
> Cc: Brian Campbell <[e-mail]>; =JeffH Hodges <[e-mail]>; IETF TokBind WG <[e-mail]>
> Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?
>  
> That may be the rub.
>  
> From a header perspective we are talking about any proxy forward and reverse.
>  
> I dont know that a proxy that doesn’t understand token binding should forward the header especially in the forward case.
>  
> What if the forward proxy is negotiating it’s own token binding  to the server?  (should a forward proxy proxy do that is perhaps another question)
>  
> I understand the desire to pass the header on in the reverse proxy case as it may make server code easier.
>  
> However I take Jeff’s point that token binding is by its nature hop by hop and if we mess with that we may get some unintended side effects.
>  
> If Brian had proposed sticking everything in one or two  new headers and removing the existing one then this would be much less controversial.
>  
> I always thought that we could use the same header on the inside of the proxy, but can see why that might mess up some other expectations.
>  
> So is token binding hop by hop?
>  
> John B.
>  
> On Feb 9, 2017, at 3:25 PM, Andrei Popov <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Exactly, I agree with Brian. The proxy/terminator is better positioned to know how/where TB headers are handled in a particular datacenter. And a proxy/terminator that knows nothing about TB headers should forward them on.
>  
> From: Unbearable [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Brian Campbell
> Sent: Thursday, February 9, 2017 8:38 AM
> To: =JeffH <[e-mail] <mailto:[e-mail]>>
> Cc: IETF TokBind WG <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?
>  
>  
>  
> On Thu, Feb 9, 2017 at 9:55 AM, =JeffH <[e-mail] <mailto:[e-mail]>> wrote:
> 
> I agree with this for security considerations reasons -- we want the Sec-Token-Binding header to be hop-by-hop in sync with the underlying TLS connection and not be "leaked" downstream unless it is a conscious decision, e.g., in the tls terminating reverse proxy (TTRP) case.
> 
>  
> But the client is only making a connection to a server and client does not know whether it makes sense for that server to forward or not. And it shouldn't know that.  Sec-Token-Binding shouldn't be listed in Connection header field by a client. 
>  
> _______________________________________________
> Unbearable mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>