Re: [whatwg/fetch] Update Fetch to support Token Binding. (#325)

vanupam commented on this pull request.



> + containing a signature (using <var>providedTokenBindingKeyPair</var>) over the
+ <var>providedTokenBindingId</var> as well as <var>tlsConnection</var>'s
+ <a for=connection>token-binding Exported Keying Material</a>, as described in
+ <a href="https://tools.ietf.org/html/draft-ietf-tokbind-protocol#section-3.3">section 3.3</a>
+ of [[!TOKBIND-PROTOCOL]].
+
+ <li><p>Set <var>tokenBindingMessage</var> to a list containing <var>providedTokenBinding</var>
+ as the only <a for=/>token binding</a>.
+
+ <li><p>If <var>httpRequest</var>'s <a for=request>referred-token-binding origin</a> is not null,
+ then run these substeps:
+  <ol>
+   <li><p>Let <var>referredTlsConnection</var> be the result of
+   <a lt="obtain a connection" for=connection>obtaining a connection</a> for
+   <var>httpRequest</var>'s <a for=request>referred-token-binding origin</a>
+   with credentials <code>true</code> from the <a>connection pool</a>.

Having the origin + key parameters as input creates the ability for a server to force a client to move to supported-by-client but more-preferred-by-server crypto algorithms + params. Without that, we have no way to make a client move away from what was first negotiated.

Yes, in the JS API case this causes a connection to be created, but presumably the script is asking for a token to be used soon with a target server, so effectively we are setting up the connection shortly before using it.

Thoughts?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/325#discussion_r181540429