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

From: =JeffH <[email-masked]>
Date: Thu, 9 Feb 2017 09:04:33 -0800

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

correct, agreed.

 > Sec-Token-Binding shouldn't be listed in Connection header field by
 > a client.

listing Sec-Token-Binding in the Connection header means ([RFC7230] 
Section 6.1)..

    6.1.  Connection

     The "Connection" header field allows the sender to indicate desired
     control options for the current connection.  In order to avoid
     confusing downstream recipients, a proxy or gateway MUST remove or
     replace any received connection options before forwarding the
     message.

..which is what we want by default for security considerations reasons, 
I think.

As Dirk noted:
  >
  > If the proxy has qualms about violating the spec by forwarding the
  > Sec-Token-Binding header despite its being listed in the Connect
  > header, it can always just use a different header name, like
  > "Private-Forwarded-Token-Binding", or whatever - some  mechanism
  > proprietary to the proxy and downstream server.

Thus, a comment on 
<https://tools.ietf.org/html/draft-campbell-tokbind-tls-term> (which 
i'll endeavor to write up more fully anon) is that it should either 
define another header field for conveyance of the 
EncodedTokenBindingMessage (along with the header field it already 
defines) or have the header field it already defines convey both the 
EncodedTokenBindingMessage and the EKM et al.

=JeffH

---

From: Andrei Popov <[email-masked]>
Date: Thu, 9 Feb 2017 18:18:17 +0000

Hi Jeff,

If you agree that the client, generally, does not know whether the proxy/TLS terminator validates TB or passes it on to the back-end server, then why do you argue that the client should require the proxy to drop TB headers? I believe the client should not interfere with this and let datacenter infrastructure figure out how/where to handle TB headers.

> ..which is what we want by default for security considerations reasons, I think.
Sorry, what security considerations reasons are you referring to?

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Thursday, February 9, 2017 9:05 AM
To: IETF TokBind WG <[email-masked]>
Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

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

correct, agreed.

 > Sec-Token-Binding shouldn't be listed in Connection header field by  > a client.

listing Sec-Token-Binding in the Connection header means ([RFC7230] Section 6.1)..

    6.1.  Connection

..which is what we want by default for security considerations reasons, I think.

  > proprietary to the proxy and downstream server.

Thus, a comment on
<https://tools.ietf.org/html/draft-campbell-tokbind-tls-term> (which i'll endeavor to write up more fully anon) is that it should either define another header field for conveyance of the EncodedTokenBindingMessage (along with the header field it already
defines) or have the header field it already defines convey both the EncodedTokenBindingMessage and the EKM et al.

=JeffH

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 10 Feb 2017 07:51:32 +1300

> Sorry, what security considerations reasons are you referring to?

* Leaking the TB values from TLS terminating proxies. *unless* they are
intentionally non-validating reverse-proxies.

* to be sure the Sec-Token-Binding actually belongs to the TLS
connection the HTTP message was transmitted over. Not being injected by
an attacker.

* to pevent multiple Sec-Token-Binding being delivered on a message if
there happened to be multiple different TLS hops along the way. To
ensure attackers can't just send multiple TBH and hope one gets accepted.

Amos