Subject: [Unbearable] WGLC comments on -tokbind-protocol-11 - S 4.2 Server Processing Rules

From: =JeffH <[email-masked]>
Date: Thu, 8 Dec 2016 12:05:52 -0800

S 4.2.  Server Processing Rules
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-11#section-4.2

this section only tangentially stipulates that the server must actually 
verify the signatures in a Token Binding Message (TBM). the relevant 
parag is this one..

    If the Token Binding message does not contain at least one
    TokenBinding structure, or if a signature contained in any
    TokenBinding structure is invalid, the server MUST reject the
    binding.

..which implies that the server ought to check the signatures on any 
TokenBindings (TBs) in a TBM.  Is this sufficiently explicit (I have my 
doubts)? (there is also a non-normative mention of the server validating 
signatures in TBM in 3d parag of Overview)

also in this section, "rejection" of token bindings (and by implication, 
a containing TBM) is defined only at the end of S 4.2. Suggest moving it 
up to the beginning of the section, e.g., as a "Note".

Also the term "reject" implies conveying some info to the client in 
response, but that is not uniformly the case, as the actual form 
"rejection" might take is left up to the server-side app-layer and one 
of the example options is "failing requests".

I would use appropriate forms of the term "not accept" instead of 
"reject", and explain that "non acceptance" can take several forms (ie 
the ones already listed), as well as including "rejection".

Finally, the present initial parag, which is the 
triple-handshake-admonition, could also be made a "Note:" and shortened 
up since the admonition proper is (duplicated) in Sec Cons. Should xref 
to sec cons "for details". OR, we could remove it from here, since it is 
duplicated in TBPROTO sec cons, and also in TBNEGO.

HTH,

=JeffH

---

From: Andrei Popov <[email-masked]>
Date: Thu, 8 Dec 2016 20:17:26 +0000

> Also the term "reject" implies conveying some info to the client in response...
Merriam-Webster thinks "reject" means "refuse to accept, consider, submit to, take for some purpose, or use", no implied obligation to respond.
So I mildly prefer "reject" to "not accept" for brevity and avoidance of extra negation:).

Cheers,

Andrei