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

Mike Jones <Michael.Jones@microsoft.com> Wed, 09 May 2018 19:50 UTC

Return-Path: <Michael.Jones@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 C6FC7127909; Wed, 9 May 2018 12:50:55 -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 CK1nWgbiCQEa; Wed, 9 May 2018 12:50:53 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0137.outbound.protection.outlook.com [104.47.32.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0776F127863; Wed, 9 May 2018 12:50:52 -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=9wACibxxIH2DD0SJus3wvumuIEYrxRlBlet9XTTMkuE=; b=ZJLfJF/CEyXk1xE4hIGUsoyE0g+XYzcqlXoZpice5bCMlzcD8xP1/2xHFHvSy7JVajJapk2tpAmtdCa5FFPQ5FflWBV7M/Do68ij1m9whgN/2gOMwdAgsbTJVQP7fKey7woUK1TFIN0F40qM/9gqRL2AH+NdF/xc8uwgRHAdXbk=
Received: from DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) by DM5PR00MB0311.namprd00.prod.outlook.com (2603:10b6:4:9f::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.795.0; Wed, 9 May 2018 19:50:51 +0000
Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::7852:c9c0:a87:36c3]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::7852:c9c0:a87:36c3%4]) with mapi id 15.20.0794.000; Wed, 9 May 2018 19:50:51 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>, Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
CC: "ve7jtb@ve7jtb.com" <ve7jtb@ve7jtb.com>, "draft-ietf-tokbind-negotiation@ietf.org" <draft-ietf-tokbind-negotiation@ietf.org>, "unbearable@ietf.org" <unbearable@ietf.org>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>
Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)
Thread-Index: AQHT58JCTJIxXJDXTEKah5wzOEn1saQnzSfg
Date: Wed, 09 May 2018 19:50:50 +0000
Message-ID: <DM5PR00MB02969C46813040FA9AE44BD7F5990@DM5PR00MB0296.namprd00.prod.outlook.com>
References: <152562063795.26840.1916104340550306942.idtracker@ietfa.amsl.com> <DM5PR21MB0507C39C1A09C13C32385F2F8C9B0@DM5PR21MB0507.namprd21.prod.outlook.com> <1525879084.3938368.1366298224.73E1E829@webmail.messagingengine.com> <DM5PR21MB05070DBF7858604599D2A14A8C990@DM5PR21MB0507.namprd21.prod.outlook.com>
In-Reply-To: <DM5PR21MB05070DBF7858604599D2A14A8C990@DM5PR21MB0507.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-09T19:50:48.1900721Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:c::36]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR00MB0311; 7:Y/b/rjFGgGa+oOB6SlU4wlZMlt4f8R2g5vK3KSIvXeKA5Eg04B90HRbeRBQl4F7Ft2qZu3qWHRAyAy+jUBXOg6vtYtSXbZmMdXWiBgDV9eNfYyXM++vNion0CMPDkwnz8cQkvsWMtBdyWzwcnDCC2L+o6ayMTz5TZJmC/XBrqfMLhqKi0+kSSgLp5NYtLTSN2HpW14CtZ1mokhOw7UFV0IaJ0DnES0cgd/fXSWteW8cGl2P/43AmCNwsmVCqrdsC; 20:lAtp5mjTJN0PpuPFhiAUyaheYXoxyRQvCSUTsC5pOqxWPs6JY2351sguXLUE/PGgU8t+wZbPG3Jd55aDAC6dQ3hWZSWimooAT3XOLk9B0RnSLckNU8MthXb17iPVsHtTKiAC7QFcGyWYpJCtPfdG43V2+euaouejXMkPOP0eILs=
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)(2017052603328)(7193020); SRVR:DM5PR00MB0311;
x-ms-traffictypediagnostic: DM5PR00MB0311:
x-microsoft-antispam-prvs: <DM5PR00MB031162693260C1D05F492642F5990@DM5PR00MB0311.namprd00.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(189930954265078)(788757137089)(100405760836317)(219752817060721);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR00MB0311; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0311;
x-forefront-prvs: 0667289FF8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(366004)(396003)(346002)(376002)(13464003)(69234005)(189003)(199004)(486006)(11346002)(476003)(6116002)(46003)(446003)(3660700001)(102836004)(229853002)(25786009)(1511001)(6506007)(53546011)(6246003)(6346003)(4326008)(97736004)(86362001)(3280700002)(53936002)(55016002)(575784001)(9686003)(6306002)(8666007)(10290500003)(59450400001)(86612001)(478600001)(93886005)(14454004)(305945005)(7736002)(10090500001)(7696005)(8936002)(33656002)(110136005)(76176011)(72206003)(68736007)(5660300001)(54906003)(106356001)(316002)(105586002)(966005)(74316002)(22452003)(2900100001)(6436002)(2906002)(5250100002)(8676002)(99286004)(81166006)(8990500004)(52396003)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0311; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-microsoft-antispam-message-info: zYjTBEOwUMyjhUPWjplsmvIumUO6/0i//ip8NYyiIWSvAZY/hoyfc3Bdr3IsPYglzJpg/MwzFctdUeOhvFpMqN4O5EBGG+CGvr1rUHCDFBHMuTaEvyFJss4S0tPCOJR8gDqdbgiQvpaR80vBPJeuh3DutqbqBzxKg9y3TtBmZYZgtsmjXlr5ErVtiCGKOri8
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 1ae77452-aa8d-457a-6f9b-08d5b5e62aec
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ae77452-aa8d-457a-6f9b-08d5b5e62aec
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2018 19:50:50.8695 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0311
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/mBpdiCJ-rPQ9XBnI7Cy2U3zuAdA>
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: Wed, 09 May 2018 19:50:56 -0000

