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

From: =JeffH <[email-masked]>
Date: Wed, 30 Mar 2016 16:56:20 -0700

Hi Amos, thanks for your review..

On 3/21/16, 11:08 PM, "Unbearable on behalf of Amos Jeffries"
<[email-masked] on behalf of [email-masked]> wrote:
 >On 22/03/2016 4:43 p.m., 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.)
 >>
 >
 >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.

agreed overall.

PR#19 <https://github.com/TokenBinding/Internet-Drafts/pull/19> has fixes
(more or less) for most all of the above comments, corrects
various superseded references, and adds a couple new ones.

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

thanks for again for reviewing.

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

I tend to agree that the spec's overall structure could be re-crafted more
along those lines, for example as is done in
<https://tools.ietf.org/html/rfc6797>.  What do others think?

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

this is (nominally) addressed in PR#19.

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

I tend to agree that the above items are things the co-authors should
consider addressing in order to editorially improve the spec.

thanks,

=JeffH