[Unbearable] Artart telechat review of draft-ietf-tokbind-negotiation-12

Matthew Miller <linuxwolf+ietf@outer-planes.net> Tue, 08 May 2018 20:35 UTC

Return-Path: <linuxwolf+ietf@outer-planes.net>
X-Original-To: unbearable@ietf.org
Delivered-To: unbearable@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6512EAC0; Tue, 8 May 2018 13:35:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Matthew Miller <linuxwolf+ietf@outer-planes.net>
To: <art@ietf.org>
Cc: unbearable@ietf.org, draft-ietf-tokbind-negotiation.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152581170538.16247.326421324193541615@ietfa.amsl.com>
Date: Tue, 08 May 2018 13:35:05 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/wqYb8qzv6GMvcTby80ZtLvI8nmY>
Subject: [Unbearable] Artart telechat review of draft-ietf-tokbind-negotiation-12
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 May 2018 20:35:06 -0000

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