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

Andrei Popov <Andrei.Popov@microsoft.com> Mon, 07 May 2018 19:06 UTC

Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F109E12D962; Mon, 7 May 2018 12:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enILxlzQW8CE; Mon, 7 May 2018 12:06:47 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0121.outbound.protection.outlook.com [104.47.42.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF2C12D95E; Mon, 7 May 2018 12:06:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xlz3qKdh+ailTybtIbj1oa1etJCjnKcvptUn1lLsYGA=; b=e0oq8zYVo94qG67yTohcovPxRY4tpFiDqRggY5J54VIFLgB8NMdmZyP7iLs9rRP2ZAGBOTAiYgDWKQZO+cr1BdgYkCw8XMBoSSq4IHlgLmeUW5ioyuIUBdfkI9pK9fmyQ1a0ACX61zN3AbY6nXJ9isDyziN/uit3oMkmBL8wEh8=
Received: from DM5PR21MB0507.namprd21.prod.outlook.com (10.172.91.141) by DM5PR21MB0697.namprd21.prod.outlook.com (10.175.112.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.3; Mon, 7 May 2018 19:06:46 +0000
Received: from DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::49e8:420f:baa2:a62f]) by DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::49e8:420f:baa2:a62f%6]) with mapi id 15.20.0776.004; Mon, 7 May 2018 19:06:46 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
CC: "draft-ietf-tokbind-negotiation@ietf.org" <draft-ietf-tokbind-negotiation@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>, "ve7jtb@ve7jtb.com" <ve7jtb@ve7jtb.com>, "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)
Thread-Index: AQHT5U8wRxIW3ZvA5U+SaJCFD/1c9KQknTiw
Date: Mon, 7 May 2018 19:06:46 +0000
Message-ID: <DM5PR21MB0507C39C1A09C13C32385F2F8C9B0@DM5PR21MB0507.namprd21.prod.outlook.com>
References: <152562063795.26840.1916104340550306942.idtracker@ietfa.amsl.com>
In-Reply-To: <152562063795.26840.1916104340550306942.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:5::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR21MB0697; 7:fzAPG0OOdqNCsKH77XCEuW7Nm6vmyz+sO1h06ZnmhqxhvfwFwWx+iVk63QafqxkbzxscHcGLD1qorkFH9CmzOaNigY962IYl1yKQoCpfRrRyM89QNpPiZGrxhPE6Kar4rw9VF2NDxkQGxrO3jEsq0a4yK9YHme4OgWa2iZAm+6rDNir+CWiDNSWvmRcTWBTQN5GAc1mcB5WnF0nP+dmSjE53EZMjksSMHsLO4Q5auQyVVXoe2SyYB1XFXfXxsAbk; 20:YXs8ienN3Um94QQlrPpW4ORCbpTHi1Sslq5Ise4VqEYa6u93d6LIm6vmRLKTExQvzYtu20JOdvGTeLGy5Rhfy4mF/073HN7RTGEKrnFfPddY40FjfrG0aZNt62/4pByNgOKCFS0sWcrUHFJ/bVGBqzsm9njcr50n/6Sn11dK+LA=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR21MB0697;
x-ms-traffictypediagnostic: DM5PR21MB0697:
x-microsoft-antispam-prvs: <DM5PR21MB06976309AC8BF1699597C9D58C9B0@DM5PR21MB0697.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR21MB0697; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0697;
x-forefront-prvs: 066517B35B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(366004)(396003)(346002)(376002)(199004)(189003)(13464003)(446003)(6246003)(478600001)(10290500003)(99286004)(6506007)(54906003)(9686003)(6116002)(229853002)(86612001)(110136005)(59450400001)(476003)(5250100002)(11346002)(53546011)(486006)(53936002)(6306002)(316002)(86362001)(575784001)(81166006)(46003)(8936002)(102836004)(6346003)(4326008)(22452003)(3280700002)(305945005)(105586002)(33656002)(7736002)(68736007)(186003)(74316002)(10090500001)(106356001)(8676002)(81156014)(72206003)(3660700001)(14454004)(6436002)(76176011)(55016002)(7696005)(8666007)(966005)(97736004)(8990500004)(2900100001)(25786009)(5660300001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0697; H:DM5PR21MB0507.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-microsoft-antispam-message-info: ASqHfMBCyopyGhFuZ+3v1CI8wqDLmpSfh+Le8BB/zRNIYiKA8eVFcrrCHVial8rN2SkgrAdNKOkYAmpatWZmpQSNTomGeDshLzRHXQSn0gvRbpdjD3l4ie9iuq1YkV+opjDN8IqOe3GC6SKXYJEdzUNd3oeXP/atfpABBwB3LHSs8O59tf2hab10BCc9C8Ip
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: ba3cb669-e82b-4c1a-d40f-08d5b44dade3
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ba3cb669-e82b-4c1a-d40f-08d5b44dade3
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2018 19:06:46.4953 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0697
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/MEQdBIi5Rjub7CSP5XpMazEZdsc>
Subject: Re: [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
Precedence: list
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: Mon, 07 May 2018 19:06:54 -0000

Hi Alexey,

Thanks for reviewing the specs, I appreciate your comments.

> What is the significance of "major" and "minor" versions?
There is no normative significance; the version value is split into two parts for convenience of discussion only, so that we can talk about versions such as 0.10, 0.13, 1.0, etc.

> 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?
We have no such rules; it is common to increment the "major" protocol version when "significant" changes happen, but this is up to future protocol specs to define.

> Any requirements on backward compatibility when only the "minor" version is incremented?
There is no backward compatibility between different Token Binding protocol versions, regardless of which component of TB_ProtocolVersion changes.

> Wouldn't be better to point to the IANA registry established by [I-D.ietf-tokbind-protocol]?
Indeed, it may be better to say something like "[I-D.ietf-tokbind-protocol] establishes an IANA registry for Token Binding key parameters" or something to this effect.
I'll try to wordsmith this.

Cheers,

Andrei

-----Original Message-----
From: Alexey Melnikov <aamelnikov@fastmail.fm> 
Sent: Sunday, May 6, 2018 8:31 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tokbind-negotiation@ietf.org; John Bradley <ve7jtb@ve7jtb.com>om>; tokbind-chairs@ietf.org; ve7jtb@ve7jtb.com; unbearable@ietf.org
Subject: Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)

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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C59e09351f0fe4b2fb9ac08d5b366524f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636612174409112174&sdata=LDU%2F%2FEr7lCYt0gm0yExDVINW1DGJh5S5cJJRv%2FRULQY%3D&reserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tokbind-negotiation%2F&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C59e09351f0fe4b2fb9ac08d5b366524f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636612174409112174&sdata=ka1kQLpRehbQmXHtxHj73cqfGsRw1Axvk%2BS%2BjkbOatQ%3D&reserved=0



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.