Telechat Review of draft-ietf-tokbind-negotiation-12
review-ietf-tokbind-negotiation-12-artart-telechat-miller-2018-05-08-00

Request Review of draft-ietf-tokbind-negotiation
Requested revision No specific revision (document currently at 14)
Type Telechat Review
Team ART Area Review Team (artart)
Deadline 2018-05-08
Requested 2018-03-19
Authors Andrei Popov , Magnus Nyström , Dirk Balfanz , Adam Langley
I-D last updated 2018-05-08
Completed reviews Genart Last Call review of -10 by Paul Kyzivat (diff)
Secdir Last Call review of -10 by Hilarie Orman (diff)
Opsdir Last Call review of -10 by Will (Shucheng) LIU (diff)
Artart Telechat review of -12 by Matthew A. Miller (diff)
Genart Telechat review of -12 by Paul Kyzivat (diff)
Assignment Reviewer Matthew A. Miller
State Completed
Request Telechat review on draft-ietf-tokbind-negotiation by ART Area Review Team Assigned
Reviewed revision 12 (document currently at 14)
Result Ready w/issues
Completed 2018-05-08
review-ietf-tokbind-negotiation-12-artart-telechat-miller-2018-05-08-00
IETF LC End Date: N/A
IESG Telechat date: 2018-05-10

Summary:  Ready with a potential issue.


Major issues:  N/A

Minor issues:

In reading the client's processing of the server's "token_binding"
extension, there seems to be the potential for falling through the
cracks with regards to version:

* client MUST terminate the TLS handshake if the server's
  TB_version is greater than the client's highest supported
* client (MUST? SHOULD? MAY?) continue the TLS handshake **without
  Token Binding** if the server's TB_version is not one the client
  is willing to use (e.g., lower than the client's minimum
  acceptable version)
  
As written, it seems that a client that requires token binding has
to finish TLS negotiation, then reject further interactions at
the application level, but it's not clear this is the expected or
best approach.  I think it's worth adding at least some language
about this scenario.

Nits/editorial comments:  N/A