Subject: [art] Artart telechat review of draft-ietf-tokbind-negotiation-12

From: Matthew Miller <[email-masked]>
Date: Tue, 08 May 2018 13:35:05 -0700

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

---

From: Andrei Popov <[email-masked]>
Date: Tue, 8 May 2018 21:49:41 +0000

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 <[email-masked]> 
Sent: Tuesday, May 8, 2018 1:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Artart telechat review of draft-ietf-tokbind-negotiation-12

Reviewer: Matthew Miller

IETF LC End Date: N/A

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:

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.

---

From: "Matthew A. Miller" <[email-masked]>
Date: Tue, 8 May 2018 17:13:03 -0600

> - 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 p…

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

---

From: Andrei Popov <[email-masked]>
Date: Wed, 9 May 2018 00:17:55 +0000

> 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 <[email-masked]> On Behalf Of Matthew A. Miller
Sent: Tuesday, May 8, 2018 4:13 PM
To: Andrei Popov <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Artart telechat review of draft-ietf-tokbind-negotiation-12

> - 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 p…

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.

- m&m

Matthew A. Miller

---

From: Adam Roach <[email-masked]>
Date: Tue, 8 May 2018 20:04:02 -0500

> 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 toke…

If I read Matthew's request correctly, all he is asking is that you add 
words to the document that say exactly what you say above. Right now, 
the implication in the document is that the client is required to 
continue to use the connection as if nothing is wrong.

/a

---

From: Andrei Popov <[email-masked]>
Date: Wed, 9 May 2018 01:29:40 +0000

Sure, will add this clarification in the next revision.

Cheers,

Andrei

-----Original Message-----
From: Adam Roach <[email-masked]> 
Sent: Tuesday, May 8, 2018 6:04 PM
To: Andrei Popov <[email-masked]>; Matthew A. Miller <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [art] Artart telechat review of draft-ietf-tokbind-negotiation-12

On 5/8/18 7:17 PM, Andrei Popov wrote:
> 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, ...)

If I read Matthew's request correctly, all he is asking is that you add words to the document that say exactly what you say above. Right now, the implication in the document is that the client is required to continue to use the connection as if nothing is wrong.

/a