> Does that mean clients can never require TB, or that such a requirement is enforced somehow at the application layer, or something else? TB has cryptographic costs associated with it, so a server would only enable TB when there is a benefit (e.g. a server that does not produce or consume tokens would not benefit from TB). Therefore, it would not make sense for a general-purpose client (such as a Web browser) to require TB on every connection. Application-specific clients and servers (custom apps) can reject connections without TB, or they can implement a variety of other measures when TB is not negotiated (e.g., issue shorter-lived tokens, require stronger authentication, ...) I don't think it would be beneficial to specify what different kinds of apps should do when TB cannot be negotiated with a server (except for the protocol error cases, such as the server returning a higher TB version than the one the client advertised). Cheers, Andrei -----Original Message----- From: Matthew Miller <linuxwolf@xxxxxxxxxxxxxxxx> On Behalf Of Matthew A. Miller Sent: Tuesday, May 8, 2018 4:13 PM To: Andrei Popov <Andrei.Popov@xxxxxxxxxxxxx>; art@xxxxxxxx Cc: unbearable@xxxxxxxx; draft-ietf-tokbind-negotiation.all@xxxxxxxx; ietf@xxxxxxxx Subject: Re: Artart telechat review of draft-ietf-tokbind-negotiation-12 On 18/05/08 15:49, Andrei Popov wrote: > 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. > Does that mean clients can never require TB, or that such a requirement is enforced somehow at the application layer, or something else? >From my experience, clients will do what clients will do -- with no guidance on what to do when the client really needs TB but the negotiated support leads to "no TB", there will be several ways clients will implement TB enforcement, which can lead to interoperability problems. I think we'd rather have some up-front guidance if at all possible. I'm happy to suggest some text, but it may take me a bit. - m&m Matthew A. Miller > > -----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 > >
