Hi Matthew, Thanks for the review and feedback. The idea is that: - It is an error for the server to respond with a TB protocol version higher than the one advertised by the client. Since the client advertises its highest supported version, it makes no sense for the server to offer a higher version. If this happens, the client MUST terminate the TLS handshake. - On the other hand, the server is allowed to offer a lower TB protocol version; if the client happens to support this lower TB version, the connection proceeds with TB. Otherwise, the connection proceeds without TB. Please let me know if I can further clarify, Cheers, Andrei -----Original Message----- From: Matthew Miller <linuxwolf+ietf@xxxxxxxxxxxxxxxx> Sent: Tuesday, May 8, 2018 1:35 PM To: art@xxxxxxxx Cc: unbearable@xxxxxxxx; draft-ietf-tokbind-negotiation.all@xxxxxxxx; ietf@xxxxxxxx Subject: Artart telechat review of draft-ietf-tokbind-negotiation-12 Reviewer: Matthew Miller Review result: Ready with Issues 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
