[Unbearable] Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)

Alexey Melnikov <aamelnikov@fastmail.fm> Sun, 06 May 2018 15:30 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 EA9B81200B9; Sun, 6 May 2018 08:30:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tokbind-negotiation@ietf.org, John Bradley <ve7jtb@ve7jtb.com>, tokbind-chairs@ietf.org, ve7jtb@ve7jtb.com, unbearable@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.79.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152562063795.26840.1916104340550306942.idtracker@ietfa.amsl.com>
Date: Sun, 06 May 2018 08:30:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/4vgpJzjmrYitnODmLwS6oYs7wF0>
Subject: [Unbearable] Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)
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: Sun, 06 May 2018 15:30:38 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-tokbind-negotiation-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I will be switching to "Yes" once one issue mentioned below is discussed:

I would like to have a quick discussion about your versionning model:

   struct {
       uint8 major;
       uint8 minor;
   } TB_ProtocolVersion;

What is the significance of "major" and "minor" versions?
Any rules on what kind of changed would require increment of the "major"
version. Any restrictions on what must remain the same when the "major" (or
"minor") version gets incremented? Any requirements on backward compatibility
when only the "minor" version is incremented?


In Section 2:

   "key_parameters_list" contains the list of identifiers of the Token
   Binding key parameters supported by the client, in descending order
   of preference.  [I-D.ietf-tokbind-protocol] defines an initial set of
   identifiers for Token Binding key parameters.

Wouldn't be better to point to the IANA registry established by [I-D.ietf-tokbind-protocol]?
My concern is that you might be misleading implementors into not looking there.