Alexey, you wrote:
> I am tempted to suggest that you should replace it with a single unsigned 16bit, as "major" doesn't mean anything

The two fields are there to facilitate the human convention of having software version numbers have two parts, for example TLS 1.2 and TLS 1.3.  I suppose that explanatory text could be added saying that the two fields are there to align with this human convention for representing version numbers, whereas for machine comparison purposes, the concatenation of the two binary fields represents the version.  Would you be happier with explanatory text along those lines?

FYI, I believe the plan is for the version number of the approved RFC to be 1.0 - that is, a 1 in the major field and a zero in the minor field.  This is pretty normal stuff.

				-- Mike

-----Original Message-----
From: Unbearable <unbearable-bounces@ietf.org> On Behalf Of Andrei Popov
Sent: Wednesday, May 9, 2018 11:19 AM
To: Alexey Melnikov <aamelnikov@fastmail.fm>; The IESG <iesg@ietf.org>
Cc: ve7jtb@ve7jtb.com; draft-ietf-tokbind-negotiation@ietf.org; unbearable@ietf.org; tokbind-chairs@ietf.org
Subject: Re: [Unbearable] Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)

Hi Alexey,

> I urge the WG to think about extensibility now, as opposed to deciding later. Both TLS and HTTP specifications put much more thoughts into versionning.
The Token Binding protocol is extensible in multiple ways:
1. New algorithms can be introduced by defining new TB key parameters; 2. TB protocol supports extensions; 3. TB protocol has a version negotiation mechanism.

> If you don't need generic extensibility (you already have ability to support different private key types), then maybe you don't need the version field at all.
> You can just get a new TLS extension number if you need some incompatible changes.
Both of these options were discussed at length in the WG, over the years, and rejected in favor of the current version negotiation mechanism.
IMHO it would be unfortunate to renegotiate WG consensus at this point in the process.

Thanks,

Andrei

-----Original Message-----
From: Alexey Melnikov <aamelnikov@fastmail.fm>
Sent: Wednesday, May 9, 2018 8:18 AM
To: Andrei Popov <Andrei.Popov@microsoft.com>; The IESG <iesg@ietf.org>
Cc: ve7jtb@ve7jtb.com; draft-ietf-tokbind-negotiation@ietf.org; unbearable@ietf.org; tokbind-chairs@ietf.org
Subject: Re: Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)

Hi Andrei,

On Mon, May 7, 2018, at 8:06 PM, Andrei Popov wrote:
> 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.

I am tempted to suggest that you should replace it with a single unsigned 16bit, as "major" doesn't mean anything

> > 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.

I urge the WG to think about extensibility now, as opposed to deciding later. Both TLS and HTTP specifications put much more thoughts into versionning.

If you don't need generic extensibility (you already have ability to support different private key types), then maybe you don't need the version field at all. You can just get a new TLS extension number if you need some incompatible changes. (Or to ask it in another way: do you just have the version number field to work around strict TLS extension code point allocation rules?)

> > 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.

Yes, this sounds good.

Best Regards,
Alexey

> 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>; 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.i
> etf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7CAndr
> ei.Popov%40microsoft.com%7C59e09351f0fe4b2fb9ac08d5b366524f%7C72f988bf
> 86f141af91ab2d7cd011db47%7C1%7C1%7C636612174409112174&sdata=LDU%2F%2FE
> r7lCYt0gm0yExDVINW1DGJh5S5cJJRv%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%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-tokbind-negotiation%2F&data=02%7C01
> %7CAndrei.Popov%40microsoft.com%7C59e09351f0fe4b2fb9ac08d5b366524f%7C7
> 2f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636612174409112174&sdata=ka1
> kQLpRehbQmXHtxHj73cqfGsRw1Axvk%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.
> 
> 
_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable