MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 19 Mar 2017 10:12:35 -0700
Message-ID: <CABcZeBOaX8W6XSekcn4Cth1ofZxxe6Dg6Pmrj6nrAwN2BneC1Q@mail.gmail.com>
To: IETF Tokbind WG <unbearable@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c087358cad09e054b188632
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/thp6ORn_dbs9nRbybt5qIXhixrI>
Subject: [Unbearable] draft-campbell-tokbind-tls-term architecture.
Precedence: list

--94eb2c087358cad09e054b188632
Content-Type: text/plain; charset=UTF-8

I have read this document. Comments below.

OVERALL
In S 2 you say:

   Reverse proxies MUST only add the "Token-Binding-Context" header when
   explicitly configured to do so and MUST only dispatch requests
   containing it to trusted backend servers.  Any occurrence of the
   "Token-Binding-Context" header in the request from the client MUST be
   removed or overwritten before forwarding the request.  Backend
   servers MUST only accept the "Token-Binding-Context" header when
   explicitly configured to do so and only from trusted reverse proxies.

As well as/instead of requiring proxies to sanitize, why not make it
not possible for the client to construct a valid header. One way to
do this would be to require that the header be MACed with a shared
key between the proxy and the server.

Also, I think some analysis of why this header doesn't need to be
in Sec-* would be valable. I am assuming your argument is going
to be that it's always stripped by proxies?


S 1.
Nit:
   standardized approach, different implementations will will address it

Duplicate will

-Ekr

--94eb2c087358cad09e054b188632
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I have read this document. Comments below.</div><div>=
<br></div><div>OVERALL</div><div>In S 2 you say:</div><div><br></div><div>=
=C2=A0 =C2=A0Reverse proxies MUST only add the &quot;Token-Binding-Context&=
quot; header when</div><div>=C2=A0 =C2=A0explicitly configured to do so and=
 MUST only dispatch requests</div><div>=C2=A0 =C2=A0containing it to truste=
d backend servers.=C2=A0 Any occurrence of the</div><div>=C2=A0 =C2=A0&quot=
;Token-Binding-Context&quot; header in the request from the client MUST be<=
/div><div>=C2=A0 =C2=A0removed or overwritten before forwarding the request=
.=C2=A0 Backend</div><div>=C2=A0 =C2=A0servers MUST only accept the &quot;T=
oken-Binding-Context&quot; header when</div><div>=C2=A0 =C2=A0explicitly co=
nfigured to do so and only from trusted reverse proxies.</div><div><br></di=
v><div>As well as/instead of requiring proxies to sanitize, why not make it=
</div><div>not possible for the client to construct a valid header. One way=
 to</div><div>do this would be to require that the header be MACed with a s=
hared</div><div>key between the proxy and the server.</div><div><br></div><=
div>Also, I think some analysis of why this header doesn&#39;t need to be</=
div><div>in Sec-* would be valable. I am assuming your argument is going</d=
iv><div>to be that it&#39;s always stripped by proxies?</div><div><br></div=
><div><br></div><div>S 1.</div><div>Nit:</div><div>=C2=A0 =C2=A0standardize=
d approach, different implementations will will address it</div><div><br></=
div><div>Duplicate will</div><div><br></div><div>-Ekr</div><div><br></div><=
div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><=
/div>

--94eb2c087358cad09e054b188632--