Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-protocol-17: (with COMMENT)

Andrei Popov <Andrei.Popov@microsoft.com> Thu, 10 May 2018 03:58 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 4E2EA12E8CA; Wed, 9 May 2018 20:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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, URIBL_BLOCKED=0.001] 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 3OsUx0LFjgtK; Wed, 9 May 2018 20:58:49 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0125.outbound.protection.outlook.com [104.47.36.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D07B12D872; Wed, 9 May 2018 20:58:48 -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=kNSfPW9pi04t69Z1uIWufu5cyr0n2prwWZW/sQMTl+Q=; b=nFW4vwbvZY8C8nMH4OzSpeaKHhmUq2ZNkiJ7AOBPqWra0b44+wqtxZ1Rq1XTmbKhKYSdR3Drv2Su9gNuDeQtGMqY1rs8LvbaMtKh9DbRatItouBn+VCK+txc1G2Xhe00chqJZZ03z7MNvasrEl9KQaQwRWkLhDrgIMxjHojDK6g=
Received: from DM5PR21MB0507.namprd21.prod.outlook.com (10.172.91.141) by DM5PR21MB0826.namprd21.prod.outlook.com (10.173.172.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.4; Thu, 10 May 2018 03:58:47 +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; Thu, 10 May 2018 03:58:46 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Ben Campbell <ben@nostrum.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-tokbind-protocol@ietf.org" <draft-ietf-tokbind-protocol@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>, "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: Ben Campbell's Yes on draft-ietf-tokbind-protocol-17: (with COMMENT)
Thread-Index: AQHT58+mtsrc8RjlJ02eHMcPEl51faQn7/jQgABdTgCAAAjOkA==
Date: Thu, 10 May 2018 03:58:46 +0000
Message-ID: <DM5PR21MB0507F2C83D3F3ABF3D7826148C980@DM5PR21MB0507.namprd21.prod.outlook.com>
References: <152589571183.4023.6683971544993897004.idtracker@ietfa.amsl.com> <DM5PR21MB0507E7960EBFD0D7EBD351048C990@DM5PR21MB0507.namprd21.prod.outlook.com> <4CC4BC4A-C2D6-4535-A30C-52AF2834E64D@nostrum.com>
In-Reply-To: <4CC4BC4A-C2D6-4535-A30C-52AF2834E64D@nostrum.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=andreipo@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-10T03:58:45.9305341Z; 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: [50.47.136.80]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR21MB0826; 7:/h6742hBDKJ/454s2DKQBnn3pOmMLDY9jEjvvujFHfhwQuJXv6p2FbnWqyWAQU3lg2yjSaFKr6nM8vwa2EvqRmPOe4cX3aEza6otLzFmLPMzI6j0ovwbhYjHTO8g5d90j9goQHzzr6PlW4h1pN22BiZDRHFsGEHNWh/7ra1C3qSfsN3kWarKW1aoC3AMqvUC9JgDhk/co/22r8ua5eCPgxY78FiQU9zCK2fRHR2mfXDEvCpaPmiahQ1sjSTGiT9N; 20:Vbb0YSvNrGIuNlB5q/0Ieai8v5Ge6f3s4NP+DSKupb8o9M57H039SyQ5v0fWZtJWkEXLqVBlbSiTkLUwWPdJW96LYGiDFpQ2Zx52hRTL6Q6rosjh0Ce2cpw1OLeamz//H2GdGzFdqSYxim1PSTp8bqp7zCJDn9D6RmQIfeNh9pg=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7193020); SRVR:DM5PR21MB0826;
x-ms-traffictypediagnostic: DM5PR21MB0826:
x-microsoft-antispam-prvs: <DM5PR21MB08265F26999076462F9CEB128C980@DM5PR21MB0826.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(89211679590171)(189930954265078)(219752817060721);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR21MB0826; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0826;
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(376002)(346002)(39860400002)(39380400002)(13464003)(199004)(189003)(4326008)(7736002)(74316002)(81156014)(6116002)(105586002)(5660300001)(8676002)(14454004)(81166006)(3280700002)(3846002)(68736007)(6246003)(8936002)(305945005)(486006)(229853002)(2906002)(97736004)(33656002)(2900100001)(106356001)(3660700001)(6346003)(25786009)(59450400001)(53546011)(102836004)(966005)(26005)(186003)(6436002)(6916009)(22452003)(6506007)(478600001)(99286004)(476003)(7696005)(54906003)(55016002)(66066001)(316002)(10090500001)(11346002)(53936002)(76176011)(86362001)(9686003)(6306002)(10290500003)(575784001)(446003)(5250100002)(86612001)(8990500004)(72206003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0826; 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: tWB8445ThRN2xpyGTtvgKHW/R2SpgSE4n5aXORVZFDZquamoSoU9ZmhtV6R9VOrml2dDPNiM6g5GMoq4EA3Ywhyy1XTbToB0H+E/m5vnyfV+WFqYLsLUQqakQDX6KI382GYrEULF9wLjdCzR8PlWpG/0jSkaO/9lqxnNqriq8tmpb/Pgbab2c2/QSrbXKw6j
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: 33c0f9ce-e739-466d-0934-08d5b62a54c5
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 33c0f9ce-e739-466d-0934-08d5b62a54c5
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 03:58:46.7812 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0826
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/IKi19QJdXOU0bhNZL8K9s1YzbRA>
Subject: Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-protocol-17: (with 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: Thu, 10 May 2018 03:58:52 -0000

Yes, I've made these clarifications in https://tools.ietf.org/html/draft-ietf-tokbind-protocol-18.

-----Original Message-----
From: Ben Campbell <ben@nostrum.com> 
Sent: Wednesday, May 9, 2018 8:25 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: The IESG <iesg@ietf.org>rg>; draft-ietf-tokbind-protocol@ietf.org; John Bradley <ve7jtb@ve7jtb.com>om>; tokbind-chairs@ietf.org; unbearable@ietf.org
Subject: Re: Ben Campbell's Yes on draft-ietf-tokbind-protocol-17: (with COMMENT)



> On May 9, 2018, at 5:16 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> 
>> §1.1: Please consider using the boilerplate from 8174 across this cluster.
> Will do.
> 
>> §3.1: This section does not seem to sufficiently define the difference between provided_token_binding and referred_token_binding, other than as a mention of the use case from the HTTPS doc. It would be nice if other application protocol bindings did not have to refer to the HTTPS doc to fully understand the basic protocol.
> Section 3.1 introduces the TB types, but Sections 4.1 and 4.2 have specific processing requirements, from the perspective of the basic protocol. The use of referred Token Binding requires interaction with an application protocol, and HTTPS is one such protocol, therefore the reference seems appropriate.

I don’t object to the reference existing, but this draft is the one describing protocol semantics, so I think some more description in the draft itself would be reasonable. This is, of course, not a blocking comment.

> 
>> §3.2, last paragraph: Why is this a SHOULD?
> From the perspective of being able to change the internal representation of the Token Binding IDs in the future, it would be best if applications did not rely on a particular TB ID structure.
> One way to achieve this is to treat TB IDs as opaque byte sequences. There are other ways, and different representations make sense for different APIs, therefore it's not a MUST.

It would be helpful to say that in the text.

> 
>> §3.3, last bullet: Is the EKM from the TLS connection at the time the binding is established (rather than when it might later be used)?
> It's the EKM from the current TLS connection where Token Binding is being established.

Please consider clarifying that in the text.

> 
>> §4.1, 2nd paragraph: Why only a SHOULD? It seems like intentionally storing keys in an insecure manner makes the entire protocol pointless.
> I do not mind saying MUST, but the degree to which TB keys can be protected depends on the client device capabilities.

I do not suggest the MUST describe a particular method of protection. But the SHOULD could possibly interpreted to allow implementations to have no protection at all in some cases.


> 
>> §6.1 (and others): I'm not sure what it means for the expert to be "advised to encourage". Is there something more concrete that could be said? Does this give the advisor grounds to reject a registration?
> We could say "...expert will require the inclusion of a reference to a permanent and readily available specification…"

That is better, assuming it was the working group intent.

> 
>> §1: Please expand TPM on first mention.
> Will do.
> 
> Thanks,
> 
> Andrei
> 
> -----Original Message-----
> From: Ben Campbell <ben@nostrum.com>
> Sent: Wednesday, May 9, 2018 12:55 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-tokbind-protocol@ietf.org; John Bradley <ve7jtb@ve7jtb.com>om>; tokbind-chairs@ietf.org; ve7jtb@ve7jtb.com; unbearable@ietf.org
> Subject: Ben Campbell's Yes on draft-ietf-tokbind-protocol-17: (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-tokbind-protocol-17: Yes
> 
> 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%7Cbef59ff1c14f45d3294108d5b5e6c79a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636614925167967005&sdata=dlNij3YGOsg2g%2Br2hg4kCy2jyGYjZglxTJMhHfABd%2Fo%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-protocol%2F&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cbef59ff1c14f45d3294108d5b5e6c79a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636614925167967005&sdata=gmXDfLO1%2B9%2F%2BE6BIdqNUn1OsaSGVBPCSrOXu0bpVQnw%3D&reserved=0
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for this document. I am balloting "yes", but I have a few minor comments:
> 
> Minor Comments:
> 
> §1.1: Please consider using the boilerplate from 8174 across this cluster.
> There are a few instances of lower case keywords across the set.
> 
> §3.1: This section does not seem to sufficiently define the difference between provided_token_binding and referred_token_binding, other than as a mention of the use case from the HTTPS doc. It would be nice if other application protocol bindings did not have to refer to the HTTPS doc to fully understand the basic protocol. (Or is it assumed that only HTTPS will use referred_token_binding)?
> 
> §3.2, last paragraph: Why is this a SHOULD? Do you envision scenarios where it would make sense to behave differently? For example, if an application made Token Binding IDs available as structured data, what would be the consequences?
> 
> §3.3, last bullet: Is the EKM from the TLS connection at the time the binding is established (rather than when it might later be used)?
> 
> §4.1, 2nd paragraph: Why only a SHOULD? It seems like intentionally storing keys in an insecure manner makes the entire protocol pointless.
> 
> §6.1 (and others): I'm not sure what it means for the expert to be "advised to encourage". Is there something more concrete that could be said? Does this give the advisor grounds to reject a registration?
> 
> Editorial Comments:
> 
> §1: Please expand TPM on first mention.
> 
>