Last Call Review of draft-ietf-tokbind-https-14
review-ietf-tokbind-https-14-opsdir-lc-chown-2018-05-08-00
| Request | Review of | draft-ietf-tokbind-https |
|---|---|---|
| Requested revision | No specific revision (document currently at 18) | |
| Type | IETF Last Call Review | |
| Team | Ops Directorate (opsdir) | |
| Deadline | 2018-03-12 | |
| Requested | 2018-02-26 | |
| Authors | Andrei Popov , Magnus Nyström , Dirk Balfanz , Adam Langley , Nick Harper , Jeff Hodges | |
| I-D last updated | 2018-12-19 (Latest revision 2018-06-26) | |
| Completed reviews |
Secdir IETF Last Call review of -15
by Tobias Gondrom
(diff)
Genart IETF Last Call review of -14 by Linda Dunbar (diff) Opsdir IETF Last Call review of -14 by Tim Chown (diff) |
|
| Assignment | Reviewer | Tim Chown |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-tokbind-https by Ops Directorate Assigned | |
| Reviewed revision | 14 (document currently at 18) | |
| Result | Ready | |
| Completed | 2018-05-08 |
review-ietf-tokbind-https-14-opsdir-lc-chown-2018-05-08-00
I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a set of mechanisms that allow HTTP servers to cryptographically bind security tokens such as cookies and OAuth tokens to TLS connections for both first-party and federated scenarios, the latter being cases where the tokens are bound to a TLS connection the client has with a server other than the one issuing the token. The document is well structured and written. It is Ready for publication, with minor nits. Minor comments/nits: Some prior knowledge is assumed, and some terms not expanded on first use, but there is no terminology section. It may be useful to include a diagram of the relationship between the various elements in a federated scenario; I found myself drawing this while reading the document the first time through. In the diagram in Section 5.1, is that a different signature associated with TBID1 and TBID2, if so perhaps label as signature1 and signature2? There is some mixture of 'should' and 'SHOULD' through the document, likewise 'must' and 'MUST'; is this intentional? In some cases, lower case seems OK, but in others, it's not so clear, e.g., the last bullet point of Section 7 would seem to be a SHOULD not a should?