[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
- [Unbearable] Artart telechat review of draft-ietf… Matthew Miller
- Re: [Unbearable] Artart telechat review of draft-… Andrei Popov
- Re: [Unbearable] Artart telechat review of draft-… Matthew A. Miller
- Re: [Unbearable] Artart telechat review of draft-… Andrei Popov
- Re: [Unbearable] [art] Artart telechat review of … Adam Roach
- Re: [Unbearable] [art] Artart telechat review of … Andrei Popov