Subject: Re: [Unbearable] Sec- prefix for Token-Binding headers (was: new draft-ietf-tokbind-https-03

From: =JeffH <[email-masked]>
Date: Mon, 21 Mar 2016 15:49:57 -0700

original issue:
Give the header a Sec-* prefix
https://github.com/TokenBinding/Internet-Drafts/issues/1

 > On 30 June 2015 at 03:09, Dirk Balfanz <[email-masked]> wrote:
 >> Hi guys,
 >>
 >> following Leif's request to mirror discussions here, I wanted to point out
 >> one discussion we're having over there regarding the Sec- prefix for the
 >> Token-Binding header:
 >> https://github.com/TokenBinding/Internet-Drafts/issues/1
 >>
 >> Anne favors a Sec- prefix (meaning it can't be set directly from
 >> Javascript), whereas Martin doesn't.
 >>
 >> I find Anne's arguments persuasive.

On 30 Jun 2015 09:41:09 Martin Thomson said:
 > This is wholly confused, as I explained in the issue.  The security of
 > token binding is based on the private key.  If it is not, then I think
 > we need to discuss how that is not sufficient.

On Mon, 21 Mar 2016 Dirk said:
 >
 > https://tools.ietf.org/html/draft-ietf-tokbind-https-03
 >
 > Changes since the last version:
 >
 > - The header has a Sec- prefix again.
 > ...

Hm. I don't see discussion of adding the "Sec-" header field prefix back to 
the token-binding header field. What's the motivation for doing so? issue #1 
was closed 30-Jun-2015.

in any case, here are relevant references into the fetch() spec..

https://fetch.spec.whatwg.org/#forbidden-header-name

https://fetch.spec.whatwg.org/#http-header-layer-division

So, from the above references, it seems that if we have the "Sec-" prefix to 
the token-binding header field, we are essentially saying that the user 
agent will automagically handle TB negotiation at the TLS layer, and also 
automagically include the token-binding header in any and all HTTP request 
messages sent to a server with which TG was successfully negotiated, and 
this is /not/ under the control of any web application that may be being 
served by said server, yes?

Are folks imagining giving a client-side web app the ability to control 
whether TB is negotiated when HTTPS connections are established? Or is it 
intended to be automatic?

Having it be automatic sounds nominally ok to me in the case of only one 
server, but I'm wondering whether it would be an issue in the federation use 
case(s) where the client-side web application may need to craft a TBMSG (and 
thus token-binding header conveying that TBMSG) containing the correct 
referred TBID, and thus may need an API to facilitate doing so. [see the 
"Referred token binding IDs" thread]

Hm, I'm curious, to what extent are federated Web SSO protocols being baked 
directly into the browsers? The answer was "none" a while back, but is that 
changing?

In terms of the actual -tokbind-https-03 spec, if the Sec- header prefix is 
kept, the implications ought to be described and security considerations added.

One consideration I can think of if there is no "Sec-" header prefix is 
whether we recommend that the TBMSG creation and sending of the TBMSG be 
done in by the user agent or the web app, and if it ends up being embedded 
in browsers, then the web app code could still craft TBMSGs and add them to 
requests.

in any case we need to stipulate whether or not the server honors any, only 
one, or all received token-binding headers in a received HTTP msg. In HSTS 
and HPKP we explictly state the server honors on the first header field in a 
received HTTP msg.

HTH,

=JeffH

---

From: Dirk Balfanz <[email-masked]>
Date: Tue, 22 Mar 2016 03:43:06 +0000

Hi Jeff,

I was told that in Yokohama it was decided to add the Sec- prefix again. (I
wasn't at that meeting.)

As for the security considerations, they already state that a
man-in-the-middle shouldn't be able to pick the value of the
(Sec-)Token-Binding header. One corollary of that is that the value of the
(Sec-)Token-Binding header can't be set by application (Javascript) code
(since that is potentially controlled by a man-in-the-middle). But perhaps
it bears saying that explicitly. Wanna open an Issue?

Dirk.

On Mon, Mar 21, 2016 at 3:50 PM =JeffH <[email-masked]>
wrote:

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

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 22 Mar 2016 19:08:55 +1300

> I was told that in Yokohama it was decided to add the Sec- prefix again. (I

Note that HTTP (RFC 7231 section 8.2.1) header naming requirements state:
"Authors of specifications defining new fields are advised to keep the
name as short as practical"

HTTP also does not define anything like namespaces within header names.
So "Sec-" has no meaning according to HTTP. If there is a document
defining such a namespace that means "Sec-" needs to be added in
violation of the "short as practical" consideration, then it should be
referenced for context in section 2.

This has prompted me to take a look at this draft in regards to the HTTP
requirements. I'm afraid to report that its in rather bad state in
respect to BCP 90 compliance. <http://tools.ietf.org/html/bcp90>

* Sec-Token-Binding does have section 2 to itself, but is still lacking
mention of many of the semantic details required by BCP 90 section 4.

I did see some details spread out elswhere around the draft, so its
likely they are mostly there somewhere. But they should be a far more
coherent set of semantic statements for HTTP implementers just wanting
to ensure the header is handled correctly by the HTTP layer without
caring about any Token Binding or TLS layer logics.

* Include-Referer-Token-Binding-ID semantics are buried in section 3.3

This may also be an overly-long header name in respect to the above
mentioned RFC7231 requirement about header naming.

IMO the header should have a section 2.x to itself outlining explicitly
and clearly the details required by BCP 90 section 4.

The document structure something along the lines of:
 Section 2 HTTP Headers
 Section 2.1 The Sec-Token-Binding Header
 Section 2.2 The Include-Referer-Token-Binding-ID Header
 Section 3 First Party Use Cases
 ...
 Section 4 Federation Use Cases
 ...

* complete lack of "IANA considerations" section for header registry
templates.

Editorial Issues:

* section 1 states that the draft covers both first-party and federated
use cases. But there is only section 3 outlining federated cases. No
clearly visible section for the first-party use case.

* in section 3.1 it says "the Sec-Token-Binding HTTP header defined above".

Should that not be an explicit "section 2" (2.1?) reference instead of
the word "above" ?

* in section 4.2  "manterial" -> material

* in section 4.3 paragraph 4 it says "A client shouldn't be tricked into
sending a Sec-Token-Binding header to a server that"

That specific wording is just telling malicious actors "dont be bad".
Which is useless. Surely it should be saying to clients not to let
themselves be tricked.

* I spy several lower-case "must", "must not", "should", "should not"
and "may" dotted around the document. Are those normative requirements
or just confusing wording?

* please pick a consistent formula for the Security Considerations and
Privacy Consuderations entries before this goes to LC.

Right now there is a mix of conceptual orderings:
 - problem, solution requirements
 - requirements, problem, solution requirements
 - problem, detailed examples, requirements
 - problem, detailed examples, some requirements, detailed examples,
more requirements

If one wants to skip the rather dense explanatinos and details of
attacks and just check that the requirements are met its quite hard to
see what those actually are.
 I suggest sticking with problem and requirements in quick prefix
paragraphs, _then_ details and examples (if necessary).

Cheers
AYJ

---

From: Leif Johansson <[email-masked]>
Date: Thu, 24 Mar 2016 09:17:12 +0100

On 2016-03-22 04:43, Dirk Balfanz wrote:
> Hi Jeff, 
> 
> I was told that in Yokohama it was decided to add the Sec- prefix again.
> (I wasn't at that meeting.)

There was consensus to that effect.

---

From: John Bradley <[email-masked]>
Date: Thu, 24 Mar 2016 08:41:50 +0000

Yes
> On Mar 24, 2016, at 8:17 AM, Leif Johansson <[email-masked]> wrote:
>

---

From: Dirk Balfanz <[email-masked]>
Date: Thu, 31 Mar 2016 14:57:13 +0000

Thanks for the comments. One question:

The security/privacy considerations sections are not normative. I was under
the impression that it's not within the scope of this spec to tell
implementors of browsers what they need to do in order to achieve security
and privacy. Rather, the goal of the spec is to say enough to ensure
interoperability between clients and servers. It just happens to be the
case that prefixing the header name with Sec- is an interoperability
specification that also addresses the security issues, so that's a
requirement we've put into the normative part of the spec.

(Ok, now the actual question:) Can you think of other requirements flowing
from the security and privacy sections that should make it into the
normative parts of the spec?

re/ spelling: I was trying to be consistent and spell it 'MUST' (etc.) in
normative parts of the spec, and 'must' in non-normative parts. What is
best practice here?

Dirk.