From nobody Fri Jun 1 07:32:44 2018 Return-Path: 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 4CBB212D887 for ; Fri, 1 Jun 2018 07:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.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 ytW4lRycUP3Q for ; Fri, 1 Jun 2018 07:32:40 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D4512D883 for ; Fri, 1 Jun 2018 07:32:39 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id r2-v6so15135973lff.4 for ; Fri, 01 Jun 2018 07:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=i8UNxzoOidCGw4OSztaITefuRcqLzCM4qcj5v0uMBA4=; b=Qzhj66t513f+b4MjIusUQcnnk9e0IA8cSHsn6vMWFXIxN2yZk7RRqnW/d8qfKA+AzU pqT9L3bly/kxXhG1U18dCn6zqX1bai1ITeE8Oa1NX6smr5WyvU8m0XNFugacppicnQJn HXbnmhN87g48tKgwBBNQFRDDdaN5RwO9l3DkXCQsjSCuzMRVkquLXw6N6WpRFFF5mMNP TevOURt5Q16kBATUYwUC5pk0R/YhKpyYZGW4Cmd91y2x+iT/4px5EiIQ+6MYDfvslwsN FvC6mpyacwjOz/Ux8PqESQAvML8isGlu+04TvjLSiYafJbXlqyXNv5lyvY5AzokNBw1j uB5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=i8UNxzoOidCGw4OSztaITefuRcqLzCM4qcj5v0uMBA4=; b=uMdfnewq6K51EkJ7rKz7XD/r1WEkKfmjZJdjw43I05SXYLXlReJpE6HRBstZzYwSnb GxdZqdPtz/rTwRyb04zMf3eZXpt/wAoiz2mjnuT8HADir5X2HrobkDhcANPt6JJMC8op dmbt5rdiaRp21CLsRZT77A2e2urOKNqFjJCiUIWi9T8W9ib4G+sKfEQMLGeGqIo189V7 hO0WjvftNlzYCKtW6aj6i4NnXilZVXy7DA2JVzRklm1CB5zxFeiNRqvXK5KabPeelhG7 2GHhpjK/oaMbRCnfkHcfp2exLb/itS8q7BjYZhP38o3iWuxbE+gpgLL5V4Zj69EoAXdr oOBQ== X-Gm-Message-State: ALKqPwd+KYKRf1K8Br6cVnLN7HyxN9H5xGURVleJBNW1RSt86LrqpCwC 92n7O+glAIz02ImGRI2ic7Zh3lS1GLI= X-Google-Smtp-Source: ADUXVKIxrW2b2VrBpODFLX88BpXcAcCtuDLdkLEOev4Z+qAG1UfOF7hFbKnhOm1F9evfVae2ZgUTGg== X-Received: by 2002:a19:5c94:: with SMTP id u20-v6mr6321378lfi.138.1527863557644; Fri, 01 Jun 2018 07:32:37 -0700 (PDT) Received: from ?IPv6:2001:6b0:7:1:4816:4623:1621:eae6? ([2001:6b0:7:1:4816:4623:1621:eae6]) by smtp.gmail.com with ESMTPSA id a67-v6sm815523lfa.48.2018.06.01.07.32.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 07:32:35 -0700 (PDT) To: Brian Campbell Cc: IETF Tokbind WG References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> From: Leif Johansson Openpgp: preference=signencrypt Autocrypt: addr=leifj@mnt.se; prefer-encrypt=mutual; keydata= xsDiBD7DfnwRBADpIpOw6bXfx2Yo3vac/j5WzVcWNZKuiYc4uuFnBYxH8zTA5cdwytuOYNte cX1yrPgmObfPVU0EFktdBMFgLE5TNRUMeJZTmAl3QYDm8N32SeSUEb6GPFsUTGgxsCW3GVAo q6DBopKqhR9HT0+crQakbc7XkS4FjeBWiXjuNf/IqwCgyoa2Qfq8UdjbcH+DRGzPnRTeqzEE ALIEsCzDp4HQqXqqNLCoExbgmCrEHvnqFmilCHJVnyuY8LXmcpq2uwJaiIdsTqLeQ8WrMxWg mZc6F9QSdLP6MVZT3v+5OqOZMUDsu4nGom3HH+tG238vMSEF+klGdrI0wdscrY+28Oshjhqj 4FZxCwdNU9RTU8xQ9IoObiEo1yOHBADK9a5GhkLT+d2cb48orETGtG7i//HOnstouw/TmEUX reZPtT6wpIdN9Jf3W80GA6A34VEGA/I+/5e+9nFvINpLvEF2ghJBH+sWwQ8EXpo0M/yir9oG eJI7gpOHRj5Mq9uqFG0wcamInuWgbMP1cefjXusHbHyDFKr7ydWSsZHqXs0gTGVpZiBKb2hh bnNzb24gPGxlaWZqQG5vcmR1Lm5ldD7CYAQTEQIAIAUCSnC85QIbIwYLCQgHAwIEFQIIAwQW AgMBAh4BAheAAAoJEPCcfBbWzGZ3J1YAnAiLOGwjJvm08O0aQEwlq9jExHJ/AKDDmnmS6Gxo YOQCdWa87weOd+5sk87BTQQ+w36FEAgAr1zK1qIIXmoeEqFulgFi17FRpSibNwwge9bkG2+I O7MOm4Ih+f4CRkqaP5U5diiWb4nyQc/Yqzf3TTSE+CH0ghvDCwfZHrzUsVl9t57S2RFKaQhD UUw3lz0TgKN66z1IRnQEARuz9PFd96pIhLaJBOn0e55Cu5qqJVwGpst3+I3jqT/cxjymRxPz 2O6R9k/ZOOiOGROZYAjNHKcdoeBr7OaIHcPRCi1R8MBKE4HOK1SwaVvs26Fd2enixIOBmyFT krue3VgaAd3zrJauD0qa/u5y2kGEyFFJwNsKnoX0aCmNNIG+aKvnSCWfba8bmYOAsbxS2lo4 MKmuDM0rrVyLhwADBQf/VzM77aviZ3Ir7qXj0uV/62wyrg8/5flXl8XjuATewD+hTaux1lg5 LgPU9cokMHYHrTsnp79nhEB9qOpsQLX+npae7a27x3zyqLP0V7neyKy1ycuBI9KU9B3ivgSM RlKR91GcmUpRnKiSnxPYNtq018mY72YYHCpfAh0OOUA88bxbYIuF5cv9dYyOBhNEkI8xB1VO Wev1CPkPb0DwDABHdOBq9e0hT3OUOaat2JPwCEHU2NTGsYFuZRysq8xnxFgHd00+h2OJZ50U YVpBjDxaCj5gvHHFFnmfCLD5VqjEJGi4k2znZHg67i2pw0f5BSq8fsfdUML35LzL/aaZPMzl g8JGBBgRAgAGBQI+w36FAAoJEPCcfBbWzGZ3djcAnAxF3084vKlsRNGcyj/rn5lA4Q+nAKCn jZYXsnFG51wbu8OI88aj3LJE5w== Message-ID: Date: Fri, 1 Jun 2018 16:32:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 14:32:42 -0000 On 2018-06-01 00:49, Brian Campbell wrote: > I'd like to request some agenda time to cover the TTRP draft, which will > likely consist of an overview and status update (with some gratuitous > photos of recent IETF meeting locations) and a plea to move towards > WGLC. Thanks! In order to facilitate that... could we get some folks to review the TTRP draft before 102? Maybe... please... ?? Cheers Leif From nobody Fri Jun 1 09:07:07 2018 Return-Path: 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 1979612D960 for ; Fri, 1 Jun 2018 09:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 4LUB-_Opb1-k for ; Fri, 1 Jun 2018 09:07:04 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50BE312D95D for ; Fri, 1 Jun 2018 09:07:04 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id c3-v6so2423076itj.4 for ; Fri, 01 Jun 2018 09:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FAZmkIK/5Kp3tlqIfnfpp7DLPvzpFEwEJUYB5AWk5ls=; b=DsOrdUDIj6uP3g1wt4XeLDVepLT/DfFtNrDdcyvz1a3UInnja2JVLV6WTEcH+IYPaU JF0EJcff7Ha+O0GreOBF/u6yZ3AGbKqcgnkXnuSbYxxKmrF8KYrm/B826guXmcOuYA1Z EGPFad9IFeBaxYOJTs91HwMoZ44sDDutF2Tic= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FAZmkIK/5Kp3tlqIfnfpp7DLPvzpFEwEJUYB5AWk5ls=; b=VmBP1YUEvj5WMopmDcvgXLqg+7Mc/30/654rhdTC9TD7TgAISeXa/QwHY52vD/QAh4 MU7i1wxlapM+NlrhFrNduiobywYw7KjwXXE2bKP0xnX70hS9FZMIORIETZBaxhS2G+ZB ulo2mY4Vs6vtUBqv+iYVWLssWd1Xe03c4N8+dvgLS0yJ8UdTN14NGuqoFOcuSxD9gEF6 c0e6xss6ksXWtPEyUQKRh/ffqNXMTMyovoOOg+m8BAdVvhwOqx9x7Dlv5r6CU2ZlwnzC bh13V2Lvx7RTRkMUl5C/cEs31TMFQMbU/IVgnlfYMv5lUUMRRT4AAAsdZZhpqa6S8y4M YbXg== X-Gm-Message-State: APt69E3WKH2PbXuChlDNgGUnES7anYZ7+LKpsrIQUAVCqLN0J1La0NDY QI7ytjlYubPbY8F7r76T5kTvF3CWBGiQxaY5MJbRONRNgd+7AUgXDiqBGSR//L0QFwBoQ6YrAp/ 71L38ZM6Mnra5GDTiUuIf X-Google-Smtp-Source: ADUXVKKsgA5hOiKwVXGjun5MSKu+PWMLxipniTF4Y5nAUKeW2/hAEmpSab6YpdvJ51EEHMMS0tLZdSfmyIrQ3LsV0Zw= X-Received: by 2002:a24:641:: with SMTP id 62-v6mr4593052itv.89.1527869223528; Fri, 01 Jun 2018 09:07:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 09:06:32 -0700 (PDT) In-Reply-To: References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> From: Brian Campbell Date: Fri, 1 Jun 2018 10:06:32 -0600 Message-ID: To: Leif Johansson Cc: IETF Tokbind WG Content-Type: multipart/alternative; boundary="000000000000550bf6056d96c6dc" Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 16:07:06 -0000 --000000000000550bf6056d96c6dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's pretty short! https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-03 On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson wrote: > > > On 2018-06-01 00:49, Brian Campbell wrote: > > I'd like to request some agenda time to cover the TTRP draft, which wil= l > > likely consist of an overview and status update (with some gratuitous > > photos of recent IETF meeting locations) and a plea to move towards > > WGLC. Thanks! > > In order to facilitate that... could we get some folks to review > the TTRP draft before 102? > > Maybe... please... ?? > > Cheers Leif > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000550bf6056d96c6dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson <leifj@mnt.se= > wrote:
<= br>
On 2018-06-01 00:49, Brian Campbell wrote:
> I'd like to request some agenda time to cover the TTRP draft, whic= h will
> likely consist of an=C2=A0overview and status update (with some gratui= tous
> photos of recent IETF meeting locations) and a plea to move towards > WGLC. Thanks!

In order to facilitate that... could we get some folks to review
the TTRP draft before 102?

Maybe... please... ??

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000550bf6056d96c6dc-- From nobody Fri Jun 1 10:20:11 2018 Return-Path: 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 EB63212D96D for ; Fri, 1 Jun 2018 10:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 6WWJgK8ZCCYv for ; Fri, 1 Jun 2018 10:20:06 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0115.outbound.protection.outlook.com [104.47.40.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C9012D962 for ; Fri, 1 Jun 2018 10:20:05 -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:X-MS-Exchange-SenderADCheck; bh=ZzOp4zhfcJE3ZkIKZ/vXltv6a2q0EdrpRonpi8ILPvw=; b=du/wfSfv5spffhMjFhJPnrBS/p+AcLPu7//UDdglfSKVQJ951AtWD8LmSKAEC6BfnuxTOturVMWAUr59OAuHVBe10xJcvj307kFlRoyYugBMDPF+zsUA2vSsvcLPuqAPzPEcEetHUpzIZw/B9MWHkjpaWHo7vQnFSW7z5Nj/NOg= Received: from DM5PR21MB0507.namprd21.prod.outlook.com (10.172.91.141) by DM5PR21MB0170.namprd21.prod.outlook.com (10.173.173.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.7; Fri, 1 Jun 2018 17:20:04 +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.0841.006; Fri, 1 Jun 2018 17:20:04 +0000 From: Andrei Popov To: Brian Campbell , Leif Johansson CC: IETF Tokbind WG Thread-Topic: [Unbearable] tokbind - New Meeting Session Request for IETF 102 Thread-Index: AQHT+KcSOfkm5RG+C024j4aQmtNOyqRJXiAAgAETswCAAQehAIAAGkEAgAAUUOA= Date: Fri, 1 Jun 2018 17:20:04 +0000 Message-ID: References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a:28b3:a023:971b:e42c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0170; 7:wlb2igzApe2rNjLYLl5Qz+/X+uxRBe3PXQxD1yj+prWrHsbzCVju6FhL6EUP4KxwPuK3d0Kf39mJWnEtYHtitKC5V+coiRRTvGyEelZfJ2t+YtpPyOwYnO9Np0JKxp8rliC0J4JPq2qsncRd9AHKeuZ9XXU07KbucNMQx84eAco9YeoVHAEugdKgtb9cQH70QW+BBpT6mhqny4YJn6hkOP8rEdXftwK0TYd532l0OiVM9Du/PEdsWjYz6OWG5gAz; 20:z5B/lDqlXRI7RoJCcpm7XU0/LDrrS5WIIpMEXaKG9hRfQtWPlL883dj+2+jMEhYuOjYZ/7LZWh7NtlVl3I+PDlJSbP9wOtY9zLCmok1OZxj/ICVAwWJ0GAF/lWzvZfb3zPdwRdgFR+qRcl1Sk6DqQjx5DByAdsDoKv63ENttuC8= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR21MB0170; x-ms-traffictypediagnostic: DM5PR21MB0170: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(189930954265078)(219752817060721)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(2018427008)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DM5PR21MB0170; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0170; x-forefront-prvs: 0690E5FF22 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(396003)(346002)(366004)(39860400002)(199004)(189003)(105586002)(86362001)(110136005)(476003)(72206003)(46003)(1600100001)(6116002)(33656002)(790700001)(316002)(446003)(11346002)(99286004)(86612001)(486006)(55016002)(74316002)(7696005)(6246003)(68736007)(478600001)(102836004)(106356001)(6506007)(53546011)(229853002)(19609705001)(2900100001)(10290500003)(59450400001)(186003)(76176011)(966005)(14454004)(3660700001)(4326008)(25786009)(8676002)(7736002)(10090500001)(5660300001)(53936002)(8936002)(9686003)(236005)(6306002)(54896002)(8990500004)(2906002)(5250100002)(22452003)(93886005)(5890100001)(3280700002)(97736004)(6436002)(606006)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0170; 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) x-microsoft-antispam-message-info: /4WY5hZUY6/OOBGubpLPs6YD02vqETl6zwbSbf/1fSKf5bjuoxYR0z9HWQlULwlzYMX58aIAwY78i1+a1omYcy5QSt1eUheLpZpItZQWqV+afdalu+29pBzNNkt7ynnsnNiHRrFlY6avT76fo9Sk1HBpDZrvV1MaM/0ITY1+FVqFGjwifJcqeEF1Varw190B spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR21MB0507FBE94735074A2FEDE3AC8C620DM5PR21MB0507namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: edb025e2-8c3e-481b-caea-08d5c7e3ea29 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: edb025e2-8c3e-481b-caea-08d5c7e3ea29 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2018 17:20:04.1463 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0170 Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 17:20:09 -0000 --_000_DM5PR21MB0507FBE94735074A2FEDE3AC8C620DM5PR21MB0507namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWxsIHJldmlldywNCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogVW5iZWFyYWJsZSA8 dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwN ClNlbnQ6IEZyaWRheSwgSnVuZSAxLCAyMDE4IDk6MDcgQU0NClRvOiBMZWlmIEpvaGFuc3NvbiA8 bGVpZmpAbW50LnNlPg0KQ2M6IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gdG9rYmluZCAtIE5ldyBNZWV0aW5nIFNlc3Npb24g UmVxdWVzdCBmb3IgSUVURiAxMDINCg0KSXQncyBwcmV0dHkgc2hvcnQhIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtdHRycC0wMzxodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmll dGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtdG9rYmluZC10dHJwLTAzJmRhdGE9MDIlN0MwMSU3 Q0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN0NiZTliNDVlNTk0MjI0MTMzMGQwOTA4ZDVj N2Q5YmJkMiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2 MzQ2NjAzMzQxMjM0NDkmc2RhdGE9bWZsNERSZUM4NDZPb1FTZHlKdlhRMFVqTVlZOXplVDhIbnAy amJYdmlpcyUzRCZyZXNlcnZlZD0wPg0KDQpPbiBGcmksIEp1biAxLCAyMDE4IGF0IDg6MzIgQU0s IExlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U8bWFpbHRvOmxlaWZqQG1udC5zZT4+IHdyb3Rl Og0KDQoNCk9uIDIwMTgtMDYtMDEgMDA6NDksIEJyaWFuIENhbXBiZWxsIHdyb3RlOg0KPiBJJ2Qg bGlrZSB0byByZXF1ZXN0IHNvbWUgYWdlbmRhIHRpbWUgdG8gY292ZXIgdGhlIFRUUlAgZHJhZnQs IHdoaWNoIHdpbGwNCj4gbGlrZWx5IGNvbnNpc3Qgb2YgYW4gb3ZlcnZpZXcgYW5kIHN0YXR1cyB1 cGRhdGUgKHdpdGggc29tZSBncmF0dWl0b3VzDQo+IHBob3RvcyBvZiByZWNlbnQgSUVURiBtZWV0 aW5nIGxvY2F0aW9ucykgYW5kIGEgcGxlYSB0byBtb3ZlIHRvd2FyZHMNCj4gV0dMQy4gVGhhbmtz IQ0KDQpJbiBvcmRlciB0byBmYWNpbGl0YXRlIHRoYXQuLi4gY291bGQgd2UgZ2V0IHNvbWUgZm9s a3MgdG8gcmV2aWV3DQp0aGUgVFRSUCBkcmFmdCBiZWZvcmUgMTAyPw0KDQpNYXliZS4uLiBwbGVh c2UuLi4gPz8NCg0KICAgICAgICBDaGVlcnMgTGVpZg0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55 IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp b24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1h aWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo= --_000_DM5PR21MB0507FBE94735074A2FEDE3AC8C620DM5PR21MB0507namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTotYXBwbGUtc3lzdGVtO30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmWxsIHJldmlldyw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bmRyZWk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFVuYmVhcmFibGUgJmx0 O3VuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mDQo8L2I+QnJp YW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDEsIDIwMTggOTowNyBB TTxicj4NCjxiPlRvOjwvYj4gTGVpZiBKb2hhbnNzb24gJmx0O2xlaWZqQG1udC5zZSZndDs8YnI+ DQo8Yj5DYzo8L2I+IElFVEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSB0b2tiaW5kIC0gTmV3IE1lZXRp bmcgU2Vzc2lvbiBSZXF1ZXN0IGZvciBJRVRGIDEwMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkl0J3MgcHJldHR5IHNob3J0ISA8YSBocmVmPSJodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmll dGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtdG9rYmluZC10dHJwLTAzJmFtcDtkYXRhPTAyJTdD MDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdDYmU5YjQ1ZTU5NDIyNDEzMzBkMDkw OGQ1YzdkOWJiZDIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM2NjM0NjYwMzM0MTIzNDQ5JmFtcDtzZGF0YT1tZmw0RFJlQzg0Nk9vUVNkeUp2WFEwVWpNWVk5 emVUOEhucDJqYlh2aWlzJTNEJmFtcDtyZXNlcnZlZD0wIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtdHRycC0wMzwvYT4gPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVuIDEsIDIwMTgg YXQgODozMiBBTSwgTGVpZiBKb2hhbnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsZWlmakBtbnQu c2UiIHRhcmdldD0iX2JsYW5rIj5sZWlmakBtbnQuc2U8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiAy MDE4LTA2LTAxIDAwOjQ5LCBCcmlhbiBDYW1wYmVsbCB3cm90ZTo8YnI+DQomZ3Q7IEknZCBsaWtl IHRvIHJlcXVlc3Qgc29tZSBhZ2VuZGEgdGltZSB0byBjb3ZlciB0aGUgVFRSUCBkcmFmdCwgd2hp Y2ggd2lsbDxicj4NCiZndDsgbGlrZWx5IGNvbnNpc3Qgb2YgYW4mbmJzcDtvdmVydmlldyBhbmQg c3RhdHVzIHVwZGF0ZSAod2l0aCBzb21lIGdyYXR1aXRvdXM8YnI+DQomZ3Q7IHBob3RvcyBvZiBy ZWNlbnQgSUVURiBtZWV0aW5nIGxvY2F0aW9ucykgYW5kIGEgcGxlYSB0byBtb3ZlIHRvd2FyZHM8 YnI+DQomZ3Q7IFdHTEMuIFRoYW5rcyE8YnI+DQo8YnI+DQpJbiBvcmRlciB0byBmYWNpbGl0YXRl IHRoYXQuLi4gY291bGQgd2UgZ2V0IHNvbWUgZm9sa3MgdG8gcmV2aWV3PGJyPg0KdGhlIFRUUlAg ZHJhZnQgYmVmb3JlIDEwMj88YnI+DQo8YnI+DQpNYXliZS4uLiBwbGVhc2UuLi4gPz88YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2hlZXJzIExlaWY8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Oi1hcHBsZS1zeXN0ZW07Y29s b3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05G SURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBh bmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQocykuIEFueSByZXZpZXcsDQogdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3Vy ZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkg ZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9p PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR21MB0507FBE94735074A2FEDE3AC8C620DM5PR21MB0507namp_-- From nobody Sun Jun 3 21:21:29 2018 Return-Path: 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 1A07E12025C for ; Sun, 3 Jun 2018 21:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.236 X-Spam-Level: X-Spam-Status: No, score=0.236 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 oTeEdLH7KGh1 for ; Sun, 3 Jun 2018 21:21:25 -0700 (PDT) Received: from m69-169.mailgun.net (m69-169.mailgun.net [166.78.69.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581251200F1 for ; Sun, 3 Jun 2018 21:21:25 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1528086084; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=sSjd8A0c1ME3JRGnr+yDyl0RAQQ0rWSkCz1unIprpMs=; b=G9rQiApwVm3XQIvKGNmVMi2bAv34ABpVW77JkXnhUL2VIqmyvgKxClfzKgB41ho/HJZP6d2Q PxWmZ2s86uTsXCPtKKAAzIsUAP48XbM4Bu0QyCcVFvIEIaIKYzFnKqEPn6jTddlkcSdrv573 dKLgdZTw/1w+CCw+YsAxPwt5wOs= X-Mailgun-Sending-Ip: 166.78.69.169 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Sender: dirk=balfanz.net@github.com Received: from github.com (Unknown [192.30.252.34]) by mxa.mailgun.org with ESMTP id 5b14be43.7fcab8d35840-smtp-out-n01; Mon, 04 Jun 2018 04:21:23 -0000 (UTC) Date: Sun, 03 Jun 2018 21:21:23 -0700 From: Dirk Balfanz Reply-To: Dirk Balfanz To: unbearable@ietf.org Message-ID: <5b14be43a4cea_7e1a2adf0185dbfc3732e@hookshot-fe-7191cb1.cp1-iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_5b14be43a46bd_7e1a2adf0185dbfc37295"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 318b2f: clarified section 6. 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 04:21:27 -0000 ----==_mimepart_5b14be43a46bd_7e1a2adf0185dbfc37295 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 318b2f0182b8b1ee0cec12049e5899805c6cbd3d https://github.com/TokenBinding/Internet-Drafts/commit/318b2f0182b8b1ee0cec12049e5899805c6cbd3d Author: Dirk Balfanz Date: 2018-06-03 (Sun, 03 Jun 2018) Changed paths: M draft-ietf-tokbind-https-16.xml Log Message: ----------- clarified section 6. **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019. ----==_mimepart_5b14be43a46bd_7e1a2adf0185dbfc37295-- From nobody Sun Jun 3 21:28:21 2018 Return-Path: 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 61F4E120227; Sun, 3 Jun 2018 21:28:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152808649334.20772.13130504133879770877@ietfa.amsl.com> Date: Sun, 03 Jun 2018 21:28:13 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-16.txt 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 04:28:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : Token Binding over HTTP Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Nick Harper Jeff Hodges Filename : draft-ietf-tokbind-https-16.txt Pages : 25 Date : 2018-06-03 Abstract: This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections. We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token. This document is a companion document to The Token Binding Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-https-16 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 3 21:33:08 2018 Return-Path: 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 0BB1C120227 for ; Sun, 3 Jun 2018 21:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 VneL7J1VPCHQ for ; Sun, 3 Jun 2018 21:33:05 -0700 (PDT) Received: from m71-131.mailgun.net (m71-131.mailgun.net [166.78.71.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D351200F1 for ; Sun, 3 Jun 2018 21:33:05 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1528086784; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=4pKtmcBYvtSxPeQiX+Gy2GaHjTqMcBO021IpzPduAhc=; b=avYWTCtSdU0eRMLydubf4VFdd6QHMaqWNycS2qIzw6zztZ8wTgIEmMCMI6vvpv7TeaUU3sbE geZhuvw/dJH1pCIM7A9sv7gA0ANnfyUpO5XvEud8gLeeH/lQLFD+orc2EhHzkEW5wVF3rZV1 ALksUwoH8TIBs7Ppd43CKaLtteY= X-Mailgun-Sending-Ip: 166.78.71.131 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Sender: dirk=balfanz.net@github.com Received: from github.com (Unknown [192.30.252.40]) by mxa.mailgun.org with ESMTP id 5b14bea8.7fd089334480-smtp-out-n02; Mon, 04 Jun 2018 04:23:04 -0000 (UTC) Date: Sun, 03 Jun 2018 21:23:04 -0700 From: Dirk Balfanz Reply-To: Dirk Balfanz To: unbearable@ietf.org Message-ID: <5b14bea81e8a0_d1f2ae94a833c004954d@hookshot-fe-d2afb11.cp1-iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_5b14bea81e2b6_d1f2ae94a833c00494f2"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 3c05ac: Capitalization 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 04:33:07 -0000 ----==_mimepart_5b14bea81e2b6_d1f2ae94a833c00494f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 3c05ace8c53cfcc4f466115c3d2694e5a4d111e5 https://github.com/TokenBinding/Internet-Drafts/commit/3c05ace8c53cfcc4f466115c3d2694e5a4d111e5 Author: Dirk Balfanz Date: 2018-06-03 (Sun, 03 Jun 2018) Changed paths: M draft-ietf-tokbind-https-16.xml Log Message: ----------- Capitalization **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019. ----==_mimepart_5b14bea81e2b6_d1f2ae94a833c00494f2-- From nobody Mon Jun 4 13:27:19 2018 Return-Path: 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 4CE11130DE6 for ; Mon, 4 Jun 2018 13:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 WLNT9VgiLQ9F for ; Mon, 4 Jun 2018 13:27:10 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF51D130DC0 for ; Mon, 4 Jun 2018 13:27:05 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id w7-v6so33576902wrn.6 for ; Mon, 04 Jun 2018 13:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zdO3RtFASYHyQ7Q+HSD7IGZQlUAPjkkd7RorJfSGULE=; b=JLCpy1sHdF0MQ2Nury2sVW2gENI6b2qXW844YJ4AvJRWY2RukbB7NVu4vhb9oItADL pJwdMvAfV1B2OG2oqjafMu2232v397xKXQ4ST5E+J8Wnz77OZC6h2SMwI/3GQVj3/lTc Jl3ZFHLF4U3cIJNjcgEqrN3CouLXRpUfJnh6euUjr0paXjH7nYHaGmBWupNA6vwf7hzH +PQft6ydTvGbbKlwXCHbDRHfrYiWcIJHI3VEvqbZu2BevB+klgTYzpVJy59+pvQ2UhPK Y0Q+yh4ThIHbiRBkOfqBgBwovap5/O70davCDT/yfAOcYe8k1ur26RBQsXPe25DJGQRS Lk+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zdO3RtFASYHyQ7Q+HSD7IGZQlUAPjkkd7RorJfSGULE=; b=ANwSbx2sikzYYU3U+q8Xes82hgqLcDuF8y4ON5Kj9l17AHYLqMNLqaOLP4Bj6rRKEY zCs5Rzt3KnKYpAuWl+chwWCEDTrlYSqm2DzN6VcQy2UAr19MARvWs+PYmkaPArP5CeiD tr5AkUVp1hvMiTbdPBDRWGiyr9KkRatJgW9hE3zkXTFOTmAYQxZ2H6UclqbanU4AHX73 0FX6AjzP+vd3CSa0fR3XFNu3SOlygPbbeyH47M2zWCayxlcUM90Ullh7i5N8ORbujUDB N+R9OBu0sEmT3khiSIaTf3ArfaYCFpCvobgVjCPhhNTztc2KV8qKMh8ji5fThCsICnx1 //iA== X-Gm-Message-State: ALKqPwdZdutYENilOMmYiYyn6WoaPsTQm5u17vhu1shqRd2A/oKpQcnY FKPie4TVwBQ2CYTlBWpQ7/6nu8bEv9SqD1mxJ2CgxA== X-Google-Smtp-Source: ADUXVKK+0mVsVr2FSPTD1yKIEuM/gyrALzIk/3wue7dUCtZHh++BGosDuUH2YNiu5lFceJ8Kjes0AZfezxWETh/BIzM= X-Received: by 2002:adf:8e30:: with SMTP id n45-v6mr16316821wrb.27.1528144023518; Mon, 04 Jun 2018 13:27:03 -0700 (PDT) MIME-Version: 1.0 References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> In-Reply-To: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> From: Dirk Balfanz Date: Mon, 4 Jun 2018 13:26:51 -0700 Message-ID: To: ben@nostrum.com Cc: The IESG , draft-ietf-tokbind-https@ietf.org, John Bradley , tokbind-chairs@ietf.org, Tokbind WG Content-Type: multipart/alternative; boundary="000000000000b08927056dd6c161" Archived-At: Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 20:27:13 -0000 --000000000000b08927056dd6c161 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, thanks for the feedback. Most of it is addressed in the new draft ( https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below (inline) for details. On Wed, May 9, 2018 at 1:38 PM Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-tokbind-https-14: 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: > https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I plan to ballot "YES", but I want to clear up once concern first: > > After reading section 6 several times, I don't know what it means. I thin= k > it's [...] > Addressed in new draft. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive Comments: > > =C2=A71.1: Please consider using the boilerplate from 8174 across the clu= ster. > Both > this and the protocol draft have lower case keyword instances. > Addressed in new draft. > > =C2=A78.2: > - Does it really make sense to wait for a user to request the keys be > expired? > I suspect the average user does this about never. Did the working group > discuss > possibly making the keys default to expiring after some period of time? Yes, we did discuss it. This was chosen consciously to be in sync with cookies and their expirations / manual user-initiated purges. - Why > is the SHOULD in paragraph 2 not a MUST? > Addressed in new draft. > > Editorial Comments: > > =C2=A72: > - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in > [RFC7230] > style, see also Section 8.3 of [RFC7231]):" The open parenthesis before > "in" > seems misplaced. Also, as written the comma after "style" creates a comma > splice. (Note that this pattern occurs elsewhere in the document.) > > - Paragraph 3: The paragraph is a single hard-to-parse sentence. Please > consider breaking into simpler sentences. > Addressed in new draft. > > - example: Am I correct to assume the backslashes are just for print > purposes > and are not in the actual message? If so, please mention that. > Addressed in new draft. > > =C2=A7 2.1: > - first paragraph, "Within the latter context...": There was no former > context. > I suggest "Within that context..." Addressed in new draft. > - 2nd paragraph: The first sentence is hard > to parse. I suggest breaking it into separate paragraphs, or restructure > without the center-imbedding. Addressed in new draft. > - 2nd to last paragraph: Does "SHOULD generally" > mean the same as just "SHOULD"? > Addressed in new draft. > > =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to another serve= r..." > Addressed in new draft. > > =C2=A75.2, > - last bullet: " (between client and Token Consumer)" seems more than > parenthetical. Please consider removing the parentheses. Addressed in new draft. > - paragraph after last > bullet: The parenthetical phrase starting with "(proving possession...) i= s > quite long and makes the sentence hard to parse. Given that the concept i= s > covered in the immediately preceding paragraph, can it be removed? > Addressed in new draft. > > =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or restat= e > requirements > in) the protocol and negotiation drafts. Can they be included by referenc= e > instead, or at least attributed? > Addressed in new draft. > > =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77.1. > Addressed in new draft. > =C2=A78.3: Unneeded comma in first sentence. > Addressed in new draft. Thanks again for the thoughtful comments! Dirk. --000000000000b08927056dd6c161 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,=C2=A0

thanks for the feedback. = Most of it is addressed in the new draft (https://tools.ietf.org= /html/draft-ietf-tokbind-https-16). See below (inline) for details.
=
On Wed, May 9, 2018 at 1:38= PM Ben Campbell <b= en@nostrum.com> wrote:
Ben Campbell has entered the following ballot position for draft-ietf-tokbind-https-14: 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/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-tokbind-https/



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

I plan to ballot "YES", but I want to clear up once concern first= :

After reading section 6 several times, I don't know what it means. I th= ink it's [...]

Addressed in new dra= ft.
=C2=A0

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

Substantive Comments:

=C2=A71.1: Please consider using the boilerplate from 8174 across the clust= er. Both
this and the protocol draft have lower case keyword instances.

Addressed in new draft.
=C2=A0

=C2=A78.2:
- Does it really make sense to wait for a user to request the keys be expir= ed?
I suspect the average user does this about never. Did the working group dis= cuss
possibly making the keys default to expiring after some period of time?

Yes, we did discuss it. This was chosen consc= iously to be in sync with cookies and their expirations / manual user-initi= ated purges.

- Why
is the SHOULD in paragraph 2 not a MUST?

Addressed in new draft.
=C2=A0

Editorial Comments:

=C2=A72:
- Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in = [RFC7230]
style, see also Section 8.3 of [RFC7231]):" The open parenthesis befor= e "in"
seems misplaced. Also, as written the comma after "style" creates= a comma
splice. (Note that this pattern occurs elsewhere in the document.)

- Paragraph 3: The paragraph is a single hard-to-parse sentence. Please
consider breaking into simpler sentences.

Addressed in new draft.
=C2=A0

- example: Am I correct to assume the backslashes are just for print purpos= es
and are not in the actual message? If so, please mention that.

Addressed in new draft.
=C2=A0

=C2=A7 2.1:
- first paragraph, "Within the latter context...": There was no f= ormer context.
I suggest "Within that context..."

Addressed i= n new draft.
=C2=A0
- 2nd paragraph: The first sentence is hard
to parse. I suggest breaking it into separate paragraphs, or restructure without the center-imbedding.

Addressed in new draft.
=C2=A0
- 2nd to last paragraph: Does "SHOULD generally"
mean the same as just "SHOULD"?

Addressed i= n new draft.
=C2=A0

=C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to another se= rver..."

Addressed in new draft.
=C2=A0

=C2=A75.2,
- last bullet: " (between client and Token Consumer)" seems more = than
parenthetical. Please consider removing the parentheses.
=
Addressed in new draft.
=C2=A0
- paragraph after last
bullet: The parenthetical phrase starting with "(proving possession...= ) is
quite long and makes the sentence hard to parse. Given that the concept is<= br> covered in the immediately preceding paragraph, can it be removed?

Addressed in new draft.
=C2=A0

=C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or restate = requirements
in) the protocol and negotiation drafts. Can they be included by reference<= br> instead, or at least attributed?

Addressed in new dra= ft.
=C2=A0

=C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77.1.

Addressed in new draft.=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A78.3: Unneeded comma in first sentence.

Addresse= d in new draft.

Thanks again for the though= tful comments!

Dirk.
--000000000000b08927056dd6c161-- From nobody Mon Jun 4 14:56:39 2018 Return-Path: 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 63A58130E0A for ; Mon, 4 Jun 2018 14:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 9Kt_hOe1MczW for ; Mon, 4 Jun 2018 14:56:34 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5116130E05 for ; Mon, 4 Jun 2018 14:56:33 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id k16-v6so228562wro.0 for ; Mon, 04 Jun 2018 14:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S/dvkkiyJr/0UxODR2BSRSMpzwd3aQ0LtborDCVC51I=; b=hhc65M2j2SR5jAHRvIT6Y+t1rvZ07hYflew+ar0qvsBifkTsTjvxABtcnU8bmbYeiM nImeYclMRJP+/HHXg4ZkQdGOcQRU6qzEf1lYEiVcdsdiXpDLELZ00WThHlmaE64LrX0U oZeTh5m/O3Zrp63u0v6j5gPFLsWLGa1Z9HAzmdoUk9y53YMI+GnE2/lSOxUaBsJTIVAa yFgFHx7SFxZKpkLjz3LtC1K9ZkUEeouKBZCJ9GIsNQtQtpeesiFWB4hsOy9gTYMwVGPh 5uvym/4Nic5CiUUwkS8+QiMD3Awknij8g43CCoEmv5iUG45jkofbj9ErUDLaMRaB//Qc UDAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S/dvkkiyJr/0UxODR2BSRSMpzwd3aQ0LtborDCVC51I=; b=ThYCHPw++1uFuOolyjiyLrJSxltY4CSF6Y1RiRzkmnx8wGQa3ws3qHtCcPwOZcsfL6 4qr7xVXyOAfRLkVB+TMMyTU942AKgiqiyXJSMUy9ombaPHVIagOLBL7ubW5TMSsT+rIM S5Y3Ai3MD3l8mIOzVUFP8gFlb1BttB/fB5UTiLpjdJpy/sUV4LeShWAJzhBGoxGO1dtG go2XSXEcIlP0EW14pEBNG0u5QAGjgLkEe22US18Tz2v+N1T2Rr4x8ShXFF77viJZu3bK axFHAD0ti5+gZtsE+9JHu/q6g92v6DZyq3guRR7z8RS3AMcQ8wUBHADL0FDXlu6/8bAr 4HKQ== X-Gm-Message-State: ALKqPwc5bQhZP6xCxM20vyn0a4MRkXI/OKBVhg700GW148c/OpaDiHn/ 7NV46ETMurcSBf4YDVwTLTWcjykoNwst9lYlrWxee4Xrasg= X-Google-Smtp-Source: ADUXVKID6DXJioj2zVUOEHYqbXFZFU/raomE9c8MFWvT3pNDNEzLexceZhcDhK5DXgyGMjTutEjKyRkSuwF2j2+vrDQ= X-Received: by 2002:adf:8e30:: with SMTP id n45-v6mr16465068wrb.27.1528149391885; Mon, 04 Jun 2018 14:56:31 -0700 (PDT) MIME-Version: 1.0 References: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com> In-Reply-To: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com> From: Dirk Balfanz Date: Mon, 4 Jun 2018 14:56:18 -0700 Message-ID: To: adam@nostrum.com Cc: The IESG , John Bradley , Tokbind WG , tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org Content-Type: multipart/alternative; boundary="000000000000ab3623056dd8015b" Archived-At: Subject: Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 21:56:38 -0000 --000000000000ab3623056dd8015b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adam, thanks for the feedback. Most of it is addressed in the new draft ( https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below (inline) for details. On Mon, May 7, 2018 at 11:06 PM Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-tokbind-https-14: 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://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: > https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to everyone who worked on this document. I am balloting "Yes", but > still have a handful of comments, including several that I believe are > rather important. > > > -------------------------------------------------------------------------= -- > > =C2=A72: > > > Once a client and server have negotiated the Token Binding Protocol > > with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and > > [I-D.ietf-tokbind-negotiation]) > > Presuming this document is intended to cover use of TLS 1.3, I believe th= is > list needs to also include [I-D.ietf-tokbind-tls13]. > Actually, the document doesn=E2=80=99t address TLS 1.3 - that will be cover= ed in a separate document. > > -------------------------------------------------------------------------= -- > > =C2=A75.3: > > > When a client receives the Include-Referred-Token-Binding-ID header, > > it includes the referred token binding even if both the Token > > Provider and the Token Consumer fall under the same eTLD+1 and the > > provided and referred token binding IDs are the same. Note that the > > referred token binding is sent only on the request resulting from the > > redirect and not on any subsequent requests to the Token Provider. > > I think this needs some clarification about handling of multiple > redirections of > the transaction. E.g.: Token Consumer sends a 3xx to redirect the user to= a > Token Provider (using, perhaps, an endpoint that is in the process of bei= ng > migrated), and then the Token Provider sends an additional 3xx to get the > client to the correct server. Presumably, the inclusion of the referred > token > binding should survive both redirections, but this text might be read as > preventing that. > This was consciously chosen to have the semantics that you took from this section (i.e., the header doesn=E2=80=99t survive multiple redirects). The migrating endpoint would have to communicate the Token Binding ID to the final endpoint in some other manner (e.g., through a custom authenticated query parameter). > -------------------------------------------------------------------------= -- > > =C2=A75.3: > > > This header field has only meaning if the HTTP status code is 301, > > 302, 303, 307 or 308, and MUST be ignored by the client for any other > > status codes. > > I'm somewhat less sanguine about this than Alexey is: we've had 3xx-class > response codes registered as recently as three years ago, and I see no > reason to > believe that the future won't hold additional development work on HTTP > overall. > > While I understand that 305 and 306 are deprecated, and the use of the > header > field is nonsensical in 304 and, to a lesser degree, in 300, it seems tha= t > there > is no harm that results in any of these cases if *this* document doesn't > prohibit them. > > Taken one at a time -- In the case of 300, the presence of the header fie= ld > would indicate that whichever option was followed by the user agent would > receive a copy of the token binding, which is as sensible a thing for a > server > to ask for as 300 is in the first place. > > In the case of 304, there is no server to receive the token binding, so n= o > harm > could possible be induced. > > For 305 and 306, to the extent that these are used any more (and they're > not), > the request will arrive back at the same origin that sent the response; > which, > again, causes no information to be divulged that should not be. > > I would strongly recommend changing this to cover all codes in the 300-39= 9 > range, for the purpose of forward-compatibility with new redirection code= s. > Addressed in new draft. > > -------------------------------------------------------------------------= -- > > =C2=A75.4: > > > The TLS Extension for Token Binding Protocol Negotiation > > [I-D.ietf-tokbind-negotiation] > > Same comment as above regarding [I-D.ietf-tokbind-tls13]. > > -------------------------------------------------------------------------= -- > > =C2=A75.5: > > > | {EKMn}Ksm: | EKM for server "n", signed by private key of TBID | > > | | "m", where "n" must represent server receiving the | > > | | ETBMSG, if a conveyed TB's type is | > > | | provided_token_binding, then m =3D n, else if TB's = | > > | | type is referred_token_binding, then m !=3D n. E.g., = | > > | | see step 1b in diagram below. | > > > I was able, with some effort, to muddle through these words and (I think) > figure > out the intention, but the construction is very difficult to follow. I > think you > want to swap the comma after "ETBMSG" for a period. > Addressed in new draft. > > > -------------------------------------------------------------------------= -- > > =C2=A711.1: > > > [fetch-spec] > > WhatWG, "Fetch", Living Standard , > > . > > I share Alexey's concern about a normative reference to a living document= . > I > would like to suggest referencing a specific snapshot (e.g., commit hash)= , > but > the specific referenced document makes this infeasible by means of an > aggressive red-box warning that effectively precludes doing so. I agree > that > understanding the document is not a prerequisite to understanding or > implementing this one, and so agree that (for the time being) moving the > document to the informative reference section is advisable. > Addressed in new draft. Thanks again for your thoughtful comments! Dirk. > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --000000000000ab3623056dd8015b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adam,

thanks for the feedback. Most = of it is addressed in the new draft (https://tools.ietf.org/html/draft-ietf-tokbin= d-https-16). See below (inline) for details.


On Mon, May 7, 2018 at 11:06 PM A= dam Roach <adam@nostrum.com> = wrote:
Adam Roac= h has entered the following ballot position for
draft-ietf-tokbind-https-14: 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://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-tokbind-https/



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

Thanks to everyone who worked on this document. I am balloting "Yes&qu= ot;, but
still have a handful of comments, including several that I believe are
rather important.


---------------------------------------------------------------------------=

=C2=A72:

>=C2=A0 Once a client and server have negotiated the Token Binding Proto= col
>=C2=A0 with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and
>=C2=A0 [I-D.ietf-tokbind-negotiation])

Presuming this document is intended to cover use of TLS 1.3, I believe this=
list needs to also include [I-D.ietf-tokbind-tls13].
<= br>
Actually, the document doesn=E2=80=99t address TLS 1.3 - that= will be covered in a separate document.

=C2= =A0

---------------------------------------------------------------------------=

=C2=A75.3:

>=C2=A0 When a client receives the Include-Referred-Token-Binding-ID hea= der,
>=C2=A0 it includes the referred token binding even if both the Token >=C2=A0 Provider and the Token Consumer fall under the same eTLD+1 and t= he
>=C2=A0 provided and referred token binding IDs are the same.=C2=A0 Note= that the
>=C2=A0 referred token binding is sent only on the request resulting fro= m the
>=C2=A0 redirect and not on any subsequent requests to the Token Provide= r.

I think this needs some clarification about handling of multiple redirectio= ns of
the transaction. E.g.: Token Consumer sends a 3xx to redirect the user to a=
Token Provider (using, perhaps, an endpoint that is in the process of being=
migrated), and then the Token Provider sends an additional 3xx to get the client to the correct server.=C2=A0 Presumably, the inclusion of the referr= ed token
binding should survive both redirections, but this text might be read as preventing that.

This was consciously c= hosen to have the semantics that you took from this section (i.e., the head= er doesn=E2=80=99t survive multiple redirects). The migrating endpoint woul= d have to communicate the Token Binding ID to the final endpoint in some ot= her manner (e.g., through a custom authenticated query parameter).
=C2=A0
---------------------------------------------------------------------------=

=C2=A75.3:

>=C2=A0 This header field has only meaning if the HTTP status code is 30= 1,
>=C2=A0 302, 303, 307 or 308, and MUST be ignored by the client for any = other
>=C2=A0 status codes.

I'm somewhat less sanguine about this than Alexey is: we've had 3xx= -class
response codes registered as recently as three years ago, and I see no reas= on to
believe that the future won't hold additional development work on HTTP = overall.

While I understand that 305 and 306 are deprecated, and the use of the head= er
field is nonsensical in 304 and, to a lesser degree, in 300, it seems that = there
is no harm that results in any of these cases if *this* document doesn'= t
prohibit them.

Taken one at a time -- In the case of 300, the presence of the header field=
would indicate that whichever option was followed by the user agent would receive a copy of the token binding, which is as sensible a thing for a ser= ver
to ask for as 300 is in the first place.

In the case of 304, there is no server to receive the token binding, so no = harm
could possible be induced.

For 305 and 306, to the extent that these are used any more (and they'r= e not),
the request will arrive back at the same origin that sent the response; whi= ch,
again, causes no information to be divulged that should not be.

I would strongly recommend changing this to cover all codes in the 300-399<= br> range, for the purpose of forward-compatibility with new redirection codes.=

Addressed in new draft.
=C2= =A0

---------------------------------------------------------------------------=

=C2=A75.4:

>=C2=A0 The TLS Extension for Token Binding Protocol Negotiation
>=C2=A0 [I-D.ietf-tokbind-negotiation]

Same comment as above regarding [I-D.ietf-tokbind-tls13].

---------------------------------------------------------------------------=

=C2=A75.5:

>=C2=A0 | {EKMn}Ksm: | EKM for server "n", signed by private k= ey of TBID=C2=A0 =C2=A0 |
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | "m", wher= e "n" must represent server receiving the=C2=A0 =C2=A0|
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | ETBMSG, if a convey= ed TB's type is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | provided_token_bind= ing, then m =3D n, else if TB's=C2=A0 =C2=A0 =C2=A0|
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | type is referred_to= ken_binding, then m !=3D n. E.g.,=C2=A0 =C2=A0|
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | see step 1b in diag= ram below.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |


I was able, with some effort, to muddle through these words and (I think) f= igure
out the intention, but the construction is very difficult to follow. I thin= k you
want to swap the comma after "ETBMSG" for a period.

Addressed in new draft.
=C2=A0


---------------------------------------------------------------------------=

=C2=A711.1:

>=C2=A0 [fetch-spec]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WhatWG, "Fetch&quo= t;, Living Standard ,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://fetch.= spec.whatwg.org/>.

I share Alexey's concern about a normative reference to a living docume= nt. I
would like to suggest referencing a specific snapshot (e.g., commit hash), = but
the specific referenced document makes this infeasible by means of an
aggressive red-box warning that effectively precludes doing so. I agree tha= t
understanding the document is not a prerequisite to understanding or
implementing this one, and so agree that (for the time being) moving the document to the informative reference section is advisable.

Addressed in new draft.

Thank= s again for your thoughtful comments!

Dirk.
<= div>
=C2=A0


_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearable=
--000000000000ab3623056dd8015b-- From nobody Mon Jun 4 15:11:57 2018 Return-Path: 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 226F5130E05; Mon, 4 Jun 2018 15:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 F5jJgHUKwV20; Mon, 4 Jun 2018 15:11:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F19130E07; Mon, 4 Jun 2018 15:11:47 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w54MBhnr065612 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Jun 2018 17:11:44 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Dirk Balfanz Cc: The IESG , John Bradley , Tokbind WG , tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org References: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Mon, 4 Jun 2018 17:11:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------20B89BDEB4E2C6C03BA5D2FD" Content-Language: en-US Archived-At: Subject: Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 22:11:50 -0000 This is a multi-part message in MIME format. --------------20B89BDEB4E2C6C03BA5D2FD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/4/18 4:56 PM, Dirk Balfanz wrote: > Hi Adam, > > thanks for the feedback. Most of it is addressed in the new draft > (https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below > (inline) for details. > > Thanks! Some responses inline. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to everyone who worked on this document. I am balloting > "Yes", but > still have a handful of comments, including several that I believe are > rather important. > > > --------------------------------------------------------------------------- > > §2: > > >  Once a client and server have negotiated the Token Binding Protocol > >  with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and > >  [I-D.ietf-tokbind-negotiation]) > > Presuming this document is intended to cover use of TLS 1.3, I > believe this > list needs to also include [I-D.ietf-tokbind-tls13]. > > > Actually, the document doesn’t address TLS 1.3 - that will be covered > in a separate document. Please adjust the title, abstract, and introduction to make this clear. I see neither prose nor technical mechanism in this document that precludes use with TLS 1.3, and it's virtually guaranteed that implementors will try to use it with TLS 1.3 unless there is clear text saying not to. > > > --------------------------------------------------------------------------- > > §5.3: > > >  When a client receives the Include-Referred-Token-Binding-ID > header, > >  it includes the referred token binding even if both the Token > >  Provider and the Token Consumer fall under the same eTLD+1 and the > >  provided and referred token binding IDs are the same. Note that the > >  referred token binding is sent only on the request resulting > from the > >  redirect and not on any subsequent requests to the Token Provider. > > I think this needs some clarification about handling of multiple > redirections of > the transaction. E.g.: Token Consumer sends a 3xx to redirect the > user to a > Token Provider (using, perhaps, an endpoint that is in the process > of being > migrated), and then the Token Provider sends an additional 3xx to > get the > client to the correct server.  Presumably, the inclusion of the > referred token > binding should survive both redirections, but this text might be > read as > preventing that. > > > This was consciously chosen to have the semantics that you took from > this section (i.e., the header doesn’t survive multiple redirects). > The migrating endpoint would have to communicate the Token Binding ID > to the final endpoint in some other manner (e.g., through a custom > authenticated query parameter). That's okay as behaviors go, but I still think the document is somewhat unclear, as the notion of what constitutes a single "request" is a bit muddy in the context of request redirection. I would suggest adding clarifying text similar to what you say above. /a --------------20B89BDEB4E2C6C03BA5D2FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/4/18 4:56 PM, Dirk Balfanz wrote:
Hi Adam,

thanks for the feedback. Most of it is addressed in the new draft (https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below (inline) for details.



Thanks! Some responses inline.



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

Thanks to everyone who worked on this document. I am balloting "Yes", but
still have a handful of comments, including several that I believe are
rather important.


---------------------------------------------------------------------------

§2:

>  Once a client and server have negotiated the Token Binding Protocol
>  with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and
>  [I-D.ietf-tokbind-negotiation])

Presuming this document is intended to cover use of TLS 1.3, I believe this
list needs to also include [I-D.ietf-tokbind-tls13].

Actually, the document doesn’t address TLS 1.3 - that will be covered in a separate document.

Please adjust the title, abstract, and introduction to make this clear. I see neither prose nor technical mechanism in this document that precludes use with TLS 1.3, and it's virtually guaranteed that implementors will try to use it with TLS 1.3 unless there is clear text saying not to.



 

---------------------------------------------------------------------------

§5.3:

>  When a client receives the Include-Referred-Token-Binding-ID header,
>  it includes the referred token binding even if both the Token
>  Provider and the Token Consumer fall under the same eTLD+1 and the
>  provided and referred token binding IDs are the same.  Note that the
>  referred token binding is sent only on the request resulting from the
>  redirect and not on any subsequent requests to the Token Provider.

I think this needs some clarification about handling of multiple redirections of
the transaction. E.g.: Token Consumer sends a 3xx to redirect the user to a
Token Provider (using, perhaps, an endpoint that is in the process of being
migrated), and then the Token Provider sends an additional 3xx to get the
client to the correct server.  Presumably, the inclusion of the referred token
binding should survive both redirections, but this text might be read as
preventing that.

This was consciously chosen to have the semantics that you took from this section (i.e., the header doesn’t survive multiple redirects). The migrating endpoint would have to communicate the Token Binding ID to the final endpoint in some other manner (e.g., through a custom authenticated query parameter).

That's okay as behaviors go, but I still think the document is somewhat unclear, as the notion of what constitutes a single "request" is a bit muddy in the context of request redirection. I would suggest adding clarifying text similar to what you say above.

/a
--------------20B89BDEB4E2C6C03BA5D2FD-- From nobody Mon Jun 4 17:34:23 2018 Return-Path: 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 2CFC1130E3B for ; Mon, 4 Jun 2018 17:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-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=teamtelstra.onmicrosoft.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 FwBf2EZOdDQJ for ; Mon, 4 Jun 2018 17:34:17 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EEBD130E31 for ; Mon, 4 Jun 2018 17:34:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.49,477,1520859600"; d="scan'208,217";a="113339065" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 05 Jun 2018 10:34:13 +1000 X-IronPort-AV: E=McAfee;i="5900,7806,8914"; a="662109312" Received: from tiesinternetgatewaypri.smart-rr.in.telstra.com.au (HELO WSMSG3705.srv.dir.telstra.com) ([172.49.40.203]) by ipcani.tcif.telstra.com.au with ESMTP; 05 Jun 2018 10:34:13 +1000 Received: from wsapp6784.srv.dir.telstra.com (10.75.3.133) by WSMSG3705.srv.dir.telstra.com (172.49.40.203) with Microsoft SMTP Server (TLS) id 8.3.485.1; Tue, 5 Jun 2018 10:34:12 +1000 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp6784.srv.dir.telstra.com (10.75.3.133) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Jun 2018 10:34:10 +1000 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.126) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 5 Jun 2018 10:34:10 +1000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/8r4WyqQjFwRHR+KpNBIUqr5ntWyzIgKfDrVuRAd1qk=; b=YHHhvKijYeU6K3gaDQHpjhDTz7RQx3M2yrE3k0VkdzNaItYyF3q8CP1m5/pOrq3KGFPvUJLz/Otz3hyMBQt+8I6+SWKyoBJNMbshdqROpC0ZXU1DEGZFx/uRd3FrAYNKA3z9Y1MdJoNQbYAo1++Y3i3HyQo+U2NRoQWE8vuTNsI= Received: from SYBPR01MB3546.ausprd01.prod.outlook.com (20.177.137.22) by SYBPR01MB3770.ausprd01.prod.outlook.com (20.177.138.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.14; Tue, 5 Jun 2018 00:34:09 +0000 Received: from SYBPR01MB3546.ausprd01.prod.outlook.com ([fe80::c131:332d:4b01:743b]) by SYBPR01MB3546.ausprd01.prod.outlook.com ([fe80::c131:332d:4b01:743b%2]) with mapi id 15.20.0820.015; Tue, 5 Jun 2018 00:34:09 +0000 From: "Manger, James" To: Brian Campbell , "Leif Johansson" CC: IETF Tokbind WG Thread-Topic: [Unbearable] tokbind - New Meeting Session Request for IETF 102 Thread-Index: AQHT+Kcl8BrfbyTG4EGtXC35UEkRuqRJXiAAgAETswCAAQehAIAAGkEAgAU50CA= Date: Tue, 5 Jun 2018 00:34:09 +0000 Message-ID: References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.35.9.18] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SYBPR01MB3770; 7:uQa1BOJp6iOkmuUDn/totj32ZqH0EKxoKCsyioF5rYwVmE5yE0pa3GO3lYfzzIPW6Xh+2HxxqhBDks14434fFpH+qtISmMRHVQcHMwEszx2ot6POPO7SYD3Etx6ELB2M1OXmWre9QCT53aIKetc62yVIu9EjpQM2EKxkSsHrkEteogw6hgproMiT16WGYX+vHZ9VjO8aVfvXE6M2C1JvgIfMamjlgHg7+c84d03cFB8zpSVOahDD3YWVOfFvCbhS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:SYBPR01MB3770; x-ms-traffictypediagnostic: SYBPR01MB3770: authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:SYBPR01MB3770; BCL:0; PCL:0; RULEID:; SRVR:SYBPR01MB3770; x-forefront-prvs: 0694C54398 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(396003)(346002)(376002)(366004)(189003)(199004)(14454004)(486006)(59450400001)(53546011)(6506007)(99286004)(72206003)(11346002)(446003)(81166006)(76176011)(33656002)(476003)(7696005)(8676002)(2906002)(53936002)(66066001)(102836004)(478600001)(229853002)(3660700001)(81156014)(5890100001)(6436002)(316002)(55016002)(8936002)(606006)(97736004)(7736002)(2900100001)(5660300001)(6116002)(790700001)(106356001)(3846002)(4326008)(26005)(186003)(25786009)(3280700002)(74316002)(1600100001)(54896002)(68736007)(105586002)(93886005)(9686003)(966005)(5250100002)(6306002)(110136005)(236005)(6246003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:SYBPR01MB3770; H:SYBPR01MB3546.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tUn2CCdhj8AcZrHoAEW8aa99FZljd8t3zFFWIKLxfnnZ2tdyADTMLfeRxhGgGbmmVn1qZ3NbuhiVqewHhSLprZlfzn+HAhwNL+BEqgPzU5hVoTEi35R64pIwrK7KBolaoml2zq3H6fhoRUISfXVEQJf7eicoqy8FQnGWQtpDsPruOwpm+dTHEM6UiJ87d4VG spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SYBPR01MB3546DA27767E7E13FBC28FEAE5660SYBPR01MB3546ausp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4ab6b917-a308-4f6f-8c9b-08d5ca7c0d9c X-MS-Exchange-CrossTenant-Network-Message-Id: 4ab6b917-a308-4f6f-8c9b-08d5ca7c0d9c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2018 00:34:09.5443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBPR01MB3770 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 00:34:21 -0000 --_000_SYBPR01MB3546DA27767E7E13FBC28FEAE5660SYBPR01MB3546ausp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ZHJhZnQtaWV0Zi10b2tiaW5kLXR0cnAtMDMgbG9va3Mgb2suDQoNClRoZXJlIGlzIG5vdGhpbmcg dG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBUb2tlbiBCaW5kaW5nIGJlaW5nIG9mZmVyZWQgYnkgdGhl IFRUUlAgYnV0IG5vdCBhY2NlcHRlZCBieSB0aGUgY2xpZW50IHZzIG5vdCBiZWluZyBvZmZlcmVk IGF0IGFsbC4gSeKAmW0gbm90IHN1cmUgaWYgdGhhdCBtYXR0ZXJzLiBQZXJoYXBzIGl0IG9ubHkg bWFrZXMgc2Vuc2UgZm9yIGEgc2VydmVyIHRvIGxvb2sgZm9yIHRoZXNlIGhlYWRlcnMgaWYgaXQg aXMgc3VyZSBhbGwgdGhlIHJldmVyc2UgcHJveGllcyB0aGF0IHNlcnZlIGl0IHN1cHBvcnQgVG9r ZW4gQmluZGluZyBhbmQgYXJlIGNvbmZpZ3VyZWQgdG8gaW5zZXJ0IHRoZXNlIGhlYWRlcnMuDQoN Cg0KTWlub3IgdHlwb3M6DQpUaGVyZSBpcyBubyBleGFtcGxlIG9mIFNlYy1PdGhlci1Ub2tlbi1C aW5kaW5nLg0KDQoyLjEuMiBBQk5GIGZvciBFbmNvZGVkVG9rZW5CaW5kaW5nVHlwZSBkb2VzbuKA mXQgc3RyaWN0bHkgbmVlZCAiQSIgLyAiYSIgYXMg4oCcQUJORiBzdHJpbmdzIGFyZSBjYXNlIGlu c2Vuc2l0aXZl4oCdIFtSRkM1MjM0IHNlY3Rpb24gMi4zPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1MjM0I3NlY3Rpb24tMi4zPl0gc28ganVzdCAiQSIgd291bGQgZG8uIEhhdmluZyBi b3RoIGRvZXMgcmVpbmZvcmNlIHRoYXQgdXBwZXIgYW5kIGxvd2VyIGNhc2UgY2FuIGJlIHVzZWQu IFJlLXVzaW5nIHRoZSBIRVhESUcgY29yZSBBQk5GIHJ1bGUgd291bGQgYmUgc2xpZ2h0bHkgYmV0 dGVyLCB3aXRoIGEgY2FzZS1pbnNlbnNpdGl2ZSBtZW50aW9uIGluIHRoZSB0ZXh0Lg0KDQogICBB IFRva2VuIEJpbmRpbmcgdHlwZSB2YWx1ZSAoYSBzaW5nbGUgYnl0ZSkgY2FuIGJlIHJlcHJlc2Vu dGVkIGFzIGFuDQogICAiRW5jb2RlZFRva2VuQmluZGluZ1R5cGUiLCB3aGljaCBpcyBhIGNhc2Ut aW5zZW5zaXRpdmUgaGV4IGVuY29kaW5nLg0KDQogICAgIEVuY29kZWRUb2tlbkJpbmRpbmdUeXBl ID0gMSoySEVYRElHDQoNCiAgICAgICAgICAgICAgICAgRmlndXJlIDI6IEVuY29kZWQgVG9rZW4g QmluZGluZyBUeXBlIEFCTkYNCg0KVHlwbzogc2VjdGlvbiAzOiDigJzigKYgdGhleSBhcmUgKmEq IHNpbmdsZSBsb2dpY2FsIHNlcnZlcuKAnQ0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTog VW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBTYXR1cmRheSwgMiBKdW5lIDIwMTggMjowNyBBTQ0K VG86IExlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+DQpDYzogSUVURiBUb2tiaW5kIFdHIDx1 bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSB0b2tiaW5kIC0g TmV3IE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0IGZvciBJRVRGIDEwMg0KDQpJdCdzIHByZXR0eSBz aG9ydCEgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC10dHJw LTAzDQoNCk9uIEZyaSwgSnVuIDEsIDIwMTggYXQgODozMiBBTSwgTGVpZiBKb2hhbnNzb24gPGxl aWZqQG1udC5zZTxtYWlsdG86bGVpZmpAbW50LnNlPj4gd3JvdGU6DQoNCg0KT24gMjAxOC0wNi0w MSAwMDo0OSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQo+IEknZCBsaWtlIHRvIHJlcXVlc3Qgc29t ZSBhZ2VuZGEgdGltZSB0byBjb3ZlciB0aGUgVFRSUCBkcmFmdCwgd2hpY2ggd2lsbA0KPiBsaWtl bHkgY29uc2lzdCBvZiBhbiBvdmVydmlldyBhbmQgc3RhdHVzIHVwZGF0ZSAod2l0aCBzb21lIGdy YXR1aXRvdXMNCj4gcGhvdG9zIG9mIHJlY2VudCBJRVRGIG1lZXRpbmcgbG9jYXRpb25zKSBhbmQg YSBwbGVhIHRvIG1vdmUgdG93YXJkcw0KPiBXR0xDLiBUaGFua3MhDQoNCkluIG9yZGVyIHRvIGZh Y2lsaXRhdGUgdGhhdC4uLiBjb3VsZCB3ZSBnZXQgc29tZSBmb2xrcyB0byByZXZpZXcNCnRoZSBU VFJQIGRyYWZ0IGJlZm9yZSAxMDI/DQoNCk1heWJlLi4uIHBsZWFzZS4uLiA/Pw0KDQogICAgICAg IENoZWVycyBMZWlmDQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xl IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3Ry aWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4g IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBt ZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5r IHlvdS4NCg== --_000_SYBPR01MB3546DA27767E7E13FBC28FEAE5660SYBPR01MB3546ausp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1B VTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+ZHJhZnQtaWV0Zi10b2tiaW5kLXR0cnAtMDMgbG9va3Mgb2suPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGVyZSBpcyBub3RoaW5nIHRvIGRpc3Rp bmd1aXNoIGJldHdlZW4gVG9rZW4gQmluZGluZyBiZWluZyBvZmZlcmVkIGJ5IHRoZSBUVFJQIGJ1 dCBub3QgYWNjZXB0ZWQgYnkgdGhlIGNsaWVudCB2cyBub3QgYmVpbmcgb2ZmZXJlZA0KIGF0IGFs bC4gSeKAmW0gbm90IHN1cmUgaWYgdGhhdCBtYXR0ZXJzLiBQZXJoYXBzIGl0IG9ubHkgbWFrZXMg c2Vuc2UgZm9yIGEgc2VydmVyIHRvIGxvb2sgZm9yIHRoZXNlIGhlYWRlcnMgaWYgaXQgaXMgc3Vy ZSBhbGwgdGhlIHJldmVyc2UgcHJveGllcyB0aGF0IHNlcnZlIGl0IHN1cHBvcnQgVG9rZW4gQmlu ZGluZyBhbmQgYXJlIGNvbmZpZ3VyZWQgdG8gaW5zZXJ0IHRoZXNlIGhlYWRlcnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWlub3IgdHlwb3M6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZXJlIGlzIG5vIGV4YW1wbGUgb2YgU2VjLU90 aGVyLVRva2VuLUJpbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij4yLjEuMiBBQk5GIGZvciBFbmNvZGVkVG9rZW5CaW5kaW5nVHlwZSBkb2VzbuKAmXQgc3RyaWN0 bHkgbmVlZCAmcXVvdDtBJnF1b3Q7IC8gJnF1b3Q7YSZxdW90OyBhcyDigJxBQk5GIHN0cmluZ3Mg YXJlIGNhc2UgaW5zZW5zaXRpdmXigJ0gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1MjM0I3NlY3Rpb24tMi4zIj5SRkM1MjM0DQogc2VjdGlvbiAyLjM8L2E+XSBzbyBq dXN0ICZxdW90O0EmcXVvdDsgd291bGQgZG8uIEhhdmluZyBib3RoIGRvZXMgcmVpbmZvcmNlIHRo YXQgdXBwZXIgYW5kIGxvd2VyIGNhc2UgY2FuIGJlIHVzZWQuIFJlLXVzaW5nIHRoZSBIRVhESUcg Y29yZSBBQk5GIHJ1bGUgd291bGQgYmUgc2xpZ2h0bHkgYmV0dGVyLCB3aXRoIGEgY2FzZS1pbnNl bnNpdGl2ZSBtZW50aW9uIGluIHRoZSB0ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgVG9rZW4gQmlu ZGluZyB0eXBlIHZhbHVlIChhIHNpbmdsZSBieXRlKSBjYW4gYmUgcmVwcmVzZW50ZWQgYXMgYW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7ICZxdW90O0VuY29kZWRUb2tlbkJpbmRpbmdUeXBlJnF1b3Q7 LCB3aGljaCBpcyBhIGNhc2UtaW5zZW5zaXRpdmUgaGV4IGVuY29kaW5nLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVuY29kZWRUb2tlbkJpbmRpbmdU eXBlID0gMSoySEVYRElHPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDI6IEVuY29kZWQgVG9rZW4gQmluZGluZyBU eXBlIEFCTkY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlR5cG86IHNl Y3Rpb24gMzog4oCc4oCmIHRoZXkgYXJlICo8Yj5hPC9iPiogc2luZ2xlIGxvZ2ljYWwgc2VydmVy 4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFy YWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIDIgSnVuZSAy MDE4IDI6MDcgQU08YnI+DQo8Yj5Ubzo8L2I+IExlaWYgSm9oYW5zc29uICZsdDtsZWlmakBtbnQu c2UmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gdG9rYmluZCAt IE5ldyBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBmb3IgSUVURiAxMDI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQncyBwcmV0dHkgc2hvcnQhIDxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtdHRycC0wMyI+ DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLXR0cnAtMDM8 L2E+IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBGcmksIEp1biAxLCAyMDE4IGF0IDg6MzIgQU0sIExlaWYgSm9oYW5zc29uICZsdDs8YSBo cmVmPSJtYWlsdG86bGVpZmpAbW50LnNlIiB0YXJnZXQ9Il9ibGFuayI+bGVpZmpAbW50LnNlPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KT24gMjAxOC0wNi0wMSAwMDo0OSwgQnJpYW4gQ2FtcGJlbGwgd3Jv dGU6PGJyPg0KJmd0OyBJJ2QgbGlrZSB0byByZXF1ZXN0IHNvbWUgYWdlbmRhIHRpbWUgdG8gY292 ZXIgdGhlIFRUUlAgZHJhZnQsIHdoaWNoIHdpbGw8YnI+DQomZ3Q7IGxpa2VseSBjb25zaXN0IG9m IGFuJm5ic3A7b3ZlcnZpZXcgYW5kIHN0YXR1cyB1cGRhdGUgKHdpdGggc29tZSBncmF0dWl0b3Vz PGJyPg0KJmd0OyBwaG90b3Mgb2YgcmVjZW50IElFVEYgbWVldGluZyBsb2NhdGlvbnMpIGFuZCBh IHBsZWEgdG8gbW92ZSB0b3dhcmRzPGJyPg0KJmd0OyBXR0xDLiBUaGFua3MhPGJyPg0KPGJyPg0K SW4gb3JkZXIgdG8gZmFjaWxpdGF0ZSB0aGF0Li4uIGNvdWxkIHdlIGdldCBzb21lIGZvbGtzIHRv IHJldmlldzxicj4NCnRoZSBUVFJQIGRyYWZ0IGJlZm9yZSAxMDI/PGJyPg0KPGJyPg0KTWF5YmUu Li4gcGxlYXNlLi4uID8/PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENo ZWVycyBMZWlmPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVy Om5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+Q09ORklERU5USUFMSVRZIE5PVElD RTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0 ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLg0KIEFu eSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBi eSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMg ZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SYBPR01MB3546DA27767E7E13FBC28FEAE5660SYBPR01MB3546ausp_-- From nobody Tue Jun 5 11:05:26 2018 Return-Path: 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 7600F126F72 for ; Tue, 5 Jun 2018 11:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 LHP9x36o1MiO for ; Tue, 5 Jun 2018 11:05:21 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D79128CF3 for ; Tue, 5 Jun 2018 11:05:21 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id d22-v6so4430737iof.13 for ; Tue, 05 Jun 2018 11:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jwd5S+3+zfEUsDp6K2xm8cqJ8Z51usG4p1c5+2Ocvvo=; b=AC44+T8g0wdQiO+W3Y92RMoYzplRKuxFOQHNobIXAwkGJrtWKH2JPSaEN75H6YqYor 49Ir/acsvzIsoqOIlyIc3dDIQQtCrcWzCXz41QX5eBDwwkTpASn72U4liyX3IB8ocG7l uY+vE5mw0vcEsWd+H7otc/cIrjK8EPwoUH3JQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jwd5S+3+zfEUsDp6K2xm8cqJ8Z51usG4p1c5+2Ocvvo=; b=XJJI/Wne+cuiGFcdaVWl34uZCpgkzUdv41V6R2XV/ISUyAYVTuOE5XO6rY1GdKq8t5 NwyQJxP+q2bZ2TmdWfp535Jxc1091QfCOICke7bZQmvh4Wka7Xa5ZBPnlTXpsuuWVquY H2pd5Ac16nXtJ+OFlHcw+4CTknie5JZbw7akYA+X1rWlEZEsfrMXC0nOwgTNvbnbwUDP VNSOE3DSfFftNs4Aty05FRFUdPCl7hxyOToC4bJBmy0kXpiZRtOqkrqk/6Yv6bY+OAHV /w/bpHK0y47mSF/wbakPWerc+7ncgCEtJ+lCFF6Rr9K7GMUzj6mPQy3UJMx75T9KWo9t 6YQQ== X-Gm-Message-State: APt69E1VWvYFocKMbmauPhTVC1bUgnALbgJqSgzFPorqY8URTJEp80M7 XqMpuZ0/Ni3vFYThxzmXXBUhGna1xTnMn/cGWA8kue+ccMrVWBW95uxosA5emI5gLx7xT8kbVZ2 4V/n8imQ7PeMcMlztLRlR X-Google-Smtp-Source: ADUXVKLRRdnbTXam2CzgcRJAi0JdGX4oqBibusvSoAJH9XRO88HISuCEjFlvb+j7LGPUC8zqETKxPVxIDbUvVKB7+gQ= X-Received: by 2002:a6b:588:: with SMTP id 130-v6mr19166878iof.282.1528221920279; Tue, 05 Jun 2018 11:05:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 11:04:49 -0700 (PDT) In-Reply-To: References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> From: Brian Campbell Date: Tue, 5 Jun 2018 12:04:49 -0600 Message-ID: To: "Manger, James" Cc: Leif Johansson , IETF Tokbind WG Content-Type: multipart/alternative; boundary="000000000000b26050056de8e487" Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 18:05:24 -0000 --000000000000b26050056de8e487 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review, James. Replies to the individual comments are inline below. On Mon, Jun 4, 2018 at 6:34 PM, Manger, James wrote: > draft-ietf-tokbind-ttrp-03 looks ok. > Thanks, that is high praise indeed! There is nothing to distinguish between Token Binding being offered by the > TTRP but not accepted by the client vs not being offered at all. I=E2=80= =99m not > sure if that matters. Perhaps it only makes sense for a server to look fo= r > these headers if it is sure all the reverse proxies that serve it support > Token Binding and are configured to insert these headers. > Yeah, there is nothing provided to the back-end server to distinguish between those two cases. But I can't think of a reason that the back-end would do anything meaningful with that distinction. The client and TTRP are doing token binding or they are not and that is what gets conveyed (along with the TB ID, of course). > > Minor typos: > > There is no example of Sec-Other-Token-Binding. > I was somewhat hesitant about adding support at all for conveying token binding types other than provided and referred. That and a touch of laziness led me to not do an example for Sec-Other-Token-Binding in the last draft revision. But it is somewhat incomplete or inconsistent without it. I'll add such an example in the next draft. > > > 2.1.2 ABNF for EncodedTokenBindingType doesn=E2=80=99t strictly need "A" = / "a" as > =E2=80=9CABNF strings are case insensitive=E2=80=9D [RFC5234 section 2.3 > ] so just "A" would do. > Having both does reinforce that upper and lower case can be used. Re-usin= g > the HEXDIG core ABNF rule would be slightly better, with a case-insensiti= ve > mention in the text. > I'd chosen not to reuse HEXDIG so as to allow upper and lower case. However, I'd overlooked the case insensitive nature of ABNF strings you referenced there. I think you're right that using the HEXDIG core ABNF rule along with with a case-insensitive mention in the text is somewhat better. I'll update accordingly. > > Typo: section 3: =E2=80=9C=E2=80=A6 they are **a** single logical server= =E2=80=9D > Will fix. Thanks! > > -- > > James Manger > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Br= ian > Campbell > *Sent:* Saturday, 2 June 2018 2:07 AM > *To:* Leif Johansson > *Cc:* IETF Tokbind WG > *Subject:* Re: [Unbearable] tokbind - New Meeting Session Request for > IETF 102 > > > > It's pretty short! https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-03 > > > > On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson wrote: > > > > On 2018-06-01 00:49, Brian Campbell wrote: > > I'd like to request some agenda time to cover the TTRP draft, which wil= l > > likely consist of an overview and status update (with some gratuitous > > photos of recent IETF meeting locations) and a plea to move towards > > WGLC. Thanks! > > In order to facilitate that... could we get some folks to review > the TTRP draft before 102? > > Maybe... please... ?? > > Cheers Leif > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000b26050056de8e487 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, James. Replies to the individu= al comments are inline below.


On Mon, Jun 4, 2018 at 6:34 PM, Mange= r, James <James.H.Manger@team.telstra.com> wrote:

draft-ietf-tokbind-ttrp-03 looks= ok.

=C2=A0
Thanks, that is high praise = indeed!


There is nothing to distinguish = between Token Binding being offered by the TTRP but not accepted by the cli= ent vs not being offered at all. I=E2=80=99m not sure if that matters. Perhaps it only makes sense = for a server to look for these headers if it is sure all the reverse proxie= s that serve it support Token Binding and are configured to insert these he= aders.

=C2=A0
Yeah, there is nothing provi= ded to the back-end server to distinguish between those two cases. But I ca= n't think of a reason that the back-end would do anything meaningful wi= th that distinction.=C2=A0 The client and TTRP are doing token binding or t= hey are not and that is what gets conveyed (along with the TB ID, of course= ).


=C2=A0

Minor typos:

There is no example of Sec-Other= -Token-Binding.


I was som= ewhat hesitant about adding support at all for=C2=A0conveying token binding= types other than provided and referred. That and a touch of laziness led m= e to not do an example for Sec-Other-Token-Binding in the last draft revisi= on. But it is somewhat incomplete or inconsistent without it. I'll add = such an example in the next draft.

=C2=A0

=C2=A0

2.1.2 ABNF for EncodedTokenBindi= ngType doesn=E2=80=99t strictly need "A" / "a" as =E2= =80=9CABNF strings are case insensitive=E2=80=9D [RFC5234 section 2.3] so just "A" would do. Having both does reinforc= e that upper and lower case can be used. Re-using the HEXDIG core ABNF rule= would be slightly better, with a case-insensitive mention in the text.<= /u>

=C2=A0
I'd chosen not to reuse = HEXDIG so as to allow upper and lower case. However, I'd overlooked the= case insensitive nature of ABNF strings you referenced there. I think you&= #39;re right that using the HEXDIG core ABNF rule along with with a case-in= sensitive mention in the text is somewhat better. I'll update according= ly.


=C2=A0

Typo: section 3: =E2=80=9C=E2=80= =A6 they are *a* single logical server=E2=80=9D


Will fix.

<= br>
Thanks!




=C2=A0

--

James Manger

=C2=A0

From: Unbe= arable [mailto:unbearable-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Saturday, 2 June 2018 2:07 AM
To: Leif Johansson <leifj@mnt.se>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for = IETF 102

=C2=A0

=C2=A0

On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson <<= a href=3D"mailto:leifj@mnt.se" target=3D"_blank">leifj@mnt.se> wrote= :



On 2018-06-01 00:49, Brian Campbell wrote:
> I'd like to request some agenda time to cover the TTRP draft, whic= h will
> likely consist of an=C2=A0overview and status update (with some gratui= tous
> photos of recent IETF meeting locations) and a plea to move towards > WGLC. Thanks!

In order to facilitate that... could we get some folks to review
the TTRP draft before 102?

Maybe... please... ??

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif

=C2=A0


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed..=C2=A0 If you have received this communication in error, please notify = the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000b26050056de8e487-- From nobody Tue Jun 5 11:47:16 2018 Return-Path: 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 4E5D213113D for ; Tue, 5 Jun 2018 11:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 e0_5hskXahhs for ; Tue, 5 Jun 2018 11:47:12 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C7C130DC4 for ; Tue, 5 Jun 2018 11:47:09 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id s26-v6so4609524ioj.4 for ; Tue, 05 Jun 2018 11:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZmJpObQ9RhdCBURi5MzfkngNftrKq7Y9BhjuHResdRA=; b=Gv2mcJBvALZjuNMqxFcdSzHToTCfNw+/HrMfk4OxHVyN7RxWUAai6KtvPbXPSngcOw UgUnLOVk6YAnQmX+GsaudMEt8cvs+M0nNske4uhKK6M29HrKV1ZweRh/e1H38AOxUQbW XdZq26xS9j+6IxZ6AUyJDBn3UeJndwnXwwxtqdpi7rPbB4AQRfKX3pwin2RhtQ/hKJBm CR+gn2Ohv8yBeY3PM2fRexjKV2ZJW2J1Vbj3t/marAWu9o63pMm6uXaShaibK9G+i5Qn JslnGbyMq3T7mlB02+bz0uTpnzIqQUzUJD2vLEiu1uhNZei8kLEOffaY33rK5KN69I9h jnKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZmJpObQ9RhdCBURi5MzfkngNftrKq7Y9BhjuHResdRA=; b=PA0dAYJ9M5dawi98aqhxZ+Q2rDBxwvsRJYiFhwwNnARb4gQKnFgjoDnB3fjTPf0s1/ KLjqtckYDRHpplr+8sH2oA6l5sr9d9/vLNA5+PuprdLqV5bkvCe5dB6cs/07Ok6Tfp0c 9NhjBCuSsmrOfchAqgDJHxdCW/dtbiuWskn344g6fKmzwXhO+82IdcfgYpT7wl2T0G/V ZXg4WKFcref26Ih3EQpsXyZBZUgOrKlWts2EwDprG/jfd00J5SaRXtC8z2IWiqy3F5I3 JTh6zKiwnMwn8t1YM6Aeu5agFEkDrlmig7mFyuJ6jjwfZdNXeWqT5Z3/q1ZumIECPefn 985A== X-Gm-Message-State: APt69E1ZB7bRVTWRCWgOPbvi0Eit3IB7h+1h8IhY6/ghXlgQSri+NPcc dNMRPW9YoehbXmH2SwgYLq/E/ZKlGdTXs0Q+u+Xthg== X-Google-Smtp-Source: ADUXVKKdkImLpfhmys9AkKq96vvhFXVZgQS+QrPmWb/ujoXahkPgDGtjP0/dvfxgHrcYYjgkT+9CUEzN4JDOpq5qu0I= X-Received: by 2002:a6b:14cd:: with SMTP id 196-v6mr28385651iou.103.1528224428301; Tue, 05 Jun 2018 11:47:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:e0a:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 11:46:47 -0700 (PDT) In-Reply-To: References: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com> From: Nick Harper Date: Tue, 5 Jun 2018 11:46:47 -0700 Message-ID: To: Adam Roach Cc: Dirk Balfanz , The IESG , John Bradley , Tokbind WG , tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org Content-Type: multipart/alternative; boundary="000000000000309dbc056de97abc" Archived-At: Subject: Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 18:47:15 -0000 --000000000000309dbc056de97abc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 4, 2018 at 3:11 PM, Adam Roach wrote: > On 6/4/18 4:56 PM, Dirk Balfanz wrote: > > Hi Adam, > > thanks for the feedback. Most of it is addressed in the new draft ( > https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below > (inline) for details. > > > > Thanks! Some responses inline. > > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks to everyone who worked on this document. I am balloting "Yes", bu= t >> still have a handful of comments, including several that I believe are >> rather important. >> >> >> ------------------------------------------------------------ >> --------------- >> >> =C2=A72: >> >> > Once a client and server have negotiated the Token Binding Protocol >> > with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and >> > [I-D.ietf-tokbind-negotiation]) >> >> Presuming this document is intended to cover use of TLS 1.3, I believe >> this >> list needs to also include [I-D.ietf-tokbind-tls13]. >> > > Actually, the document doesn=E2=80=99t address TLS 1.3 - that will be cov= ered in a > separate document. > > > Please adjust the title, abstract, and introduction to make this clear. I > see neither prose nor technical mechanism in this document that precludes > use with TLS 1.3, and it's virtually guaranteed that implementors will tr= y > to use it with TLS 1.3 unless there is clear text saying not to. > I think this document does cover using Token Binding with TLS 1.3, but only once draft-ietf-tokbind-tls13 is published. (I.e. before the draft is published, it does not cover TLS 1.3, because draft-ietf-tokbind-protocol is limited to TLS 1.2, but once draft-ietf-tokbind-tls13 is published, this automatically covers TLS 1.3 as well.) --000000000000309dbc056de97abc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 4, 2018 at 3:11 PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 6/4/18 4:56 PM, = Dirk Balfanz wrote:
Hi Adam,

thanks for the feedback. Most of it is addressed in the new draft (https://tools.ietf.org/html/draft-ietf-tok= bind-https-16). See below (inline) for details.



Thanks! Some responses inline.



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Thanks to everyone who worked on this document. I am balloting "Yes", but
still have a handful of comments, including several that I believe are
rather important.


-----------------------------------------------------------------= ----------

=C2=A72:

>=C2=A0 Once a client and server have negotiated the Token Binding Protocol
>=C2=A0 with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and
>=C2=A0 [I-D.ietf-tokbind-negotiation])

Presuming this document is intended to cover use of TLS 1.3, I believe this
list needs to also include [I-D.ietf-tokbind-tls13].

Actually, the document doesn=E2=80=99t address TLS 1.3 - tha= t will be covered in a separate document.

 Please adjust the title, abstract, and introduction to make this clear. I see neither prose nor technical mechanism in this document that precludes use with TLS 1.3, and it's virtually guaranteed that implementors will try to use it with TLS 1.3 unless there is clear text saying not to.=C2=A0

I think= this document does cover using Token Binding with TLS 1.3, but only once d= raft-ietf-tokbind-tls13 is published. (I.e. before the draft is published, = it does not cover TLS 1.3, because draft-ietf-tokbind-protocol is limited t= o TLS 1.2, but once draft-ietf-tokbind-tls13 is published, this automatical= ly covers TLS 1.3 as well.)
--000000000000309dbc056de97abc-- From nobody Tue Jun 5 11:50:44 2018 Return-Path: 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 915A7131141; Tue, 5 Jun 2018 11:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 ef9Q9Fp386Dz; Tue, 5 Jun 2018 11:50:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5F4126F72; Tue, 5 Jun 2018 11:50:40 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w55IobUA071520 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 5 Jun 2018 13:50:37 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Nick Harper Cc: Dirk Balfanz , The IESG , John Bradley , Tokbind WG , tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org References: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Tue, 5 Jun 2018 13:50:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------28B798A08218A2DA6C2B6135" Content-Language: en-US Archived-At: Subject: Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 18:50:43 -0000 This is a multi-part message in MIME format. --------------28B798A08218A2DA6C2B6135 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/5/18 1:46 PM, Nick Harper wrote: > > > On Mon, Jun 4, 2018 at 3:11 PM, Adam Roach > wrote: > > On 6/4/18 4:56 PM, Dirk Balfanz wrote: >> Hi Adam, >> >> thanks for the feedback. Most of it is addressed in the new draft >> (https://tools.ietf.org/html/draft-ietf-tokbind-https-16 >> ). See >> below (inline) for details. >> >> > > Thanks! Some responses inline. > > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks to everyone who worked on this document. I am >> balloting "Yes", but >> still have a handful of comments, including several that I >> believe are >> rather important. >> >> >> --------------------------------------------------------------------------- >> >> §2: >> >> >  Once a client and server have negotiated the Token Binding >> Protocol >> >  with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and >> >  [I-D.ietf-tokbind-negotiation]) >> >> Presuming this document is intended to cover use of TLS 1.3, >> I believe this >> list needs to also include [I-D.ietf-tokbind-tls13]. >> >> >> Actually, the document doesn’t address TLS 1.3 - that will be >> covered in a separate document. > > Please adjust the title, abstract, and introduction to make this > clear. I see neither prose nor technical mechanism in this > document that precludes use with TLS 1.3, and it's virtually > guaranteed that implementors will try to use it with TLS 1.3 > unless there is clear text saying not to. > > > I think this document does cover using Token Binding with TLS 1.3, but > only once draft-ietf-tokbind-tls13 is published. (I.e. before the > draft is published, it does not cover TLS 1.3, because > draft-ietf-tokbind-protocol is limited to TLS 1.2, but once > draft-ietf-tokbind-tls13 is published, this automatically covers TLS > 1.3 as well.) Then please add an informative reference to draft-ietf-tokbind-tls13. /a --------------28B798A08218A2DA6C2B6135 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/5/18 1:46 PM, Nick Harper wrote:


On Mon, Jun 4, 2018 at 3:11 PM, Adam Roach <adam@nostrum.com> wrote:
On 6/4/18 4:56 PM, Dirk Balfanz wrote:
Hi Adam,

thanks for the feedback. Most of it is addressed in the new draft (https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below (inline) for details.



Thanks! Some responses inline.



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

Thanks to everyone who worked on this document. I am balloting "Yes", but
still have a handful of comments, including several that I believe are
rather important.


---------------------------------------------------------------------------

§2:

>  Once a client and server have negotiated the Token Binding Protocol
>  with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and
>  [I-D.ietf-tokbind-negotiation])

Presuming this document is intended to cover use of TLS 1.3, I believe this
list needs to also include [I-D.ietf-tokbind-tls13].

Actually, the document doesn’t address TLS 1.3 - that will be covered in a separate document.

 Please adjust the title, abstract, and introduction to make this clear. I see neither prose nor technical mechanism in this document that precludes use with TLS 1.3, and it's virtually guaranteed that implementors will try to use it with TLS 1.3 unless there is clear text saying not to. 

I think this document does cover using Token Binding with TLS 1.3, but only once draft-ietf-tokbind-tls13 is published. (I.e. before the draft is published, it does not cover TLS 1.3, because draft-ietf-tokbind-protocol is limited to TLS 1.2, but once draft-ietf-tokbind-tls13 is published, this automatically covers TLS 1.3 as well.)


Then please add an informative reference to draft-ietf-tokbind-tls13.

/a

--------------28B798A08218A2DA6C2B6135-- From nobody Tue Jun 5 12:01:57 2018 Return-Path: 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 4B012131145 for ; Tue, 5 Jun 2018 12:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xL6xWtf8bCMQ for ; Tue, 5 Jun 2018 12:01:44 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C48B131187 for ; Tue, 5 Jun 2018 12:01:44 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id t6-v6so4642535iob.10 for ; Tue, 05 Jun 2018 12:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=APAvRFTt5sxnsXSZBitWmRZYiPA//jprzvVzjF3Pu5M=; b=rfifbaGI/Iz152gWGetuZR3Uj7/EFV9oiqxDrrR+MoXApuDj/0Za7O7grjBVnWTyjV IvoktfSnksV/RJi58s/8i0wQM2oMcqJJvwTscJaoZwd3Fi+Wy3VfyDC81fWCNTfaVExw pYDUQGiZnkRoCWhXt4S4sF5Wx2YvdCZRExKibr4BIrkbgvm0LcQJP6JUyWgbLNtl9BwZ x3TXyRGg+gMwZPxIYM0ieBYhbkPY5/jJVxxT2EluGIVjeHyHe2OQLyffn8FKXamQHthS Gk11E7RBuvrQJFJDa0zT3PP6Sa2aRfwDfkCmgdax2Tzw4ui7t5HUJksPyg7VvKGV8Xtn GmvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=APAvRFTt5sxnsXSZBitWmRZYiPA//jprzvVzjF3Pu5M=; b=Y28ZxdphVFz1Fc0IBhfS+C0cU5rO9z7HMxm4Y5c6b48pyieE5/v0ZxxLSL4a4lkKyE m6xMSqbVEyh9iVtCsIxuTi8/TkVaXpshbvrWXj7gVRsb3wxKq3ll+MrxqC9NAm4A6hp6 6ptNBnBQcvqPv+hc/XZ59l3WeHcVTCwcPZjmdxpWjdnZVzPBSNifDPrrrNz895tI3bLv /BjLnsZUofgFlKi8XjXqfvbvkeLrhCRJ/CnTOge9Vt9v46XQ+KCruD7YLwwQGrA72Vjw uJabXT5WeHDwoVU27485rOgMir98CBaXb5QAW+XmwdbTaLLcPNNGe9+1wDvaIbAuOu+p 3AEg== X-Gm-Message-State: APt69E1esSCQ2poTnnkfpn3upeS9+2GQM8eSf5i5oRD+PFiXk8Vnqce+ z5YH/iJVxsc+xbbNg0P2F+XOAnja6mEssW/W5h3uDQ== X-Google-Smtp-Source: ADUXVKIT2dHRGRK3tijEYAvSeclMjtjcCrrKnrhsbz26Xt1MOmfV+L/Gl/arzwtbs9h4MbPQQOHl7EFeMn2sY0AUElU= X-Received: by 2002:a6b:3110:: with SMTP id j16-v6mr26762401ioa.249.1528225303125; Tue, 05 Jun 2018 12:01:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:e0a:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 12:01:22 -0700 (PDT) In-Reply-To: References: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com> From: Nick Harper Date: Tue, 5 Jun 2018 12:01:22 -0700 Message-ID: To: Adam Roach Cc: Dirk Balfanz , The IESG , John Bradley , Tokbind WG , tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org Content-Type: multipart/alternative; boundary="000000000000550e23056de9ae77" Archived-At: Subject: Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 19:01:56 -0000 --000000000000550e23056de9ae77 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 5, 2018 at 11:50 AM, Adam Roach wrote: > Then please add an informative reference to draft-ietf-tokbind-tls13. > > /a > The reason for splitting off draft-ietf-tokbind-tls13 into a separate draft was so that publication of draft-ietf-tls-tls13 doesn't delay publication of the 3 core tokbind drafts (draft-ietf-tokbind-protocol, draft-ietf-tokbind-negotiation, and draft-ietf-tokbind-https). It sounds like adding a reference to draft-ietf-tokbind-tls13 would result in postponing publication of at least this draft until both draft-ietf-tls-tls13 and draft-ietf-tokbind-tls13 get published. Given that the WG's goal of excluding TLS 1.3 in the 3 core drafts is to avoid blocking them on publication of draft-ietf-tls-tls13, what do you think the best approach is with this? --000000000000550e23056de9ae77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 5, 2018 at 11:50 AM, Adam Roach <adam@nostrum.com> wr= ote:
=20 =20 =20
Then please add an informative reference to draft-ietf-tokbind-tls13.

/a

The reason for splitting off draft-ietf-tokbind-tls13 in= to a separate draft was so that publication of draft-ietf-tls-tls13 doesn&#= 39;t delay publication of the 3 core tokbind drafts (draft-ietf-tokbind-pro= tocol, draft-ietf-tokbind-negotiation, and draft-ietf-tokbind-https). It so= unds like adding a reference to draft-ietf-tokbind-tls13 would result in po= stponing publication of at least this draft until both draft-ietf-tls-tls13= and draft-ietf-tokbind-tls13 get published.

Given that the WG's goal of excl= uding TLS 1.3 in the 3 core drafts is to avoid blocking them on publication= of draft-ietf-tls-tls13, what do you think the best approach is with this?=
--000000000000550e23056de9ae77-- From nobody Tue Jun 5 12:07:53 2018 Return-Path: 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 E9249130DC2; Tue, 5 Jun 2018 12:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 g4PUgchollSn; Tue, 5 Jun 2018 12:07:49 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC233130DEE; Tue, 5 Jun 2018 12:07:49 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w55J7jgX074420 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 5 Jun 2018 14:07:46 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Nick Harper Cc: Dirk Balfanz , The IESG , John Bradley , Tokbind WG , tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org References: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <69cb4854-912f-cc4f-1a61-d730ac53b89d@nostrum.com> Date: Tue, 5 Jun 2018 14:07:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------73847364591D96045D0457B1" Content-Language: en-US Archived-At: Subject: Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 19:07:52 -0000 This is a multi-part message in MIME format. --------------73847364591D96045D0457B1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 6/5/18 2:01 PM, Nick Harper wrote: > On Tue, Jun 5, 2018 at 11:50 AM, Adam Roach > wrote: > > Then please add an informative reference to draft-ietf-tokbind-tls13. > > /a > > The reason for splitting off draft-ietf-tokbind-tls13 into a separate > draft was so that publication of draft-ietf-tls-tls13 doesn't delay > publication of the 3 core tokbind drafts (draft-ietf-tokbind-protocol, > draft-ietf-tokbind-negotiation, and draft-ietf-tokbind-https). It > sounds like adding a reference to draft-ietf-tokbind-tls13 would > result in postponing publication of at least this draft until both > draft-ietf-tls-tls13 and draft-ietf-tokbind-tls13 get published. It would if the reference were normative. This is why I said "informative reference" above. /a --------------73847364591D96045D0457B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 6/5/18 2:01 PM, Nick Harper wrote:
On Tue, Jun 5, 2018 at 11:50 AM, Adam Roach <adam@nostrum.com> wrote:
Then please add an informative reference to draft-ietf-tokbind-tls13.

/a

The reason for splitting off draft-ietf-tokbind-tls13 into a separate draft was so that publication of draft-ietf-tls-tls13 doesn't delay publication of the 3 core tokbind drafts (draft-ietf-tokbind-protocol, draft-ietf-tokbind-negotiation, and draft-ietf-tokbind-https). It sounds like adding a reference to draft-ietf-tokbind-tls13 would result in postponing publication of at least this draft until both draft-ietf-tls-tls13 and draft-ietf-tokbind-tls13 get published.

It would if the reference were normative. This is why I said "informative reference" above.

/a --------------73847364591D96045D0457B1-- From nobody Tue Jun 5 12:29:00 2018 Return-Path: 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 70732130DCE for ; Tue, 5 Jun 2018 12:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 WN2e9v_BDb0h for ; Tue, 5 Jun 2018 12:28:49 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60ADF131145 for ; Tue, 5 Jun 2018 12:28:49 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id d8-v6so3638776wro.4 for ; Tue, 05 Jun 2018 12:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L/ayTEifHPqz1FjBROPkeXol9MzCU0h3/9zPx+oFJVg=; b=gI5V6sVmXgjs88dqWmfEQ54TXuoHHkd5Qm+f/HnQI80Easzakb7qgJDqNnoLpVeazi HRpAcz7yuzyFoRJL03lh1kFiuoFb6wTkTMvbwf4c5ScQzXHZ55DJeogVNFSV3Z9M2x87 PWr0aH+nBpCNacjQgZWw19jDCeGhC8ZusKSTmGHrKPUjtfRVZ8NqQSYe/7JocL0UtArL ErS9W8fANNX+qHd2AaJPQOb2hRiV+NGIJCIlyNZqBNRbQWMQvuCne0jf16+66MgONyPn 4/UJpaR3yrVZRlyRYzkSSzjnDnTorPp7Aymmrk61Al2Abl8yZG59Advm3mbvzbS07c7q 99fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L/ayTEifHPqz1FjBROPkeXol9MzCU0h3/9zPx+oFJVg=; b=FF2c1Zw+GxbsMp4vXkRG4ZoSp2qNswRC7RcLiyrl+K7b5OnH9x98ljwFf9G0ueW7Bt 7YiY5seFkAAbR18cL+GsDdU/WzDE5ZsIiciM+iIyxGxN29W53/gULFlQFITzMt9sV5hs hEO/TkYGTwhXeoZSUsLlwKm2ZYD93nWHNPyozXK/ycmpfYMiBShKVG1ikA6AbRfVq8TD Rjfpg0QasCT+Vu+zVYn9tS4xGMG/yrf1Pz0uaEn0l8OcgsTtHwy8k7W01Kh6e1usbuZD 7tSo2vAuYbrDyf2V7nNdMQ8f2u2jamcX424quaftdHW0+JbIetFjeBO5WgElEKukBH64 idXQ== X-Gm-Message-State: ALKqPweNdhq3/1vI+rOCLcd5js8l2Ee0k9J0gHzAFXAGGGGIL6VzPftg r2AeUb7D48EcpMMLFziCwpqJPBqftzCFQwJH+J32uA== X-Google-Smtp-Source: ADUXVKIKsPfu2OclNRSHqhq5maOVB7A+nhxqmR++YsiksxpjQBjk55YA0lByuyv5NnJQxZx9VCjYFK5g0ZpqJzfRFAM= X-Received: by 2002:adf:9441:: with SMTP id 59-v6mr15882279wrq.274.1528226927429; Tue, 05 Jun 2018 12:28:47 -0700 (PDT) MIME-Version: 1.0 References: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com> <69cb4854-912f-cc4f-1a61-d730ac53b89d@nostrum.com> In-Reply-To: <69cb4854-912f-cc4f-1a61-d730ac53b89d@nostrum.com> From: John Bradley Date: Tue, 5 Jun 2018 21:28:34 +0200 Message-ID: To: Adam Roach Cc: Nick Harper , Dirk Balfanz , The IESG , Tokbind WG , tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org Content-Type: multipart/alternative; boundary="000000000000255d09056dea0fad" Archived-At: Subject: Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 19:28:53 -0000 --000000000000255d09056dea0fad Content-Type: text/plain; charset="UTF-8" I think adding a non normative reference to the current draft of tls13 is fine. The data tracker will have the forward reference to the final spec if someone follows it. John B. On Tue, Jun 5, 2018, 9:07 PM Adam Roach wrote: > On 6/5/18 2:01 PM, Nick Harper wrote: > > On Tue, Jun 5, 2018 at 11:50 AM, Adam Roach wrote: > >> Then please add an informative reference to draft-ietf-tokbind-tls13. >> >> /a >> > The reason for splitting off draft-ietf-tokbind-tls13 into a separate > draft was so that publication of draft-ietf-tls-tls13 doesn't delay > publication of the 3 core tokbind drafts (draft-ietf-tokbind-protocol, > draft-ietf-tokbind-negotiation, and draft-ietf-tokbind-https). It sounds > like adding a reference to draft-ietf-tokbind-tls13 would result in > postponing publication of at least this draft until both > draft-ietf-tls-tls13 and draft-ietf-tokbind-tls13 get published. > > > It would if the reference were normative. This is why I said "informative > reference" above. > > /a > --000000000000255d09056dea0fad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think adding a non normative reference to the curr= ent draft of tls13 is fine.=C2=A0 The data tracker will have the forward re= ference to the final spec if someone follows it.=C2=A0=C2=A0

John B.=C2=A0

On Tue, Jun 5, 2018, 9:07 PM Adam = Roach <adam@nostrum.com> wrot= e:
=20 =20 =20
On 6/5/18 2:01 PM, N= ick Harper wrote:
On Tue, Jun 5, 2018 at 11:50 AM, Adam Roach <adam@nostrum.com> wrote:
Then please add an informative reference to draft-ietf-tokbind-tls13.

/a

The reason for splitting off draft-ietf-tokbind-tls13 into a separate draft was so that publication of draft-ietf-tls-tls13 doesn't delay publication of the 3 core tokbind drafts (draft-ietf-tokbind-protocol, draft-ietf-tokbind-negotiation, and draft-ietf-tokbind-https). It sounds like adding a reference to draft-ietf-tokbind-tls13 would result in postponing publication of at least this draft until both draft-ietf-tls-tls13 and draft-ietf-tokbind-tls13 get published.

It would if the reference were normative. This is why I said "informative reference" above.

/a
--000000000000255d09056dea0fad-- From nobody Tue Jun 5 21:41:33 2018 Return-Path: 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 0B299130E98 for ; Tue, 5 Jun 2018 21:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QqV1XzpPs9EV for ; Tue, 5 Jun 2018 21:41:23 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4227130E97 for ; Tue, 5 Jun 2018 21:41:17 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id l41-v6so4675467wre.7 for ; Tue, 05 Jun 2018 21:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NYRB22EZGhBPFwyBfVfhbvbTwiZx99K4qywjPgsvtfo=; b=YpKwLtMPKOq5LpvRxWvsC3Pxsc6D84/8ahfz1e5V5WPHDDkt1+rXVTW8sRANORvr6s 8w+zBDEyO1XqKPaJgp/bJEopHmynoolQZeTtyOwT7Wbr9rs7LGj0OpLPr45fLYq7dBRs CitVfmv+QRKkblXpiz0UdnHfrEFUMW0oe018nY4dphOm7S5Us+gmqvWWRYfwKfXlntk7 vNEbGE9dpYMgyb/LNVO77FAjcS9esMk/0qvMJeamc28ZvVnpxLa1rIAbvQQGdCrc5dAm 6vXdkbnkQ2zFYovzJYeiDwEAgmEhUq21IUKswyFnrW/JDwuIbcHN6tHCX0CR/caX4sd7 EpdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NYRB22EZGhBPFwyBfVfhbvbTwiZx99K4qywjPgsvtfo=; b=Gk/yITsXCT0DvJ5dxf0dvnHoKBDjJnjCUUvS2I97geDuvkP0mSl0V3GS/iQwgM8bzI v62P85torXMTixoVXz1HrInMEDCkG319FMd1QFtgkWsmy6oaVdOpdogZWFEJxPnR28Jm 0XnLT3CuqjPJ7KKsS+ctVIDz4NHaABhulaCy2tm4F0ZRjNC3DYzmQJ5IqsyD3Z+UHpEV ARbkdP83QloYKb9+VplvtAgMrVyvWczDmaDDXYIYynUx4FD9prsEa5jYKeqB/R8Ipwq+ D1ktrmGzVkosLdfiOXCEqfMCbbUTsDOfBKMrTqx1+ryQYCtXh0Qq923Gd2/0AbF8jFuk Cjvw== X-Gm-Message-State: APt69E1sn5kvSW3IFpCAzPz/JsJ3D85a64eHJKF9psSy6ALYNXm44hCK yE3x0HHishhe+yeDz2QUxOEEZAdGDO62OfDYscBMyg== X-Google-Smtp-Source: ADUXVKJMCU1Bjxceo2iicWin2jlWFpzt1sCP1ksoPLKJfninNIPV+b8Br0u1ytMHaz+RHdSHoANa97/GglaFmFVUQbg= X-Received: by 2002:adf:fec2:: with SMTP id q2-v6mr961455wrs.165.1528260075859; Tue, 05 Jun 2018 21:41:15 -0700 (PDT) MIME-Version: 1.0 References: <152596031836.10294.13536754824931837516.idtracker@ietfa.amsl.com> In-Reply-To: <152596031836.10294.13536754824931837516.idtracker@ietfa.amsl.com> From: Dirk Balfanz Date: Tue, 5 Jun 2018 21:41:03 -0700 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-tokbind-https@ietf.org, John Bradley , tokbind-chairs@ietf.org, Tokbind WG Content-Type: multipart/alternative; boundary="000000000000f2ac4f056df1c6f3" Archived-At: Subject: Re: [Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 04:41:25 -0000 --000000000000f2ac4f056df1c6f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Benjamin, thanks for the feedback. Most of it is addressed in the new draft ( https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below (inline) for details. On Thu, May 10, 2018 at 6:51 AM Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-tokbind-https-15: No Objection > > 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: > https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alexey about clarifying that backslashes are only for > readability. > Addressed in the new draft. > > I'm curious why Section 2 limits to at most one referred_token_binding. > We couldn't come up with examples where we would have more than one, and wanted to write the spec as narrow as possible for now. > > > Section 2 > > A TokenBindingMessage is validated by the server as described in > Section 4.2. ("Server Processing Rules") of > [I-D.ietf-tokbind-protocol]. > > Nit: no period after "4.2". > Addressed in new draft. > > [...] If validation fails and a Token Binding > is rejected, any associated bound tokens MUST also be rejected by the > server. > > I repeat my remark about "associated" from tokbind-protocol. > > > Section 2.1 > > It seems a little unusual to see "Applications other than Web > browsers MAY [...]", though I do not object. > > > Section 3 > > To be clear, this means that the EKM used is the one from before > the renegotiation, corresponding in the somewhat-common use case of > renegotiation for optional client authentication to the > unauthenticated-client state, right? > See previous answers from Nick et al. It's a new EKM. > > > Section 5.3 > > As illustrated in Section 5.5, when a client receives this header > field, it should take the TokenBindingID of the provided TokenBinding > from the referrer and create a referred TokenBinding with it to > include in the TokenBindingMessage on the redirect request. In other > words, the Token Binding message in the redirect request to the Token > Provider now includes one provided binding and one referred binding, > the latter constructed from the binding between the client and the > Token Consumer. > > I'm not really an HTTP expert, but is "redirect request" the right > term (as opposed to, say, "redirected request" or "post-redirect > request")? > > The TokenBindingMessage SHOULD contain a TokenBinding with > TokenBindingType referred_token_binding. > > At this point we may have lost track of what "The > TokenBindingMessage" refers to -- some explicit scope (the message > sent to the Token Provider after following the redirect) could be > helpful. > Addressed in new draft. > > > Section 7.1 > > The goal of the Federated Token Binding mechanisms is to prevent > attackers from exporting and replaying tokens used in protocols > between the client and Token Consumer, [...] > > Do we actually need to limit the scope to Token Consumer? The Token > Provider may also issue tokens that we want to protect, after all. > Correct - and that=E2=80=99s covered in the more general version of this consideration in draft-ietf-tokbind-protocol. Here we point out that the federation mechanism in particular focuses on the client<->Token Consumer connection. > > > Section 7.2 > > Do we need to repeat the normative statements already made in > [TBPROTO]? Maybe we can just say that [TBPROTO] requires these > things to be used, to protect against [TRIPLE-HS]. > Addressed in new draft. Thanks again for your thoughtful comments! Dirk. --000000000000f2ac4f056df1c6f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,=C2=A0

thanks for the feedb= ack. Most of it is addressed in the new draft (https://tools.iet= f.org/html/draft-ietf-tokbind-https-16). See below (inline) for details= .

On Thu, May 10, 2018= at 6:51 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
Benjamin Kaduk has entered the following ballot positio= n for
draft-ietf-tokbind-https-15: No Objection

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/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-tokbind-https/



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

I agree with Alexey about clarifying that backslashes are only for readabil= ity.

Addressed in the new draft.
<= div>=C2=A0

I'm curious why Section 2 limits to at most one referred_token_binding.=

We couldn't come up with examples = where we would have more than one, and wanted to write the spec as narrow a= s possible for now.
=C2=A0


Section 2

=C2=A0 =C2=A0A TokenBindingMessage is validated by the server as described = in
=C2=A0 =C2=A0Section 4.2.=C2=A0 ("Server Processing Rules") of =C2=A0 =C2=A0[I-D.ietf-tokbind-protocol].

Nit: no period after "4.2".

A= ddressed in new draft.
=C2=A0

=C2=A0 =C2=A0[...] If validation fails and a Token Binding
=C2=A0 =C2=A0is rejected, any associated bound tokens MUST also be rejected= by the
=C2=A0 =C2=A0server.

I repeat my remark about "associated" from tokbind-protocol.


Section 2.1

It seems a little unusual to see "Applications other than Web
browsers MAY [...]", though I do not object.


Section 3

To be clear, this means that the EKM used is the one from before
the renegotiation, corresponding in the somewhat-common use case of
renegotiation for optional client authentication to the
unauthenticated-client state, right?

Se= e previous answers from Nick et al. It's a new EKM.
=C2=A0


Section 5.3

=C2=A0 =C2=A0As illustrated in Section 5.5, when a client receives this hea= der
=C2=A0 =C2=A0field, it should take the TokenBindingID of the provided Token= Binding
=C2=A0 =C2=A0from the referrer and create a referred TokenBinding with it t= o
=C2=A0 =C2=A0include in the TokenBindingMessage on the redirect request.=C2= =A0 In other
=C2=A0 =C2=A0words, the Token Binding message in the redirect request to th= e Token
=C2=A0 =C2=A0Provider now includes one provided binding and one referred bi= nding,
=C2=A0 =C2=A0the latter constructed from the binding between the client and= the
=C2=A0 =C2=A0Token Consumer.

I'm not really an HTTP expert, but is "redirect request" the = right
term (as opposed to, say, "redirected request" or "post-redi= rect
request")?

=C2=A0 =C2=A0The TokenBindingMessage SHOULD contain a TokenBinding with
=C2=A0 =C2=A0TokenBindingType referred_token_binding.

At this point we may have lost track of what "The
TokenBindingMessage" refers to -- some explicit scope (the message
sent to the Token Provider after following the redirect) could be
helpful.

Addressed in new draft.
<= div>=C2=A0


Section 7.1

=C2=A0 =C2=A0The goal of the Federated Token Binding mechanisms is to preve= nt
=C2=A0 =C2=A0attackers from exporting and replaying tokens used in protocol= s
=C2=A0 =C2=A0between the client and Token Consumer, [...]

Do we actually need to limit the scope to Token Consumer?=C2=A0 The Token Provider may also issue tokens that we want to protect, after all.

Correct - and that=E2=80=99s covered in th= e more general version of this consideration in draft-ietf-tokbind-protocol= . Here we point out that the federation mechanism in particular focuses on = the client<->Token Consumer connection.

=C2=A0


Section 7.2

Do we need to repeat the normative statements already made in
[TBPROTO]?=C2=A0 Maybe we can just say that [TBPROTO] requires these
things to be used, to protect against [TRIPLE-HS].
Addressed in new draft.

Thanks again f= or your thoughtful comments!

Dirk.

<= /div>
=C2=A0
--000000000000f2ac4f056df1c6f3-- From nobody Tue Jun 5 22:06:15 2018 Return-Path: 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 86DBC130E96 for ; Tue, 5 Jun 2018 22:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 uYfWPz0-dq1X for ; Tue, 5 Jun 2018 22:06:10 -0700 (PDT) Received: from m69-170.mailgun.net (m69-170.mailgun.net [166.78.69.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C9E130E37 for ; Tue, 5 Jun 2018 22:06:10 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1528261569; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=dTGRVT5vckFinesHsAs0kRg/Hj+c6o9YItQA97LTB9k=; b=RghusnN5sa2ZZDE71/BFJhBG1dhHFJCplEteC5HEoMWdGrYlYiHZ5ZhnEuj5rJQehBuPqV9l VExqOi9sDDJM0q9R0O/TW8M/HQlxwvCOuJynE6aRpng41raDJ0m5GaChRiecmS+a7wXfleu9 yZshSwWjksBHIu/i4AplrunTI/0= X-Mailgun-Sending-Ip: 166.78.69.170 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Sender: dirk=balfanz.net@github.com Received: from github.com (Unknown [192.30.252.37]) by mxa.mailgun.org with ESMTP id 5b176bc1.7fc1762fab40-smtp-out-n01; Wed, 06 Jun 2018 05:06:09 -0000 (UTC) Date: Tue, 05 Jun 2018 22:06:08 -0700 From: Dirk Balfanz Reply-To: Dirk Balfanz To: unbearable@ietf.org Message-ID: <5b176bc02fbea_5f9c2b1f05fd1c1450712@hookshot-fe-32b5f5b.cp1-iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_5b176bc02f73e_5f9c2b1f05fd1c14506e0"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 925439: Started v17. Added an informal reference to tokbin... X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 05:06:12 -0000 ----==_mimepart_5b176bc02f73e_5f9c2b1f05fd1c14506e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 925439a1152984a81555b1ddbcb377484bb6f11a https://github.com/TokenBinding/Internet-Drafts/commit/925439a1152984a81555b1ddbcb377484bb6f11a Author: Dirk Balfanz Date: 2018-06-05 (Tue, 05 Jun 2018) Changed paths: R draft-ietf-tokbind-https-16.xml A draft-ietf-tokbind-https-17.xml Log Message: ----------- Started v17. Added an informal reference to tokbind-tls13. Clarified language on whether referred token bindings survive multiple redirects. Commit: d1b47c556d33e552b66df1d96850a562da0ceef1 https://github.com/TokenBinding/Internet-Drafts/commit/d1b47c556d33e552b66df1d96850a562da0ceef1 Author: Dirk Balfanz Date: 2018-06-05 (Tue, 05 Jun 2018) Changed paths: M draft-ietf-tokbind-https-17.xml Log Message: ----------- tagging as v17 Compare: https://github.com/TokenBinding/Internet-Drafts/compare/3c05ace8c53c...d1b47c556d33 **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019. ----==_mimepart_5b176bc02f73e_5f9c2b1f05fd1c14506e0-- From nobody Tue Jun 5 22:07:55 2018 Return-Path: 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 7A57A130DDE; Tue, 5 Jun 2018 22:07:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152826166746.19008.7202309501213424477@ietfa.amsl.com> Date: Tue, 05 Jun 2018 22:07:47 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-17.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 05:07:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : Token Binding over HTTP Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Nick Harper Jeff Hodges Filename : draft-ietf-tokbind-https-17.txt Pages : 25 Date : 2018-06-05 Abstract: This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections. We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token. This document is a companion document to The Token Binding Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-https-17 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 5 22:11:49 2018 Return-Path: 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 43B89130E96 for ; Tue, 5 Jun 2018 22:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 kXmmUUYmkj9P for ; Tue, 5 Jun 2018 22:11:44 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F03130E37 for ; Tue, 5 Jun 2018 22:11:41 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id w10-v6so4721738wrk.9 for ; Tue, 05 Jun 2018 22:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m5ca3KygPKCDi5mjgeT7rhsbm+zw4TvsgtLLv7m96Xs=; b=I029BsdWlJjFPxBieaLPRycqPQdH/+XMSWjq+J2aAnXqPI1Dtoip6QI8j78MwpVW9M annE4sCurjaKQlVlvrh5QOqR3k1pgD7J8XF/CT9TBrzB0WgpYQWs8prq0mhQyXLzpNEh yt0EJp06yczyhpjjafgwwoXg0B05ap2Y0enPe5Z9GKNjb/jE11Oa2OAcloliaK6yj2ai +L5H4aFMPncw2fC8nZIDe+qG0S/1D+08zVSnUxuieMKyC1rez4i6z8xBT7fdpygKxcq6 mBPRpV2Gxom7YCERZniLSpTjS6dl75bZgsr2rqLXGfa/D3tu6y4lvNUSGOV//IDHfqqN Y+9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m5ca3KygPKCDi5mjgeT7rhsbm+zw4TvsgtLLv7m96Xs=; b=cJo6OkVfRaMmR0dBVPlezH09+sscpCIn2/4cXVIDAVRUPxXIEuNcpjqeP/+yT2c+9O 5qCrRk3CB0DBuTlq+lNRCQyZaE6NOoEE5cEvSMjP2giVGBhrzbFmsYDeeznvBDBdaZFm fuLDsiE9E2OHPEFMYXxrwEOvWo4VMkGWb2PQQUESva2sPQy0IKPG8xX0kCqjLaxUwf4u l7eOBoOXGG5WCL1mkUn/BWb0Esa0LRLFk31debKTjaawrzX0AQJpspgnUpY1Hs09wK9B kSIsEOJrG3gxoo6XWGgRkv93ssoXdLWWt7wDkCetKthEhmb3c3+KAzvxhm+ZskyQZK6J tA3Q== X-Gm-Message-State: APt69E1tDXTODRhnKHRmmwmnK5zqC4WsUu1a/rQtFSguGkrf0PaI44m8 TgUFI1o7IeWVlxUcViaMw8Da6zfm8dncPh+gXj5E+g== X-Google-Smtp-Source: ADUXVKJ8877+JUuXGPQRUtlJW9QOGTW9LLPwOTBaVshBo94qh5C+R46LsVhuQzvRbdoEmbxrMpZ+IM6y6QwSk3SgkRI= X-Received: by 2002:adf:eccd:: with SMTP id s13-v6mr1078147wro.160.1528261899477; Tue, 05 Jun 2018 22:11:39 -0700 (PDT) MIME-Version: 1.0 References: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com> <69cb4854-912f-cc4f-1a61-d730ac53b89d@nostrum.com> In-Reply-To: From: Dirk Balfanz Date: Tue, 5 Jun 2018 22:11:27 -0700 Message-ID: To: John Bradley Cc: Adam Roach , Nick Harper , The IESG , Tokbind WG , tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4d0ec056df23312" Archived-At: Subject: Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 05:11:47 -0000 --000000000000a4d0ec056df23312 Content-Type: text/plain; charset="UTF-8" I uploaded a new draft ( https://tools.ietf.org/html/draft-ietf-tokbind-https-17) that includes a non-normative reference to tokbind-tls13, and some clarifying language around redirects. Dirk. On Tue, Jun 5, 2018 at 12:28 PM John Bradley wrote: > I think adding a non normative reference to the current draft of tls13 is > fine. The data tracker will have the forward reference to the final spec > if someone follows it. > > John B. > > On Tue, Jun 5, 2018, 9:07 PM Adam Roach wrote: > >> On 6/5/18 2:01 PM, Nick Harper wrote: >> >> On Tue, Jun 5, 2018 at 11:50 AM, Adam Roach wrote: >> >>> Then please add an informative reference to draft-ietf-tokbind-tls13. >>> >>> /a >>> >> The reason for splitting off draft-ietf-tokbind-tls13 into a separate >> draft was so that publication of draft-ietf-tls-tls13 doesn't delay >> publication of the 3 core tokbind drafts (draft-ietf-tokbind-protocol, >> draft-ietf-tokbind-negotiation, and draft-ietf-tokbind-https). It sounds >> like adding a reference to draft-ietf-tokbind-tls13 would result in >> postponing publication of at least this draft until both >> draft-ietf-tls-tls13 and draft-ietf-tokbind-tls13 get published. >> >> >> It would if the reference were normative. This is why I said "informative >> reference" above. >> >> /a >> > --000000000000a4d0ec056df23312 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I uploaded a new draft (https://tools.ietf.org/html/draft-ietf-to= kbind-https-17) that includes a non-normative reference to tokbind-tls1= 3, and some clarifying language around redirects.=C2=A0

= Dirk.

On Tue, Ju= n 5, 2018 at 12:28 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
<= div dir=3D"auto">
I think adding a non normative reference to the curre= nt draft of tls13 is fine.=C2=A0 The data tracker will have the forward ref= erence to the final spec if someone follows it.=C2=A0=C2=A0

John B.=C2=A0

On Tue, Jun 5, 2018, 9:07 PM Adam = Roach <adam@nostru= m.com> wrote:
=20 =20 =20
On 6/5/18 2:01 PM, Nick Harper wrote:
On Tue, Jun 5, 2018 at 11:50 AM, Adam Roach <adam@nostrum.com> wrote:
T= hen please add an informative reference to draft-ietf-tokbind-tls13.

/a

The reason for splitting off draft-ietf-tokbind-tls13 into a separate draft was so that publication of draft-ietf-tls-tls13 doesn't delay publication of the 3 core tokbind drafts (draft-ietf-tokbind-protocol, draft-ietf-tokbind-negotiation, and draft-ietf-tokbind-https). It sounds like adding a reference to draft-ietf-tokbind-tls13 would result in postponing publication of at least this draft until both draft-ietf-tls-tls13 and draft-ietf-tokbind-tls13 get published.

It would if the reference were normative. This is why I said "informative reference" above.

/a
--000000000000a4d0ec056df23312-- From nobody Wed Jun 6 09:45:34 2018 Return-Path: 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 3882A130F90; Wed, 6 Jun 2018 09:44:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152830349817.6220.12949705837733503874@ietfa.amsl.com> Date: Wed, 06 Jun 2018 09:44:58 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-04.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 16:45:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : HTTPS Token Binding with TLS Terminating Reverse Proxies Author : Brian Campbell Filename : draft-ietf-tokbind-ttrp-04.txt Pages : 13 Date : 2018-06-06 Abstract: This document defines HTTP header fields that enable a TLS terminating reverse proxy to convey information to a backend server about the validated Token Binding Message received from a client, which enables that backend server to bind, or verify the binding of, cookies and other security tokens to the client's Token Binding key. This facilitates the reverse proxy and backend server functioning together as though they are a single logical server side deployment of HTTPS Token Binding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-04 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-ttrp-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-ttrp-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 6 09:51:40 2018 Return-Path: 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 BA88D130F70 for ; Wed, 6 Jun 2018 09:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 5G_GzmvQ8ehl for ; Wed, 6 Jun 2018 09:51:31 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D280D130F66 for ; Wed, 6 Jun 2018 09:51:30 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id a195-v6so9055347itd.3 for ; Wed, 06 Jun 2018 09:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PQafGFRyDcjZZ9CdD9b80FE6+16TAAM60voLJ47xLDE=; b=VGIYe2dWyoHQvZrMFQeD0T6wiwUc+Hb1hjIrLP2+I7MwQTsQa19MSm7OGcjNAJnTRJ +Pif8ynXYcMExzGemzuhTQViNVbX8pVADj1+noCpp48OcZkzetTS2ptQulw2S89+h0g1 /f6JtkBdgCeGMlrMXI2lAbm88lhxGOWvXJT94= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PQafGFRyDcjZZ9CdD9b80FE6+16TAAM60voLJ47xLDE=; b=h60jK+aSOWsMOmOsxlqvgRwV/UINCDvLeauYBhwYvsz35uZDVVIWjPN96QN061ez58 qjpyFhtv+aMzg7mX3A7E1fHHKCx/dMiWVsZTeYyUm2C7tN9tXLBvCGgWPDv8RfNXjCKK rc9jhbZYfZYl1mDBww5Pk+Pfke6f4EC7D/VPY8ByRqq0CcCtdEeJtZapy/rO0WwHMw4r 78TZ6frdHjBrawdiUc/r2hMqPcURRwObEjDHnrzpM79aQcpVvvsG+Vq7m++WyVJNSmV/ J+uoaz/ZaCg7suCrfRjanOlTHpmQYmS34t0vhbfzZ9+tjQPqppt/BCDkH5bE91LYBo+v OHFA== X-Gm-Message-State: APt69E26UZz7GxX4qjp+MdGZE08y+mKaikByoq5aKXNWMRPUrtkOcbre tbyMHA6Xftl9fnym6Pvj0tr2GsSh81nCN9qHB7eARxjeMogRvtgAjTdTM6eg/oPe0v8fVc5OD1e i7Zvw+fengknz2v4/te9YzB8= X-Google-Smtp-Source: ADUXVKKX5W+9NeWnDoLFoaCJFGrrZLKP2TY4uvn+puyTaBBsJG5rAokFwcCR5QxK4B3m1pyyI0edzFA6GVVMxxqnstU= X-Received: by 2002:a24:96:: with SMTP id 144-v6mr3542400ita.76.1528303890001; Wed, 06 Jun 2018 09:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 09:50:59 -0700 (PDT) In-Reply-To: References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> From: Brian Campbell Date: Wed, 6 Jun 2018 10:50:59 -0600 Message-ID: To: "Manger, James" Cc: Leif Johansson , IETF Tokbind WG Content-Type: multipart/alternative; boundary="0000000000007909a9056dfbfafc" Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 16:51:36 -0000 --0000000000007909a9056dfbfafc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks again for the review, James. I've submitted -04 with changes addressing the comments. Name: draft-ietf-tokbind-ttrp Revision: 04 Title: HTTPS Token Binding with TLS Terminating Reverse Proxies Document date: 2018-06-06 Group: tokbind Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-ietf-tokbind-ttr= p -04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ Htmlized: https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-tt rp Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tokbind-ttrp= -04 On Tue, Jun 5, 2018 at 12:04 PM, Brian Campbell wrote: > Thanks for the review, James. Replies to the individual comments are > inline below. > > > On Mon, Jun 4, 2018 at 6:34 PM, Manger, James < > James.H.Manger@team.telstra.com> wrote: > >> draft-ietf-tokbind-ttrp-03 looks ok. >> > > Thanks, that is high praise indeed! > > > There is nothing to distinguish between Token Binding being offered by th= e >> TTRP but not accepted by the client vs not being offered at all. I=E2=80= =99m not >> sure if that matters. Perhaps it only makes sense for a server to look f= or >> these headers if it is sure all the reverse proxies that serve it suppor= t >> Token Binding and are configured to insert these headers. >> > > Yeah, there is nothing provided to the back-end server to distinguish > between those two cases. But I can't think of a reason that the back-end > would do anything meaningful with that distinction. The client and TTRP > are doing token binding or they are not and that is what gets conveyed > (along with the TB ID, of course). > > > >> >> Minor typos: >> >> There is no example of Sec-Other-Token-Binding. >> > > I was somewhat hesitant about adding support at all for conveying token > binding types other than provided and referred. That and a touch of > laziness led me to not do an example for Sec-Other-Token-Binding in the > last draft revision. But it is somewhat incomplete or inconsistent withou= t > it. I'll add such an example in the next draft. > > > >> >> >> 2.1.2 ABNF for EncodedTokenBindingType doesn=E2=80=99t strictly need "A"= / "a" as >> =E2=80=9CABNF strings are case insensitive=E2=80=9D [RFC5234 section 2.3 >> ] so just "A" would do. >> Having both does reinforce that upper and lower case can be used. Re-usi= ng >> the HEXDIG core ABNF rule would be slightly better, with a case-insensit= ive >> mention in the text. >> > > I'd chosen not to reuse HEXDIG so as to allow upper and lower case. > However, I'd overlooked the case insensitive nature of ABNF strings you > referenced there. I think you're right that using the HEXDIG core ABNF ru= le > along with with a case-insensitive mention in the text is somewhat better= . > I'll update accordingly. > > > >> >> Typo: section 3: =E2=80=9C=E2=80=A6 they are **a** single logical server= =E2=80=9D >> > > Will fix. > > > Thanks! > > > > > >> >> -- >> >> James Manger >> >> >> >> *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *B= rian >> Campbell >> *Sent:* Saturday, 2 June 2018 2:07 AM >> *To:* Leif Johansson >> *Cc:* IETF Tokbind WG >> *Subject:* Re: [Unbearable] tokbind - New Meeting Session Request for >> IETF 102 >> >> >> >> It's pretty short! https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-0= 3 >> >> >> >> On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson wrote: >> >> >> >> On 2018-06-01 00:49, Brian Campbell wrote: >> > I'd like to request some agenda time to cover the TTRP draft, which wi= ll >> > likely consist of an overview and status update (with some gratuitous >> > photos of recent IETF meeting locations) and a plea to move towards >> > WGLC. Thanks! >> >> In order to facilitate that... could we get some folks to review >> the TTRP draft before 102? >> >> Maybe... please... ?? >> >> Cheers Leif >> >> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000007909a9056dfbfafc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks again for the review, James. I've submitte= d -04 with changes addressing the comments.

<= br>
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0draft-ietf-tokbind-ttrp
Revision:=C2=A0 =C2=A0 =C2=A0= =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HTTPS To= ken Binding with TLS Terminating Reverse Proxies
Document d= ate:=C2=A0 2018-06-06
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 tokbind
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/= internet-drafts/draft-ietf-tokbind-ttrp-04.txt
Statu= s:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-04
https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-ttrp
= Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-tokbind-ttrp-04

On Tue, Jun 5, 2018 at 12:04 PM, Brian= Campbell <bcampbell@pingidentity.com> wrote:
Thanks for the review, J= ames. Replies to the individual comments are inline below.


On Mon, = Jun 4, 2018 at 6:34 PM, Manger, James <James.H.Manger@team.t= elstra.com> wrote:

draft-ietf-tokbind-ttrp-03 looks= ok.

=C2=A0
Thanks, that is high praise = indeed!


There is nothing to distinguish = between Token Binding being offered by the TTRP but not accepted by the cli= ent vs not being offered at all. I=E2=80=99m not sure if that matters. Perhaps it only makes sense = for a server to look for these headers if it is sure all the reverse proxie= s that serve it support Token Binding and are configured to insert these he= aders.

=C2=A0
Yeah, there is nothin= g provided to the back-end server to distinguish between those two cases. B= ut I can't think of a reason that the back-end would do anything meanin= gful with that distinction.=C2=A0 The client and TTRP are doing token bindi= ng or they are not and that is what gets conveyed (along with the TB ID, of= course).


=C2=A0

Minor typos:

There is no example of Sec-Other= -Token-Binding.


I = was somewhat hesitant about adding support at all for=C2=A0conveying token = binding types other than provided and referred. That and a touch of lazines= s led me to not do an example for Sec-Other-Token-Binding in the last draft= revision. But it is somewhat incomplete or inconsistent without it. I'= ll add such an example in the next draft.
=
=C2=A0

=C2=A0

2.1.2 ABNF for EncodedTokenBindi= ngType doesn=E2=80=99t strictly need "A" / "a" as =E2= =80=9CABNF strings are case insensitive=E2=80=9D [RFC5234 section 2.3] so just "A" would do. Having both does reinforc= e that upper and lower case can be used. Re-using the HEXDIG core ABNF rule= would be slightly better, with a case-insensitive mention in the text.<= /u>

=C2=A0
I'd chosen not to= reuse HEXDIG so as to allow upper and lower case. However, I'd overloo= ked the case insensitive nature of ABNF strings you referenced there. I thi= nk you're right that using the HEXDIG core ABNF rule along with with a = case-insensitive mention in the text is somewhat better. I'll update ac= cordingly.


=C2=A0

Typo: section 3: =E2=80=9C=E2=80= =A6 they are *a* single logical server=E2=80=9D


Will fix.


Thanks!




=C2=A0

--

James Manger

=C2=A0

From: Unbe= arable [mailto:unbearable-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Saturday, 2 June 2018 2:07 AM
To: Leif Johansson <leifj@mnt.se>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for = IETF 102

=C2=A0

=C2=A0

On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson <<= a href=3D"mailto:leifj@mnt.se" target=3D"_blank">leifj@mnt.se> wrote= :



On 2018-06-01 00:49, Brian Campbell wrote:
> I'd like to request some agenda time to cover the TTRP draft, whic= h will
> likely consist of an=C2=A0overview and status update (with some gratui= tous
> photos of recent IETF meeting locations) and a plea to move towards > WGLC. Thanks!

In order to facilitate that... could we get some folks to review
the TTRP draft before 102?

Maybe... please... ??

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif

=C2=A0


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed..=C2=A0 If you have received this communication in error, please notify = the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000007909a9056dfbfafc-- From nobody Wed Jun 6 11:52:07 2018 Return-Path: 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 6701E129385 for ; Wed, 6 Jun 2018 11:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable 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 lPliQKtqwNbY for ; Wed, 6 Jun 2018 11:52:01 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0139.outbound.protection.outlook.com [104.47.42.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D3F129619 for ; Wed, 6 Jun 2018 11:51:57 -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:X-MS-Exchange-SenderADCheck; bh=gfrQZFTjo0IpRbwdb4jVCBG+dq47BJd3mxqp9KBmeyA=; b=JFUykzrXgCX4zhgfE86tTWUNOZV3shIPohF7fyRK2Z5h8rLo9n8C73DZNvitE75cR7oe+mVtsSI65JXlUUAmfRthlnCqwEJh64nuk0K0Oyk+xgkX7ZIMjLoCmnirIMzEOSGXhW+zqGjOuDWw9Wlq1UMvvxwRNBhvZ0M1qMQCRrU= Received: from DM5PR21MB0507.namprd21.prod.outlook.com (10.172.91.141) by DM5PR21MB0284.namprd21.prod.outlook.com (10.173.174.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.7; Wed, 6 Jun 2018 18:51:56 +0000 Received: from DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::7cac:8247:7a46:1bfd]) by DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::7cac:8247:7a46:1bfd%16]) with mapi id 15.20.0863.004; Wed, 6 Jun 2018 18:51:56 +0000 From: Andrei Popov To: Brian Campbell , Leif Johansson CC: IETF Tokbind WG Thread-Topic: [Unbearable] tokbind - New Meeting Session Request for IETF 102 Thread-Index: AQHT+KcSOfkm5RG+C024j4aQmtNOyqRJXiAAgAETswCAAQehAIAAGkEAgAVCOXA= Date: Wed, 6 Jun 2018 18:51:56 +0000 Message-ID: References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:1:28bc:a023:971b:e42c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0284; 7:u2Umk6kB557HA7FIcTFe77l0OoU3lcXajBFUMTo5esKvYi6WyALbZ+Kj4zP2YTxkzFtETMBb9xRXx1or+2kwPgOMc4DWykgYhe4Ya38CqEsXyc7zIYoqPhbhzvWiHaZDO8SMrzIY2y9cydbEvQspsOOJYFS3Fd1QpHKBB+ayZ9Saf8K4pMJq8XvyvRmAUohbOYo8i6ob9e4kLqe7fK8/8/h3WXsjAEgDaQznGdHSuKdaIvBOglXSrUj5U/zh4V8I x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR21MB0284; x-ms-traffictypediagnostic: DM5PR21MB0284: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(189930954265078)(100405760836317)(219752817060721)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DM5PR21MB0284; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0284; x-forefront-prvs: 06952FC175 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39380400002)(396003)(39860400002)(189003)(199004)(6116002)(6436002)(4326008)(229853002)(19609705001)(1600100001)(966005)(2906002)(76176011)(55016002)(2900100001)(10290500003)(5250100002)(99286004)(6246003)(14454004)(478600001)(7696005)(8936002)(81156014)(81166006)(5660300001)(8676002)(33656002)(68736007)(446003)(11346002)(5890100001)(486006)(606006)(72206003)(476003)(22452003)(105586002)(74316002)(93886005)(7736002)(316002)(110136005)(10090500001)(9686003)(54896002)(186003)(236005)(3280700002)(86612001)(53546011)(6506007)(97736004)(59450400001)(86362001)(102836004)(53936002)(790700001)(25786009)(46003)(3660700001)(8990500004)(106356001)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0284; H:DM5PR21MB0507.namprd21.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) x-microsoft-antispam-message-info: XysHpkGmtqaZfbYzlLyd9bOAD/FlD+VxLz29sGmESB/mBJOy270JePIk7QeWpPOMraBcuCROFUJ/8fIuBVJqbpnGoZY6LLaG/DQ+DF0Esp12YsDYxWFhFTISgHlG3U0T6lUHUGkfIPSPfNvsU9xchUGAXYUOzMNehEx/udFljtFElosySYFaP9scPtrh9OiS spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR21MB050756924C75D2A4CB31826C8C650DM5PR21MB0507namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: e8b40a0a-b268-44b5-2972-08d5cbde938f X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e8b40a0a-b268-44b5-2972-08d5cbde938f X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 18:51:56.1164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0284 Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 18:52:06 -0000 --_000_DM5PR21MB050756924C75D2A4CB31826C8C650DM5PR21MB0507namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRvY3VtZW50IGlzIHdlbGwtd3JpdHRlbiBhbmQgY2xlYXIsIG92ZXJhbGwuIEkgaGF2ZSBh IGZldyBlZGl0b3JpYWwgY29tbWVudHMgYW5kIHNvbWUgZGVzaWduIGNvbW1lbnRzOg0KDQogIOKA nFRva2VuIEJpbmRpbmcgb3ZlciBIVFRQIFtJLUQuaWV0Zi10b2tiaW5kLWh0dHBzXSBwcm92aWRl cyBhIG1lY2hhbmlzbQ0KICAgdGhhdCBlbmFibGVzIEhUVFAgc2VydmVycyB0byBjcnlwdG9ncmFw aGljYWxseSBiaW5kIGNvb2tpZXMgYW5kIG90aGVyDQogICBzZWN1cml0eSB0b2tlbnMgdG8gYSBr ZXkgaGVsZCBieSB0aGUgYnJvd3NlciBvciBvdGhlciBIVFRQIGNsaWVudCwNCiAgIHBvc3Nlc3Np b24gb2Ygd2hpY2ggaXMgcHJvdmVuIG9uIHRoZSBUTFMgW1JGQzUyNDZdIGNvbm5lY3Rpb25zIG92 ZXINCiAgIHdoaWNoIHRoZSB0b2tlbnMgYXJlIHVzZWQu4oCdDQoNCkVkaXRvcmlhbCBzdWdnZXN0 aW9uOiDigJzigKZ0byBhIGtleSBnZW5lcmF0ZWQgYnkgdGhlIGNsaWVudC7igJ0gV2hldGhlciB0 aGUgYnJvd3NlciwgSFRUUCBjbGllbnQsIG9yIHVuZGVybHlpbmcgcGxhdGZvcm0gaG9sZCB0aGUg VEIga2V5IGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGFuZCBwcm9iYWJseSB1bm5lY2Vzc2Fy eSBkZXRhaWwgaGVyZS4gUHJvb2Ygb2YgcG9zc2Vzc2lvbiBpcyBkaXNjdXNzZWQgaW4gdGhlIG5l eHQgc2VudGVuY2UuDQoNCiAg4oCcVGhlIHVzYWdlIG9mIHRoZSBoZWFkZXJzLCBib3RoIHRoZSBy ZXZlcnNlIHByb3h5IGFkZGluZyBfaXRfIGFuZCB0aGUNCiAgIGFwcGxpY2F0aW9uIHNlcnZlciB1 c2luZyBfdGhlbV8gdG8gYmluZCBjb29raWVzIG9yIG90aGVyIHRva2VucywgYXJlIHRvDQogICBi ZSBjb25maWd1cmF0aW9uIG9wdGlvbnMgb2YgdGhlIHJlc3BlY3RpdmUgc3lzdGVtcyBhcyB0aGV5 IHdpbGwgbm90DQogICBhbHdheXMgYmUgYXBwbGljYWJsZS7igJ0NCg0KRWRpdG9yaWFsOiB0aGlz IHNlbnRlbmNlIGNvbmZ1c2VzIG1lLCBlc3AuIGFyb3VuZCDigJxpdOKAnSBhbmQg4oCcdGhlbeKA nTsgcGVyaGFwcyBpdOKAmXMgcG9zc2libGUgdG8gc2ltcGxpZnkuDQoNClNlY3Rpb24gMi4yOiBI YXZpbmcgdGhyZWUgc2VwYXJhdGUgaGVhZGVyczogU2VjLVByb3ZpZGVkLCBTZWMtUmVmZXJyZWQg YW5kIFNlYy1PdGhlciBjYXRjaC1hbGwgd291bGQgbm90IGJlIG15IGRlc2lnbiBjaG9pY2UuIEni gJlkIHN1Z2dlc3QgZWl0aGVyIG9uZSBoZWFkZXIgd2l0aCBhIGxpc3Qgb2YgYWxsIFRCIElEcywg b3IgYSBzZXBhcmF0ZSBoZWFkZXIgZm9yIGVhY2ggVEIgSUQuIE9mIGNvdXJzZSwgaWYgV0cgY29u c2Vuc3VzIGV4aXN0cyBvbiB0aGUgY3VycmVudCBkZXNpZ24sIHRoZW4gdGhhdOKAmXMgd2hhdCBp dCBpcy4NCg0KICAg4oCcQm90aCAiU2VjLVByb3ZpZGVkLVRva2VuLUJpbmRpbmctSUQiIGFuZCAi U2VjLVJlZmVycmVkLVRva2VuLUJpbmRpbmctDQogICBJRCIgYXJlIHNpbmdsZSBIVFRQIGhlYWRl ciBmaWVsZC12YWx1ZWTigKbigJ0NCg0KU29tZXdoYXQgcmVsYXRlZCB0byB0aGUgcHJldmlvdXMg Y29tbWVudDogdGhpcyBzZWVtcyB0byBiZSBzYXlpbmcgdGhhdCB0aGVyZSBjYW5ub3QgYmUgbW9y ZSB0aGFuIG9uZSByZWZlcnJlZCBUQiBJRCwgd2hpY2ggaXMgZmluZSBub3csIGJ1dCBub3QgbmVj ZXNzYXJpbHkgZnV0dXJlIHByb29mLg0KVFRSUCBzZWVtcyB0byBub3QgYmUgdmVyc2lvbmVkOyBp Ziwgc2F5LCBUQiAyLjAgdXNlcyBtdWx0aXBsZSByZWZlcnJlZCBiaW5kaW5ncyBwZXIgcmVxdWVz dCwgd2lsbCB3ZSBuZWVkIFRUUlAgMi4wIHdpdGggYWxsIG5ldyBoZWFkZXJzPw0KDQpJdCBzZWVt cyB0aGF0IFRUUlAgbmVlZHMgdG8gYmUgZWl0aGVyIFRCIHZlcnNpb24tc3BlY2lmaWMsIGkuZS4g ZXhwbGljaXRseSBzYXkg4oCcdGhpcyBpcyBmb3IgVEIgMS4wIG9ubHksIGFuZCBmdXR1cmUgVEIg dmVyc2lvbnMgd2lsbCByZXF1aXJlIG5ldyBUVFJQIHNwZWNz4oCdLCBvciBiZSBkZXNpZ25lZCBh cyBhIHBpcGVsaW5lLCBwYXNzaW5nIHdoYXRldmVyIGJpbmRpbmdzIHRoZSBwcm94eSB3YXMgYWJs ZSB0byB2ZXJpZnksIHBvc3NpYmx5IGFsb25nIHdpdGggdGhlIG5lZ290aWF0ZWQgVEIgcHJvdG9j b2wgdmVyc2lvbi4NCg0KU2VjdXJpdHkgYW5kIElBTkEgY29uc2lkZXJhdGlvbnMgbG9vayBnb29k IHRvIG1lLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBVbmJlYXJhYmxlIDx1bmJlYXJh YmxlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDog RnJpZGF5LCBKdW5lIDEsIDIwMTggOTowNyBBTQ0KVG86IExlaWYgSm9oYW5zc29uIDxsZWlmakBt bnQuc2U+DQpDYzogSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtVbmJlYXJhYmxlXSB0b2tiaW5kIC0gTmV3IE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0 IGZvciBJRVRGIDEwMg0KDQpJdCdzIHByZXR0eSBzaG9ydCEgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC10dHJwLTAzPGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcl MkZodG1sJTJGZHJhZnQtaWV0Zi10b2tiaW5kLXR0cnAtMDMmZGF0YT0wMiU3QzAxJTdDQW5kcmVp LlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3Q2JlOWI0NWU1OTQyMjQxMzMwZDA5MDhkNWM3ZDliYmQy JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjYzNDY2MDMz NDEyMzQ0OSZzZGF0YT1tZmw0RFJlQzg0Nk9vUVNkeUp2WFEwVWpNWVk5emVUOEhucDJqYlh2aWlz JTNEJnJlc2VydmVkPTA+DQoNCk9uIEZyaSwgSnVuIDEsIDIwMTggYXQgODozMiBBTSwgTGVpZiBK b2hhbnNzb24gPGxlaWZqQG1udC5zZTxtYWlsdG86bGVpZmpAbW50LnNlPj4gd3JvdGU6DQoNCg0K T24gMjAxOC0wNi0wMSAwMDo0OSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQo+IEknZCBsaWtlIHRv IHJlcXVlc3Qgc29tZSBhZ2VuZGEgdGltZSB0byBjb3ZlciB0aGUgVFRSUCBkcmFmdCwgd2hpY2gg d2lsbA0KPiBsaWtlbHkgY29uc2lzdCBvZiBhbiBvdmVydmlldyBhbmQgc3RhdHVzIHVwZGF0ZSAo d2l0aCBzb21lIGdyYXR1aXRvdXMNCj4gcGhvdG9zIG9mIHJlY2VudCBJRVRGIG1lZXRpbmcgbG9j YXRpb25zKSBhbmQgYSBwbGVhIHRvIG1vdmUgdG93YXJkcw0KPiBXR0xDLiBUaGFua3MhDQoNCklu IG9yZGVyIHRvIGZhY2lsaXRhdGUgdGhhdC4uLiBjb3VsZCB3ZSBnZXQgc29tZSBmb2xrcyB0byBy ZXZpZXcNCnRoZSBUVFJQIGRyYWZ0IGJlZm9yZSAxMDI/DQoNCk1heWJlLi4uIHBsZWFzZS4uLiA/ Pw0KDQogICAgICAgIENoZWVycyBMZWlmDQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhp cyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3 LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29t cHV0ZXIuIFRoYW5rIHlvdS4NCg== --_000_DM5PR21MB050756924C75D2A4CB31826C8C650DM5PR21MB0507namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZG9j dW1lbnQgaXMgd2VsbC13cml0dGVuIGFuZCBjbGVhciwgb3ZlcmFsbC4gSSBoYXZlIGEgZmV3IGVk aXRvcmlhbCBjb21tZW50cyBhbmQgc29tZSBkZXNpZ24gY29tbWVudHM6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyDigJxUb2tlbiBCaW5kaW5nIG92ZXIgSFRUUCBbSS1ELmlldGYtdG9r YmluZC1odHRwc10gcHJvdmlkZXMgYSBtZWNoYW5pc208bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB0aGF0IGVuYWJsZXMgSFRUUCBzZXJ2ZXJzIHRvIGNy eXB0b2dyYXBoaWNhbGx5IGJpbmQgY29va2llcyBhbmQgb3RoZXI8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBzZWN1cml0eSB0b2tlbnMgdG8gYSBrZXkg aGVsZCBieSB0aGUgYnJvd3NlciBvciBvdGhlciBIVFRQIGNsaWVudCw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBwb3NzZXNzaW9uIG9mIHdoaWNoIGlz IHByb3ZlbiBvbiB0aGUgVExTIFtSRkM1MjQ2XSBjb25uZWN0aW9ucyBvdmVyPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgd2hpY2ggdGhlIHRva2VucyBh cmUgdXNlZC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RWRpdG9yaWFsIHN1Z2dlc3Rpb246 IOKAnOKApnRvIGEga2V5IGdlbmVyYXRlZCBieSB0aGUgY2xpZW50LuKAnSBXaGV0aGVyIHRoZSBi cm93c2VyLCBIVFRQIGNsaWVudCwgb3IgdW5kZXJseWluZyBwbGF0Zm9ybSBob2xkIHRoZSBUQiBr ZXkgaXMgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgYW5kIHByb2JhYmx5IHVubmVjZXNzYXJ5IGRl dGFpbCBoZXJlLiBQcm9vZiBvZiBwb3NzZXNzaW9uIGlzIGRpc2N1c3NlZCBpbiB0aGUNCiBuZXh0 IHNlbnRlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg4oCcVGhlIHVzYWdlIG9m IHRoZSBoZWFkZXJzLCBib3RoIHRoZSByZXZlcnNlIHByb3h5IGFkZGluZyBfPGk+aXQ8L2k+XyBh bmQgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg YXBwbGljYXRpb24gc2VydmVyIHVzaW5nIF88aT50aGVtPC9pPl8gdG8gYmluZCBjb29raWVzIG9y IG90aGVyIHRva2VucywgYXJlIHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgYmUgY29uZmlndXJhdGlvbiBvcHRpb25zIG9mIHRoZSByZXNwZWN0aXZl IHN5c3RlbXMgYXMgdGhleSB3aWxsIG5vdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7IGFsd2F5cyBiZSBhcHBsaWNhYmxlLuKAnTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5FZGl0b3JpYWw6IHRoaXMgc2VudGVuY2UgY29uZnVzZXMgbWUsIGVzcC4gYXJv dW5kIOKAnGl04oCdIGFuZCDigJx0aGVt4oCdOyBwZXJoYXBzIGl04oCZcyBwb3NzaWJsZSB0byBz aW1wbGlmeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiAyLjI6IEhhdmluZyB0aHJl ZSBzZXBhcmF0ZSBoZWFkZXJzOiBTZWMtUHJvdmlkZWQsIFNlYy1SZWZlcnJlZCBhbmQgU2VjLU90 aGVyIGNhdGNoLWFsbCB3b3VsZCBub3QgYmUgbXkgZGVzaWduIGNob2ljZS4gSeKAmWQgc3VnZ2Vz dCBlaXRoZXIgb25lIGhlYWRlciB3aXRoIGEgbGlzdCBvZiBhbGwgVEIgSURzLCBvciBhIHNlcGFy YXRlIGhlYWRlciBmb3IgZWFjaCBUQiBJRC4gT2YgY291cnNlLCBpZiBXRw0KIGNvbnNlbnN1cyBl eGlzdHMgb24gdGhlIGN1cnJlbnQgZGVzaWduLCB0aGVuIHRoYXTigJlzIHdoYXQgaXQgaXMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyDigJxCb3RoICZxdW90O1NlYy1Qcm92 aWRlZC1Ub2tlbi1CaW5kaW5nLUlEJnF1b3Q7IGFuZCAmcXVvdDtTZWMtUmVmZXJyZWQtVG9rZW4t QmluZGluZy08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyBJRCZxdW90OyBhcmUgc2luZ2xlIEhUVFAgaGVhZGVyIGZpZWxkLXZhbHVlZOKApuKAnTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21ld2hhdCByZWxhdGVkIHRvIHRoZSBwcmV2aW91cyBjb21t ZW50OiB0aGlzIHNlZW1zIHRvIGJlIHNheWluZyB0aGF0IHRoZXJlIGNhbm5vdCBiZSBtb3JlIHRo YW4gb25lIHJlZmVycmVkIFRCIElELCB3aGljaCBpcyBmaW5lIG5vdywgYnV0IG5vdCBuZWNlc3Nh cmlseSBmdXR1cmUgcHJvb2YuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U VFJQIHNlZW1zIHRvIG5vdCBiZSB2ZXJzaW9uZWQ7IGlmLCBzYXksIFRCIDIuMCB1c2VzIG11bHRp cGxlIHJlZmVycmVkIGJpbmRpbmdzIHBlciByZXF1ZXN0LCB3aWxsIHdlIG5lZWQgVFRSUCAyLjAg d2l0aCBhbGwgbmV3IGhlYWRlcnM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNlZW1zIHRo YXQgVFRSUCBuZWVkcyB0byBiZSBlaXRoZXIgVEIgdmVyc2lvbi1zcGVjaWZpYywgaS5lLiBleHBs aWNpdGx5IHNheSDigJx0aGlzIGlzIGZvciBUQiAxLjAgb25seSwgYW5kIGZ1dHVyZSBUQiB2ZXJz aW9ucyB3aWxsIHJlcXVpcmUgbmV3IFRUUlAgc3BlY3PigJ0sIG9yIGJlIGRlc2lnbmVkIGFzIGEg cGlwZWxpbmUsIHBhc3Npbmcgd2hhdGV2ZXIgYmluZGluZ3MgdGhlIHByb3h5IHdhcyBhYmxlIHRv DQogdmVyaWZ5LCBwb3NzaWJseSBhbG9uZyB3aXRoIHRoZSBuZWdvdGlhdGVkIFRCIHByb3RvY29s IHZlcnNpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3VyaXR5IGFuZCBJQU5BIGNvbnNp ZGVyYXRpb25zIGxvb2sgZ29vZCB0byBtZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJz LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmRyZWk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+RnJvbTo8L2I+IFVuYmVhcmFibGUgJmx0O3VuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZyZn dDsgPGI+T24gQmVoYWxmIE9mDQo8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4g RnJpZGF5LCBKdW5lIDEsIDIwMTggOTowNyBBTTxicj4NCjxiPlRvOjwvYj4gTGVpZiBKb2hhbnNz b24gJmx0O2xlaWZqQG1udC5zZSZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgVG9rYmluZCBXRyAm bHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJl YXJhYmxlXSB0b2tiaW5kIC0gTmV3IE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0IGZvciBJRVRGIDEw MjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0J3MgcHJldHR5IHNob3J0 ISA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtdG9r YmluZC10dHJwLTAzJmFtcDtkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQu Y29tJTdDYmU5YjQ1ZTU5NDIyNDEzMzBkMDkwOGQ1YzdkOWJiZDIlN0M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjM0NjYwMzM0MTIzNDQ5JmFtcDtzZGF0YT1t Zmw0RFJlQzg0Nk9vUVNkeUp2WFEwVWpNWVk5emVUOEhucDJqYlh2aWlzJTNEJmFtcDtyZXNlcnZl ZD0wIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtdHRy cC0wMzwvYT4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEZyaSwgSnVuIDEsIDIwMTggYXQgODozMiBBTSwgTGVpZiBKb2hhbnNzb24gJmx0 OzxhIGhyZWY9Im1haWx0bzpsZWlmakBtbnQuc2UiIHRhcmdldD0iX2JsYW5rIj5sZWlmakBtbnQu c2U8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiAyMDE4LTA2LTAxIDAwOjQ5LCBCcmlhbiBDYW1wYmVs bCB3cm90ZTo8YnI+DQomZ3Q7IEknZCBsaWtlIHRvIHJlcXVlc3Qgc29tZSBhZ2VuZGEgdGltZSB0 byBjb3ZlciB0aGUgVFRSUCBkcmFmdCwgd2hpY2ggd2lsbDxicj4NCiZndDsgbGlrZWx5IGNvbnNp c3Qgb2YgYW4mbmJzcDtvdmVydmlldyBhbmQgc3RhdHVzIHVwZGF0ZSAod2l0aCBzb21lIGdyYXR1 aXRvdXM8YnI+DQomZ3Q7IHBob3RvcyBvZiByZWNlbnQgSUVURiBtZWV0aW5nIGxvY2F0aW9ucykg YW5kIGEgcGxlYSB0byBtb3ZlIHRvd2FyZHM8YnI+DQomZ3Q7IFdHTEMuIFRoYW5rcyE8YnI+DQo8 YnI+DQpJbiBvcmRlciB0byBmYWNpbGl0YXRlIHRoYXQuLi4gY291bGQgd2UgZ2V0IHNvbWUgZm9s a3MgdG8gcmV2aWV3PGJyPg0KdGhlIFRUUlAgZHJhZnQgYmVmb3JlIDEwMj88YnI+DQo8YnI+DQpN YXliZS4uLiBwbGVhc2UuLi4gPz88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgQ2hlZXJzIExlaWY8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTti b3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkg Tk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdl ZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyku DQogQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg Y29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2ht ZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR21MB050756924C75D2A4CB31826C8C650DM5PR21MB0507namp_-- From nobody Thu Jun 7 12:09:34 2018 Return-Path: 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 0D7FF131158 for ; Thu, 7 Jun 2018 12:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 I9tjSqyF_RCA for ; Thu, 7 Jun 2018 12:09:24 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995DD130FCB for ; Thu, 7 Jun 2018 12:09:24 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id j186-v6so13997213ita.5 for ; Thu, 07 Jun 2018 12:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IV3kopxHp3DunCf+br6osShF3LOg63udpSyaRx0Uds0=; b=L/Ubq6Pa1X6J+Fp5t7krj7R4MsnO2kfpV6G0AXuPFelyN3YbP2c41vJxyFK/kEo5eM moUF8TLK8/aQV2E17cwmwPUf4n8/Et90qrMfBDeB8gZBatuuEey+Y9Lxs4aU4C335mLP Wv8VkYoTtKh7MtkISqMD7YbQy0W1A0ZkQuZyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IV3kopxHp3DunCf+br6osShF3LOg63udpSyaRx0Uds0=; b=SfxjCt3O8fm11kiqEHvrU9EGum9KlOzi2uCddr31grw1DRemrtlNeMbD2SohtNTO7S LRdsTiG43Y2nb2Ef1Z0a9PzhMAGXAj4hhtwVzjh0oSz3sVeeFgiSN+QKAQUbgwb4BJpc +946lws6AqbkmXcRp3QxRASJFAjJ9cA5c7n/OOZ3Bz1RG8Ld0Ad8jT6898HzevuJiSCX xfNu9j7yELsydh2LnhUttdFIRl7tFXlHg3Kc09X1txPn7hjwPrJgf1Lc+q/Se+iRyTQ4 HvQJMOg39M56eQm93lLs0O3WjRGNltnLvtk0cM1cFaPxY4Yqt1HldKzp2nETvrsb8OWW mM9g== X-Gm-Message-State: APt69E1UGr7ZwcsDbNEbIBTNlFWbIsspZ97eCcipE2GXkCMAEenxamfh m9Ly+QGnjH91g5ZWHkeUqMVZzQIjga20AvQbeKvGuFjrd1H1/j0hjw8xFQ1tPIaLGKoDMSDNW8/ 02HtFJkiEchJObmkRXPYU X-Google-Smtp-Source: ADUXVKJ6j1TXNuHu7M+Xv56dQFQVwyQ71zWaa+JjeEpae06Rg0mC6ZJA6HWKobV2h/v5x5yzaZsQPhV2UBHImzPep4c= X-Received: by 2002:a24:641:: with SMTP id 62-v6mr2894206itv.89.1528398563583; Thu, 07 Jun 2018 12:09:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 12:08:52 -0700 (PDT) In-Reply-To: References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> From: Brian Campbell Date: Thu, 7 Jun 2018 13:08:52 -0600 Message-ID: To: Andrei Popov Cc: Leif Johansson , IETF Tokbind WG Content-Type: multipart/alternative; boundary="0000000000007548cb056e1205a8" Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 19:09:32 -0000 --0000000000007548cb056e1205a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review, Andrei. I'll incorporate the editorial suggestions. The design choice of having distinct Sec-Provided and Sec-Referred headers was intentional and aimed at making the most common cases simple at the application layer dealing with HTTP. The vast majority of the time there's going to be only the Provided and a single header that carries that value unadorned makes accessing that very straightforward. Referred is the other defined type with defined usage in HTTPSTB so TTRP has Sec-Referred for that. Then there are 254 other undefined types and there was a request from the WG (or a portion thereof) to allow for them somehow. A separate header for every one of them seemed prohibitive to say the least. That's where the Sec-Other catch-all comes from. There are trade-offs any design choice and this is a bit of a hybrid but I feel it strikes a good balance of simplicity for the common defined cases while still accommodating others. Gauging WG consensus isn't particularity easy in this WG at this stage but in my mind consensus is there. This would, of course, be a good time for the WG to speak up to indicate otherwise, if that's not the case. Nothing is future proof. TTRP is intended to facilitate deployments of HTTPSTB. HTTPSTB isn't future proof or versioned and would need to change to allow for more than one referred TB ID. Saying TTRP will work only with a specific version may or may not prove true. And passing along the negotiated TB protocol version may or may not accommodate future changes. Future TB protocol versions may or may not even happen. The single HTTP header field-valued text was largely put in there with the hope/expectation that it would ease the registration process (after Jeff suggested something similar for the Sec-Token-Binding header, IIRC). But also because it was inline with the "exactly one" restriction in HTTPSTB. But that text could easily be removed, I think. On Wed, Jun 6, 2018 at 12:51 PM, Andrei Popov < Andrei.Popov=3D40microsoft.com@dmarc.ietf.org> wrote: > The document is well-written and clear, overall. I have a few editorial > comments and some design comments: > > > > =E2=80=9CToken Binding over HTTP [I-D.ietf-tokbind-https] provides a me= chanism > > that enables HTTP servers to cryptographically bind cookies and other > > security tokens to a key held by the browser or other HTTP client, > > possession of which is proven on the TLS [RFC5246] connections over > > which the tokens are used.=E2=80=9D > > > > Editorial suggestion: =E2=80=9C=E2=80=A6to a key generated by the client.= =E2=80=9D Whether the > browser, HTTP client, or underlying platform hold the TB key is > implementation-specific and probably unnecessary detail here. Proof of > possession is discussed in the next sentence. > > > > =E2=80=9CThe usage of the headers, both the reverse proxy adding _*it*_= and the > > application server using _*them*_ to bind cookies or other tokens, are > to > > be configuration options of the respective systems as they will not > > always be applicable.=E2=80=9D > > > > Editorial: this sentence confuses me, esp. around =E2=80=9Cit=E2=80=9D an= d =E2=80=9Cthem=E2=80=9D; perhaps > it=E2=80=99s possible to simplify. > > > > Section 2.2: Having three separate headers: Sec-Provided, Sec-Referred an= d > Sec-Other catch-all would not be my design choice. I=E2=80=99d suggest ei= ther one > header with a list of all TB IDs, or a separate header for each TB ID. Of > course, if WG consensus exists on the current design, then that=E2=80=99s= what it > is. > > > > =E2=80=9CBoth "Sec-Provided-Token-Binding-ID" and "Sec-Referred-Token-= Binding- > > ID" are single HTTP header field-valued=E2=80=A6=E2=80=9D > > > > Somewhat related to the previous comment: this seems to be saying that > there cannot be more than one referred TB ID, which is fine now, but not > necessarily future proof. > > TTRP seems to not be versioned; if, say, TB 2.0 uses multiple referred > bindings per request, will we need TTRP 2.0 with all new headers? > > > > It seems that TTRP needs to be either TB version-specific, i.e. explicitl= y > say =E2=80=9Cthis is for TB 1.0 only, and future TB versions will require= new TTRP > specs=E2=80=9D, or be designed as a pipeline, passing whatever bindings t= he proxy > was able to verify, possibly along with the negotiated TB protocol versio= n. > > > > Security and IANA considerations look good to me. > > > > Cheers, > > > > Andrei > > > > *From:* Unbearable *On Behalf Of *Brian > Campbell > *Sent:* Friday, June 1, 2018 9:07 AM > *To:* Leif Johansson > *Cc:* IETF Tokbind WG > *Subject:* Re: [Unbearable] tokbind - New Meeting Session Request for > IETF 102 > > > > It's pretty short! https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-03 > > > > > On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson wrote: > > > > On 2018-06-01 00:49, Brian Campbell wrote: > > I'd like to request some agenda time to cover the TTRP draft, which wil= l > > likely consist of an overview and status update (with some gratuitous > > photos of recent IETF meeting locations) and a plea to move towards > > WGLC. Thanks! > > In order to facilitate that... could we get some folks to review > the TTRP draft before 102? > > Maybe... please... ?? > > Cheers Leif > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000007548cb056e1205a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, Andrei.
I'll incorporate the editorial suggestions.

The design choice of having distinct Sec-Provided and Sec-R= eferred headers was intentional and aimed at making the most common cases s= imple at the application layer dealing with HTTP. The vast majority of the = time there's going to be only the=C2=A0Provided and a single header tha= t carries that value unadorned makes accessing that very straightforward.= =C2=A0 Referred is the other defined type with defined usage in HTTPSTB so = TTRP has Sec-Referred for that. Then there are 254 other undefined types an= d there was a request from the WG (or a portion thereof) to allow for them = somehow. A separate header for every one of them seemed prohibitive to say = the least. That's where the Sec-Other catch-all comes from. There are = trade-offs any design choice and this is a bit of a hybrid but I feel it st= rikes a good balance of simplicity for the common defined cases while still= accommodating others. Gauging WG consensus isn't particularity easy in= this WG at this stage but in my mind consensus is there. This would, of co= urse, be a good time for the WG to speak up to indicate otherwise, if that&= #39;s not the case.

Nothing is future proof. TTRP = is intended to facilitate deployments of HTTPSTB. HTTPSTB isn't future = proof or versioned and would need to change to allow for more than one refe= rred TB ID. Saying TTRP will work only with a specific version may or may n= ot prove true. And passing along the negotiated TB protocol version may or = may not accommodate future changes. Future TB protocol versions may or may = not even happen.

The single HTTP header field= -valued text was largely put in there with the hope/expectation that it wou= ld ease the registration process (after Jeff suggested something similar fo= r the Sec-Token-Binding header, IIRC). But also because it was inline with = the "exactly one" restriction in HTTPSTB. But that text could eas= ily be removed, I think.



On Wed, Jun 6, 2018 at 12:51 PM,= Andrei Popov <Andrei.Popov=3D40microsoft.com@= dmarc.ietf.org> wrote:

The document is well-written and clear, overall. I h= ave a few editorial comments and some design comments:

=C2=A0

=C2=A0 =E2=80=9CToken Binding over HTTP [I-D.ietf-to= kbind-https] provides a mechanism

=C2=A0=C2=A0 that enables HTTP servers to cryptograp= hically bind cookies and other

=C2=A0=C2=A0 security tokens to a key held by the br= owser or other HTTP client,

=C2=A0=C2=A0 possession of which is proven on the TL= S [RFC5246] connections over

=C2=A0=C2=A0 which the tokens are used.=E2=80=9D<= /u>

=C2=A0

Editorial suggestion: =E2=80=9C=E2=80=A6to a key gen= erated by the client.=E2=80=9D Whether the browser, HTTP client, or underly= ing platform hold the TB key is implementation-specific and probably unnece= ssary detail here. Proof of possession is discussed in the next sentence.

=C2=A0

=C2=A0 =E2=80=9CThe usage of the headers, both the r= everse proxy adding _it_ and the

=C2=A0=C2=A0 application server using _them_ = to bind cookies or other tokens, are to

=C2=A0=C2=A0 be configuration options of the respect= ive systems as they will not

=C2=A0=C2=A0 always be applicable.=E2=80=9D

=C2=A0

Editorial: this sentence confuses me, esp. around = =E2=80=9Cit=E2=80=9D and =E2=80=9Cthem=E2=80=9D; perhaps it=E2=80=99s possi= ble to simplify.

=C2=A0

Section 2.2: Having three separate headers: Sec-Prov= ided, Sec-Referred and Sec-Other catch-all would not be my design choice. I= =E2=80=99d suggest either one header with a list of all TB IDs, or a separa= te header for each TB ID. Of course, if WG consensus exists on the current design, then that=E2=80=99s what it is.=

=C2=A0

=C2=A0=C2=A0 =E2=80=9CBoth "Sec-Provided-Token-= Binding-ID" and "Sec-Referred-Token-Binding-

=C2=A0=C2=A0 ID" are single HTTP header field-v= alued=E2=80=A6=E2=80=9D

=C2=A0

Somewhat related to the previous comment: this seems= to be saying that there cannot be more than one referred TB ID, which is f= ine now, but not necessarily future proof.

TTRP seems to not be versioned; if, say, TB 2.0 uses= multiple referred bindings per request, will we need TTRP 2.0 with all new= headers?

=C2=A0

It seems that TTRP needs to be either TB version-spe= cific, i.e. explicitly say =E2=80=9Cthis is for TB 1.0 only, and future TB = versions will require new TTRP specs=E2=80=9D, or be designed as a pipeline= , passing whatever bindings the proxy was able to verify, possibly along with the negotiated TB protocol version.<= /u>

=C2=A0

Security and IANA considerations look good to me.=

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable <unbearable-bounce= s@ietf.org> On Behalf Of Brian Campbell
Sent: Friday, June 1, 2018 9:07 AM
To: Leif Johansson <leifj@mnt.se>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for = IETF 102

=C2=A0

=C2=A0

On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson <<= a href=3D"mailto:leifj@mnt.se" target=3D"_blank">leifj@mnt.se> wrote= :



On 2018-06-01 00:49, Brian Campbell wrote:
> I'd like to request some agenda time to cover the TTRP draft, whic= h will
> likely consist of an=C2=A0overview and status update (with some gratui= tous
> photos of recent IETF meeting locations) and a plea to move towards > WGLC. Thanks!

In order to facilitate that... could we get some folks to review
the TTRP draft before 102?

Maybe... please... ??

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif

=C2=A0


CONFIDENTIAL= ITY NOTICE: This email may contain confidential and privileged material for= the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed..=C2=A0 If you have received this communication in error, please notify = the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000007548cb056e1205a8-- From nobody Thu Jun 7 14:58:41 2018 Return-Path: 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 394CE130DDB for ; Thu, 7 Jun 2018 14:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 vhhE6SbrcoOx for ; Thu, 7 Jun 2018 14:58:29 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0118.outbound.protection.outlook.com [104.47.32.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F4C130DD7 for ; Thu, 7 Jun 2018 14:58:29 -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:X-MS-Exchange-SenderADCheck; bh=qKbSzkp0fFOuAI0FViOPM3eECNLn2McCT5wKvuWZt2U=; b=SVQIK717NZyEqT7thYuW9BkhrPryIhgpndAFKgjZ/MZQXUXHpoCXxJqb3GkgS6Ew6iwjYXMYbgLUYtOBkKbHkit7Lue6qdo7erfTmR8kt1YanJO1tbdoyFaDj7AHlA5aqWS2B0vGkgLCAUR6zQDy+aMGUegXJyzwXvv9uq7/NXo= Received: from DM5PR21MB0507.namprd21.prod.outlook.com (10.172.91.141) by DM5PR21MB0138.namprd21.prod.outlook.com (10.173.173.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.2; Thu, 7 Jun 2018 21:58:27 +0000 Received: from DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::7cac:8247:7a46:1bfd]) by DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::7cac:8247:7a46:1bfd%16]) with mapi id 15.20.0863.004; Thu, 7 Jun 2018 21:58:27 +0000 From: Andrei Popov To: Brian Campbell CC: Leif Johansson , IETF Tokbind WG Thread-Topic: [Unbearable] tokbind - New Meeting Session Request for IETF 102 Thread-Index: AQHT+KcSOfkm5RG+C024j4aQmtNOyqRJXiAAgAETswCAAQehAIAAGkEAgAVCOXCABF61AIAAKsKg Date: Thu, 7 Jun 2018 21:58:26 +0000 Message-ID: References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:9:28b4:a023:971b:e42c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0138; 7:JqfFq10SaZAMMGKvT0XX2wlvCzLMMJgXbfWvpMLcc9by3Xr9WP/+dMK2iUvXqhIJcdiOhco1zZcA8hXsBSQWAMNeMFw+xlM4gxc5+z453IIie2oojoiMaA1qI2e030EKKO/fmyJz98kG8oktXG6kIWiFmsFRPN/BkkNoMEyLUpFDXYCd2DdGrK7ZEzuvkVaZikBSG07dG8aSBjcZ2wfhTXgyjm4aA9EAMwV4evdcBh+ZF2qeyyXZe1O7BpugWu5u x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR21MB0138; x-ms-traffictypediagnostic: DM5PR21MB0138: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(192374486261705)(189930954265078)(100405760836317)(219752817060721)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(2018427008)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DM5PR21MB0138; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0138; x-forefront-prvs: 06968FD8C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(366004)(39380400002)(376002)(199004)(189003)(51914003)(8676002)(10290500003)(8936002)(476003)(54906003)(7736002)(606006)(99286004)(74316002)(1600100001)(6246003)(316002)(22452003)(97736004)(81156014)(2900100001)(790700001)(6116002)(93886005)(81166006)(9686003)(5250100002)(236005)(53936002)(6306002)(5660300001)(59450400001)(186003)(55016002)(6436002)(10090500001)(102836004)(54896002)(86612001)(53546011)(6506007)(7696005)(76176011)(33656002)(11346002)(446003)(3280700002)(229853002)(486006)(5890100001)(966005)(14454004)(4326008)(68736007)(106356001)(8990500004)(105586002)(2906002)(3660700001)(478600001)(46003)(86362001)(25786009)(72206003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0138; 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) x-microsoft-antispam-message-info: ry+kmTsZOb7ICebnq8OLfBlppA4s2hwWo2YuOt2uCkuXCWSZuIUjPbePOReDMDqVktI54owCxztsGETOuFIddshvo3tTxgdKUPIww6jzPJ5gW21sCoQCBoQBW4FjhkRV0GRykgb9qNw8AKsd/hZebXQfx/3I50zkfWxCQKgzwSijj4HLKZU9PAGGDNetq3Xy spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR21MB0507D809A381912B03CDEB3C8C640DM5PR21MB0507namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 2194c627-77b9-4b17-a268-08d5ccc1cc55 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2194c627-77b9-4b17-a268-08d5ccc1cc55 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2018 21:58:27.0230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0138 Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 21:58:38 -0000 --_000_DM5PR21MB0507D809A381912B03CDEB3C8C640DM5PR21MB0507namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgR2F1Z2luZyBXRyBjb25zZW5zdXMgaXNuJ3QgcGFydGljdWxhcml0eSBlYXN5IGluIHRo aXMgV0cgYXQgdGhpcyBzdGFnZSBidXQgaW4gbXkgbWluZCBjb25zZW5zdXMgaXMgdGhlcmUuDQpP dXIgYXdlc29tZSBDaGFpcnMgY2FuIHByb2JhYmx5IGhlbHAgY29uZmlybSBvbmUgd2F5IG9yIHRo ZSBvdGhlci4NCg0KDQogICogICBOb3RoaW5nIGlzIGZ1dHVyZSBwcm9vZi4NCiAgKiAgIFNheWlu ZyBUVFJQIHdpbGwgd29yayBvbmx5IHdpdGggYSBzcGVjaWZpYyB2ZXJzaW9uIG1heSBvciBtYXkg bm90IHByb3ZlIHRydWUuDQpTdXJlLiBKdXN0IHRyeWluZyB0byB1bmRlcnN0YW5kIHdoYXQgdGhl IHRoaW5raW5nIGlzOiBpZiBUVFJQIGlzIG5vdCBzdXBwb3J0YWJsZSB3aXRoIFRCIFgsIHdl4oCZ bGwganVzdCBzYXkg4oCcZG9u4oCZdCB1c2UgVFRSUCB3aXRoIFRCIFgsIHVzZSBUVFJQYmlzIGlu c3RlYWTigJ0/DQpBbmQgVFRSUGJpcyB3aWxsIHByb2JhYmx5IGRlZmluZSBzb21lIG5ldyBoZWFk ZXJzPw0KDQpGcm9tOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNv bUBkbWFyYy5pZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDcsIDIwMTggMTI6MDkgUE0N ClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IExlaWYg Sm9oYW5zc29uIDxsZWlmakBtbnQuc2U+OyBJRVRGIFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIHRva2JpbmQgLSBOZXcgTWVldGluZyBT ZXNzaW9uIFJlcXVlc3QgZm9yIElFVEYgMTAyDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldywgQW5k cmVpLg0KDQpJJ2xsIGluY29ycG9yYXRlIHRoZSBlZGl0b3JpYWwgc3VnZ2VzdGlvbnMuDQoNClRo ZSBkZXNpZ24gY2hvaWNlIG9mIGhhdmluZyBkaXN0aW5jdCBTZWMtUHJvdmlkZWQgYW5kIFNlYy1S ZWZlcnJlZCBoZWFkZXJzIHdhcyBpbnRlbnRpb25hbCBhbmQgYWltZWQgYXQgbWFraW5nIHRoZSBt b3N0IGNvbW1vbiBjYXNlcyBzaW1wbGUgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIGRlYWxpbmcg d2l0aCBIVFRQLiBUaGUgdmFzdCBtYWpvcml0eSBvZiB0aGUgdGltZSB0aGVyZSdzIGdvaW5nIHRv IGJlIG9ubHkgdGhlIFByb3ZpZGVkIGFuZCBhIHNpbmdsZSBoZWFkZXIgdGhhdCBjYXJyaWVzIHRo YXQgdmFsdWUgdW5hZG9ybmVkIG1ha2VzIGFjY2Vzc2luZyB0aGF0IHZlcnkgc3RyYWlnaHRmb3J3 YXJkLiAgUmVmZXJyZWQgaXMgdGhlIG90aGVyIGRlZmluZWQgdHlwZSB3aXRoIGRlZmluZWQgdXNh Z2UgaW4gSFRUUFNUQiBzbyBUVFJQIGhhcyBTZWMtUmVmZXJyZWQgZm9yIHRoYXQuIFRoZW4gdGhl cmUgYXJlIDI1NCBvdGhlciB1bmRlZmluZWQgdHlwZXMgYW5kIHRoZXJlIHdhcyBhIHJlcXVlc3Qg ZnJvbSB0aGUgV0cgKG9yIGEgcG9ydGlvbiB0aGVyZW9mKSB0byBhbGxvdyBmb3IgdGhlbSBzb21l aG93LiBBIHNlcGFyYXRlIGhlYWRlciBmb3IgZXZlcnkgb25lIG9mIHRoZW0gc2VlbWVkIHByb2hp Yml0aXZlIHRvIHNheSB0aGUgbGVhc3QuIFRoYXQncyB3aGVyZSB0aGUgU2VjLU90aGVyIGNhdGNo LWFsbCBjb21lcyBmcm9tLiBUaGVyZSBhcmUgdHJhZGUtb2ZmcyBhbnkgZGVzaWduIGNob2ljZSBh bmQgdGhpcyBpcyBhIGJpdCBvZiBhIGh5YnJpZCBidXQgSSBmZWVsIGl0IHN0cmlrZXMgYSBnb29k IGJhbGFuY2Ugb2Ygc2ltcGxpY2l0eSBmb3IgdGhlIGNvbW1vbiBkZWZpbmVkIGNhc2VzIHdoaWxl IHN0aWxsIGFjY29tbW9kYXRpbmcgb3RoZXJzLiBHYXVnaW5nIFdHIGNvbnNlbnN1cyBpc24ndCBw YXJ0aWN1bGFyaXR5IGVhc3kgaW4gdGhpcyBXRyBhdCB0aGlzIHN0YWdlIGJ1dCBpbiBteSBtaW5k IGNvbnNlbnN1cyBpcyB0aGVyZS4gVGhpcyB3b3VsZCwgb2YgY291cnNlLCBiZSBhIGdvb2QgdGlt ZSBmb3IgdGhlIFdHIHRvIHNwZWFrIHVwIHRvIGluZGljYXRlIG90aGVyd2lzZSwgaWYgdGhhdCdz IG5vdCB0aGUgY2FzZS4NCg0KTm90aGluZyBpcyBmdXR1cmUgcHJvb2YuIFRUUlAgaXMgaW50ZW5k ZWQgdG8gZmFjaWxpdGF0ZSBkZXBsb3ltZW50cyBvZiBIVFRQU1RCLiBIVFRQU1RCIGlzbid0IGZ1 dHVyZSBwcm9vZiBvciB2ZXJzaW9uZWQgYW5kIHdvdWxkIG5lZWQgdG8gY2hhbmdlIHRvIGFsbG93 IGZvciBtb3JlIHRoYW4gb25lIHJlZmVycmVkIFRCIElELiBTYXlpbmcgVFRSUCB3aWxsIHdvcmsg b25seSB3aXRoIGEgc3BlY2lmaWMgdmVyc2lvbiBtYXkgb3IgbWF5IG5vdCBwcm92ZSB0cnVlLiBB bmQgcGFzc2luZyBhbG9uZyB0aGUgbmVnb3RpYXRlZCBUQiBwcm90b2NvbCB2ZXJzaW9uIG1heSBv ciBtYXkgbm90IGFjY29tbW9kYXRlIGZ1dHVyZSBjaGFuZ2VzLiBGdXR1cmUgVEIgcHJvdG9jb2wg dmVyc2lvbnMgbWF5IG9yIG1heSBub3QgZXZlbiBoYXBwZW4uDQoNClRoZSBzaW5nbGUgSFRUUCBo ZWFkZXIgZmllbGQtdmFsdWVkIHRleHQgd2FzIGxhcmdlbHkgcHV0IGluIHRoZXJlIHdpdGggdGhl IGhvcGUvZXhwZWN0YXRpb24gdGhhdCBpdCB3b3VsZCBlYXNlIHRoZSByZWdpc3RyYXRpb24gcHJv Y2VzcyAoYWZ0ZXIgSmVmZiBzdWdnZXN0ZWQgc29tZXRoaW5nIHNpbWlsYXIgZm9yIHRoZSBTZWMt VG9rZW4tQmluZGluZyBoZWFkZXIsIElJUkMpLiBCdXQgYWxzbyBiZWNhdXNlIGl0IHdhcyBpbmxp bmUgd2l0aCB0aGUgImV4YWN0bHkgb25lIiByZXN0cmljdGlvbiBpbiBIVFRQU1RCLiBCdXQgdGhh dCB0ZXh0IGNvdWxkIGVhc2lseSBiZSByZW1vdmVkLCBJIHRoaW5rLg0KDQoNCg0KT24gV2VkLCBK dW4gNiwgMjAxOCBhdCAxMjo1MSBQTSwgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3Y9NDBtaWNy b3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpBbmRyZWkuUG9wb3Y9NDBtaWNyb3NvZnQu Y29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpUaGUgZG9jdW1lbnQgaXMgd2VsbC13cml0dGVu IGFuZCBjbGVhciwgb3ZlcmFsbC4gSSBoYXZlIGEgZmV3IGVkaXRvcmlhbCBjb21tZW50cyBhbmQg c29tZSBkZXNpZ24gY29tbWVudHM6DQoNCiAg4oCcVG9rZW4gQmluZGluZyBvdmVyIEhUVFAgW0kt RC5pZXRmLXRva2JpbmQtaHR0cHNdIHByb3ZpZGVzIGEgbWVjaGFuaXNtDQogICB0aGF0IGVuYWJs ZXMgSFRUUCBzZXJ2ZXJzIHRvIGNyeXB0b2dyYXBoaWNhbGx5IGJpbmQgY29va2llcyBhbmQgb3Ro ZXINCiAgIHNlY3VyaXR5IHRva2VucyB0byBhIGtleSBoZWxkIGJ5IHRoZSBicm93c2VyIG9yIG90 aGVyIEhUVFAgY2xpZW50LA0KICAgcG9zc2Vzc2lvbiBvZiB3aGljaCBpcyBwcm92ZW4gb24gdGhl IFRMUyBbUkZDNTI0Nl0gY29ubmVjdGlvbnMgb3Zlcg0KICAgd2hpY2ggdGhlIHRva2VucyBhcmUg dXNlZC7igJ0NCg0KRWRpdG9yaWFsIHN1Z2dlc3Rpb246IOKAnOKApnRvIGEga2V5IGdlbmVyYXRl ZCBieSB0aGUgY2xpZW50LuKAnSBXaGV0aGVyIHRoZSBicm93c2VyLCBIVFRQIGNsaWVudCwgb3Ig dW5kZXJseWluZyBwbGF0Zm9ybSBob2xkIHRoZSBUQiBrZXkgaXMgaW1wbGVtZW50YXRpb24tc3Bl Y2lmaWMgYW5kIHByb2JhYmx5IHVubmVjZXNzYXJ5IGRldGFpbCBoZXJlLiBQcm9vZiBvZiBwb3Nz ZXNzaW9uIGlzIGRpc2N1c3NlZCBpbiB0aGUgbmV4dCBzZW50ZW5jZS4NCg0KICDigJxUaGUgdXNh Z2Ugb2YgdGhlIGhlYWRlcnMsIGJvdGggdGhlIHJldmVyc2UgcHJveHkgYWRkaW5nIF9pdF8gYW5k IHRoZQ0KICAgYXBwbGljYXRpb24gc2VydmVyIHVzaW5nIF90aGVtXyB0byBiaW5kIGNvb2tpZXMg b3Igb3RoZXIgdG9rZW5zLCBhcmUgdG8NCiAgIGJlIGNvbmZpZ3VyYXRpb24gb3B0aW9ucyBvZiB0 aGUgcmVzcGVjdGl2ZSBzeXN0ZW1zIGFzIHRoZXkgd2lsbCBub3QNCiAgIGFsd2F5cyBiZSBhcHBs aWNhYmxlLuKAnQ0KDQpFZGl0b3JpYWw6IHRoaXMgc2VudGVuY2UgY29uZnVzZXMgbWUsIGVzcC4g YXJvdW5kIOKAnGl04oCdIGFuZCDigJx0aGVt4oCdOyBwZXJoYXBzIGl04oCZcyBwb3NzaWJsZSB0 byBzaW1wbGlmeS4NCg0KU2VjdGlvbiAyLjI6IEhhdmluZyB0aHJlZSBzZXBhcmF0ZSBoZWFkZXJz OiBTZWMtUHJvdmlkZWQsIFNlYy1SZWZlcnJlZCBhbmQgU2VjLU90aGVyIGNhdGNoLWFsbCB3b3Vs ZCBub3QgYmUgbXkgZGVzaWduIGNob2ljZS4gSeKAmWQgc3VnZ2VzdCBlaXRoZXIgb25lIGhlYWRl ciB3aXRoIGEgbGlzdCBvZiBhbGwgVEIgSURzLCBvciBhIHNlcGFyYXRlIGhlYWRlciBmb3IgZWFj aCBUQiBJRC4gT2YgY291cnNlLCBpZiBXRyBjb25zZW5zdXMgZXhpc3RzIG9uIHRoZSBjdXJyZW50 IGRlc2lnbiwgdGhlbiB0aGF04oCZcyB3aGF0IGl0IGlzLg0KDQogICDigJxCb3RoICJTZWMtUHJv dmlkZWQtVG9rZW4tQmluZGluZy1JRCIgYW5kICJTZWMtUmVmZXJyZWQtVG9rZW4tQmluZGluZy0N CiAgIElEIiBhcmUgc2luZ2xlIEhUVFAgaGVhZGVyIGZpZWxkLXZhbHVlZOKApuKAnQ0KDQpTb21l d2hhdCByZWxhdGVkIHRvIHRoZSBwcmV2aW91cyBjb21tZW50OiB0aGlzIHNlZW1zIHRvIGJlIHNh eWluZyB0aGF0IHRoZXJlIGNhbm5vdCBiZSBtb3JlIHRoYW4gb25lIHJlZmVycmVkIFRCIElELCB3 aGljaCBpcyBmaW5lIG5vdywgYnV0IG5vdCBuZWNlc3NhcmlseSBmdXR1cmUgcHJvb2YuDQpUVFJQ IHNlZW1zIHRvIG5vdCBiZSB2ZXJzaW9uZWQ7IGlmLCBzYXksIFRCIDIuMCB1c2VzIG11bHRpcGxl IHJlZmVycmVkIGJpbmRpbmdzIHBlciByZXF1ZXN0LCB3aWxsIHdlIG5lZWQgVFRSUCAyLjAgd2l0 aCBhbGwgbmV3IGhlYWRlcnM/DQoNCkl0IHNlZW1zIHRoYXQgVFRSUCBuZWVkcyB0byBiZSBlaXRo ZXIgVEIgdmVyc2lvbi1zcGVjaWZpYywgaS5lLiBleHBsaWNpdGx5IHNheSDigJx0aGlzIGlzIGZv ciBUQiAxLjAgb25seSwgYW5kIGZ1dHVyZSBUQiB2ZXJzaW9ucyB3aWxsIHJlcXVpcmUgbmV3IFRU UlAgc3BlY3PigJ0sIG9yIGJlIGRlc2lnbmVkIGFzIGEgcGlwZWxpbmUsIHBhc3Npbmcgd2hhdGV2 ZXIgYmluZGluZ3MgdGhlIHByb3h5IHdhcyBhYmxlIHRvIHZlcmlmeSwgcG9zc2libHkgYWxvbmcg d2l0aCB0aGUgbmVnb3RpYXRlZCBUQiBwcm90b2NvbCB2ZXJzaW9uLg0KDQpTZWN1cml0eSBhbmQg SUFOQSBjb25zaWRlcmF0aW9ucyBsb29rIGdvb2QgdG8gbWUuDQoNCkNoZWVycywNCg0KQW5kcmVp DQoNCkZyb206IFVuYmVhcmFibGUgPHVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxs DQpTZW50OiBGcmlkYXksIEp1bmUgMSwgMjAxOCA5OjA3IEFNDQpUbzogTGVpZiBKb2hhbnNzb24g PGxlaWZqQG1udC5zZTxtYWlsdG86bGVpZmpAbW50LnNlPj4NCkNjOiBJRVRGIFRva2JpbmQgV0cg PHVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFtVbmJlYXJhYmxlXSB0b2tiaW5kIC0gTmV3IE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0 IGZvciBJRVRGIDEwMg0KDQpJdCdzIHByZXR0eSBzaG9ydCEgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC10dHJwLTAzPGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcl MkZodG1sJTJGZHJhZnQtaWV0Zi10b2tiaW5kLXR0cnAtMDMmZGF0YT0wMiU3QzAxJTdDQW5kcmVp LlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3Q2JlOWI0NWU1OTQyMjQxMzMwZDA5MDhkNWM3ZDliYmQy JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjYzNDY2MDMz NDEyMzQ0OSZzZGF0YT1tZmw0RFJlQzg0Nk9vUVNkeUp2WFEwVWpNWVk5emVUOEhucDJqYlh2aWlz JTNEJnJlc2VydmVkPTA+DQoNCk9uIEZyaSwgSnVuIDEsIDIwMTggYXQgODozMiBBTSwgTGVpZiBK b2hhbnNzb24gPGxlaWZqQG1udC5zZTxtYWlsdG86bGVpZmpAbW50LnNlPj4gd3JvdGU6DQoNCg0K T24gMjAxOC0wNi0wMSAwMDo0OSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQo+IEknZCBsaWtlIHRv IHJlcXVlc3Qgc29tZSBhZ2VuZGEgdGltZSB0byBjb3ZlciB0aGUgVFRSUCBkcmFmdCwgd2hpY2gg d2lsbA0KPiBsaWtlbHkgY29uc2lzdCBvZiBhbiBvdmVydmlldyBhbmQgc3RhdHVzIHVwZGF0ZSAo d2l0aCBzb21lIGdyYXR1aXRvdXMNCj4gcGhvdG9zIG9mIHJlY2VudCBJRVRGIG1lZXRpbmcgbG9j YXRpb25zKSBhbmQgYSBwbGVhIHRvIG1vdmUgdG93YXJkcw0KPiBXR0xDLiBUaGFua3MhDQoNCklu IG9yZGVyIHRvIGZhY2lsaXRhdGUgdGhhdC4uLiBjb3VsZCB3ZSBnZXQgc29tZSBmb2xrcyB0byBy ZXZpZXcNCnRoZSBUVFJQIGRyYWZ0IGJlZm9yZSAxMDI/DQoNCk1heWJlLi4uIHBsZWFzZS4uLiA/ Pw0KDQogICAgICAgIENoZWVycyBMZWlmDQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhp cyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3 LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29t cHV0ZXIuIFRoYW5rIHlvdS4NCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWls IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwg ZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUg dGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4g VGhhbmsgeW91Lg0K --_000_DM5PR21MB0507D809A381912B03CDEB3C8C640DM5PR21MB0507namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDA0MjU5ODIz Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzIwMjgy NiA1NTI4OTU4NTggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkdhdWdpbmcgV0cgY29u c2Vuc3VzIGlzbid0IHBhcnRpY3VsYXJpdHkgZWFzeSBpbiB0aGlzIFdHIGF0IHRoaXMgc3RhZ2Ug YnV0IGluIG15IG1pbmQgY29uc2Vuc3VzIGlzIHRoZXJlLjxvOnA+PC9vOnA+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T3VyIGF3ZXNvbWUgQ2hhaXJzIGNhbiBwcm9iYWJseSBoZWxw IGNvbmZpcm0gb25lIHdheSBvciB0aGUgb3RoZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5Ob3RoaW5nIGlzIGZ1dHVyZSBw cm9vZi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5TYXlpbmcgVFRSUCB3aWxs IHdvcmsgb25seSB3aXRoIGEgc3BlY2lmaWMgdmVyc2lvbiBtYXkgb3IgbWF5IG5vdCBwcm92ZSB0 cnVlLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VyZS4gSnVz dCB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0IHRoZSB0aGlua2luZyBpczogaWYgVFRSUCBpcyBu b3Qgc3VwcG9ydGFibGUgd2l0aCBUQiBYLCB3ZeKAmWxsIGp1c3Qgc2F5IOKAnGRvbuKAmXQgdXNl IFRUUlAgd2l0aCBUQiBYLCB1c2UgVFRSUGJpcyBpbnN0ZWFk4oCdPw0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgVFRSUGJpcyB3aWxsIHByb2JhYmx5IGRlZmluZSBz b21lIG5ldyBoZWFkZXJzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQnJp YW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5v cmcmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUgNywgMjAxOCAxMjowOSBQ TTxicj4NCjxiPlRvOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IExlaWYgSm9oYW5zc29uICZsdDtsZWlmakBtbnQuc2Um Z3Q7OyBJRVRGIFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gdG9rYmluZCAtIE5ldyBNZWV0aW5nIFNlc3Np b24gUmVxdWVzdCBmb3IgSUVURiAxMDI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgcmV2aWV3LCBBbmRyZWkuIDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2xsIGluY29ycG9yYXRl IHRoZSBlZGl0b3JpYWwgc3VnZ2VzdGlvbnMuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZGVzaWduIGNob2ljZSBvZiBoYXZpbmcgZGlz dGluY3QgU2VjLVByb3ZpZGVkIGFuZCBTZWMtUmVmZXJyZWQgaGVhZGVycyB3YXMgaW50ZW50aW9u YWwgYW5kIGFpbWVkIGF0IG1ha2luZyB0aGUgbW9zdCBjb21tb24gY2FzZXMgc2ltcGxlIGF0IHRo ZSBhcHBsaWNhdGlvbiBsYXllciBkZWFsaW5nIHdpdGggSFRUUC4gVGhlIHZhc3QgbWFqb3JpdHkg b2YgdGhlIHRpbWUgdGhlcmUncyBnb2luZyB0byBiZSBvbmx5DQogdGhlJm5ic3A7UHJvdmlkZWQg YW5kIGEgc2luZ2xlIGhlYWRlciB0aGF0IGNhcnJpZXMgdGhhdCB2YWx1ZSB1bmFkb3JuZWQgbWFr ZXMgYWNjZXNzaW5nIHRoYXQgdmVyeSBzdHJhaWdodGZvcndhcmQuJm5ic3A7IFJlZmVycmVkIGlz IHRoZSBvdGhlciBkZWZpbmVkIHR5cGUgd2l0aCBkZWZpbmVkIHVzYWdlIGluIEhUVFBTVEIgc28g VFRSUCBoYXMgU2VjLVJlZmVycmVkIGZvciB0aGF0LiBUaGVuIHRoZXJlIGFyZSAyNTQgb3RoZXIg dW5kZWZpbmVkIHR5cGVzIGFuZA0KIHRoZXJlIHdhcyBhIHJlcXVlc3QgZnJvbSB0aGUgV0cgKG9y IGEgcG9ydGlvbiB0aGVyZW9mKSB0byBhbGxvdyBmb3IgdGhlbSBzb21laG93LiBBIHNlcGFyYXRl IGhlYWRlciBmb3IgZXZlcnkgb25lIG9mIHRoZW0gc2VlbWVkIHByb2hpYml0aXZlIHRvIHNheSB0 aGUgbGVhc3QuIFRoYXQncyB3aGVyZSB0aGUgU2VjLU90aGVyIGNhdGNoLWFsbCBjb21lcyBmcm9t LiBUaGVyZSBhcmUgdHJhZGUtb2ZmcyBhbnkgZGVzaWduIGNob2ljZSBhbmQgdGhpcw0KIGlzIGEg Yml0IG9mIGEgaHlicmlkIGJ1dCBJIGZlZWwgaXQgc3RyaWtlcyBhIGdvb2QgYmFsYW5jZSBvZiBz aW1wbGljaXR5IGZvciB0aGUgY29tbW9uIGRlZmluZWQgY2FzZXMgd2hpbGUgc3RpbGwgYWNjb21t b2RhdGluZyBvdGhlcnMuIEdhdWdpbmcgV0cgY29uc2Vuc3VzIGlzbid0IHBhcnRpY3VsYXJpdHkg ZWFzeSBpbiB0aGlzIFdHIGF0IHRoaXMgc3RhZ2UgYnV0IGluIG15IG1pbmQgY29uc2Vuc3VzIGlz IHRoZXJlLiBUaGlzIHdvdWxkLCBvZg0KIGNvdXJzZSwgYmUgYSBnb29kIHRpbWUgZm9yIHRoZSBX RyB0byBzcGVhayB1cCB0byBpbmRpY2F0ZSBvdGhlcndpc2UsIGlmIHRoYXQncyBub3QgdGhlIGNh c2UuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Ro aW5nIGlzIGZ1dHVyZSBwcm9vZi4gVFRSUCBpcyBpbnRlbmRlZCB0byBmYWNpbGl0YXRlIGRlcGxv eW1lbnRzIG9mIEhUVFBTVEIuIEhUVFBTVEIgaXNuJ3QgZnV0dXJlIHByb29mIG9yIHZlcnNpb25l ZCBhbmQgd291bGQgbmVlZCB0byBjaGFuZ2UgdG8gYWxsb3cgZm9yIG1vcmUgdGhhbiBvbmUgcmVm ZXJyZWQgVEIgSUQuIFNheWluZyBUVFJQIHdpbGwgd29yayBvbmx5IHdpdGggYSBzcGVjaWZpYyB2 ZXJzaW9uDQogbWF5IG9yIG1heSBub3QgcHJvdmUgdHJ1ZS4gQW5kIHBhc3NpbmcgYWxvbmcgdGhl IG5lZ290aWF0ZWQgVEIgcHJvdG9jb2wgdmVyc2lvbiBtYXkgb3IgbWF5IG5vdCBhY2NvbW1vZGF0 ZSBmdXR1cmUgY2hhbmdlcy4gRnV0dXJlIFRCIHByb3RvY29sIHZlcnNpb25zIG1heSBvciBtYXkg bm90IGV2ZW4gaGFwcGVuLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBzaW5nbGUgSFRUUCBoZWFkZXIgZmllbGQtdmFsdWVkIHRleHQg d2FzIGxhcmdlbHkgcHV0IGluIHRoZXJlIHdpdGggdGhlIGhvcGUvZXhwZWN0YXRpb24gdGhhdCBp dCB3b3VsZCBlYXNlIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyAoYWZ0ZXIgSmVmZiBzdWdnZXN0 ZWQgc29tZXRoaW5nIHNpbWlsYXIgZm9yIHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIsIElJ UkMpLiBCdXQgYWxzbyBiZWNhdXNlIGl0DQogd2FzIGlubGluZSB3aXRoIHRoZSAmcXVvdDtleGFj dGx5IG9uZSZxdW90OyByZXN0cmljdGlvbiBpbiBIVFRQU1RCLiBCdXQgdGhhdCB0ZXh0IGNvdWxk IGVhc2lseSBiZSByZW1vdmVkLCBJIHRoaW5rLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1biA2LCAyMDE4IGF0IDEyOjUxIFBNLCBBbmRyZWkg UG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3Y9NDBtaWNyb3NvZnQuY29tQGRt YXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92PTQwbWljcm9zb2Z0LmNv bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgZG9jdW1lbnQgaXMg d2VsbC13cml0dGVuIGFuZCBjbGVhciwgb3ZlcmFsbC4gSSBoYXZlIGEgZmV3IGVkaXRvcmlhbCBj b21tZW50cyBhbmQgc29tZSBkZXNpZ24gY29tbWVudHM6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsg4oCcVG9rZW4gQmluZGluZyBvdmVyIEhUVFAgW0ktRC5pZXRmLXRva2JpbmQt aHR0cHNdIHByb3ZpZGVzIGEgbWVjaGFuaXNtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOyZuYnNwOyB0aGF0IGVuYWJsZXMgSFRUUCBzZXJ2ZXJzIHRvIGNyeXB0 b2dyYXBoaWNhbGx5IGJpbmQgY29va2llcyBhbmQgb3RoZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IHNlY3VyaXR5IHRva2VucyB0byBhIGtleSBo ZWxkIGJ5IHRoZSBicm93c2VyIG9yIG90aGVyIEhUVFAgY2xpZW50LDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgcG9zc2Vzc2lvbiBvZiB3aGljaCBp cyBwcm92ZW4gb24gdGhlIFRMUyBbUkZDNTI0Nl0gY29ubmVjdGlvbnMgb3ZlcjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgd2hpY2ggdGhlIHRva2Vu cyBhcmUgdXNlZC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkVkaXRvcmlhbCBzdWdn ZXN0aW9uOiDigJzigKZ0byBhIGtleSBnZW5lcmF0ZWQgYnkgdGhlIGNsaWVudC7igJ0gV2hldGhl ciB0aGUgYnJvd3NlciwgSFRUUCBjbGllbnQsIG9yIHVuZGVybHlpbmcgcGxhdGZvcm0gaG9sZCB0 aGUgVEIga2V5IGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGFuZCBwcm9iYWJseSB1bm5lY2Vz c2FyeQ0KIGRldGFpbCBoZXJlLiBQcm9vZiBvZiBwb3NzZXNzaW9uIGlzIGRpc2N1c3NlZCBpbiB0 aGUgbmV4dCBzZW50ZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyDigJxU aGUgdXNhZ2Ugb2YgdGhlIGhlYWRlcnMsIGJvdGggdGhlIHJldmVyc2UgcHJveHkgYWRkaW5nIF88 aT5pdDwvaT5fIGFuZCB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0aW9uIHNlcnZlciB1c2luZyBfPGk+dGhlbTwvaT5fIHRvIGJp bmQgY29va2llcyBvciBvdGhlciB0b2tlbnMsIGFyZSB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgYmUgY29uZmlndXJhdGlvbiBvcHRpb25zIG9m IHRoZSByZXNwZWN0aXZlIHN5c3RlbXMgYXMgdGhleSB3aWxsIG5vdDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgYWx3YXlzIGJlIGFwcGxpY2FibGUu 4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FZGl0b3JpYWw6IHRoaXMgc2VudGVuY2Ug Y29uZnVzZXMgbWUsIGVzcC4gYXJvdW5kIOKAnGl04oCdIGFuZCDigJx0aGVt4oCdOyBwZXJoYXBz IGl04oCZcyBwb3NzaWJsZSB0byBzaW1wbGlmeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlNlY3Rpb24gMi4yOiBIYXZpbmcgdGhyZWUgc2VwYXJhdGUgaGVhZGVyczogU2VjLVByb3ZpZGVk LCBTZWMtUmVmZXJyZWQgYW5kIFNlYy1PdGhlciBjYXRjaC1hbGwgd291bGQgbm90IGJlIG15IGRl c2lnbiBjaG9pY2UuIEnigJlkIHN1Z2dlc3QgZWl0aGVyIG9uZSBoZWFkZXIgd2l0aCBhIGxpc3Qg b2YgYWxsIFRCDQogSURzLCBvciBhIHNlcGFyYXRlIGhlYWRlciBmb3IgZWFjaCBUQiBJRC4gT2Yg Y291cnNlLCBpZiBXRyBjb25zZW5zdXMgZXhpc3RzIG9uIHRoZSBjdXJyZW50IGRlc2lnbiwgdGhl biB0aGF04oCZcyB3aGF0IGl0IGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 Jm5ic3A7IOKAnEJvdGggJnF1b3Q7U2VjLVByb3ZpZGVkLVRva2VuLUJpbmRpbmctSUQmcXVvdDsg YW5kICZxdW90O1NlYy1SZWZlcnJlZC1Ub2tlbi1CaW5kaW5nLTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgSUQmcXVvdDsgYXJlIHNpbmdsZSBIVFRQ IGhlYWRlciBmaWVsZC12YWx1ZWTigKbigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNv bWV3aGF0IHJlbGF0ZWQgdG8gdGhlIHByZXZpb3VzIGNvbW1lbnQ6IHRoaXMgc2VlbXMgdG8gYmUg c2F5aW5nIHRoYXQgdGhlcmUgY2Fubm90IGJlIG1vcmUgdGhhbiBvbmUgcmVmZXJyZWQgVEIgSUQs IHdoaWNoIGlzIGZpbmUgbm93LCBidXQgbm90IG5lY2Vzc2FyaWx5IGZ1dHVyZSBwcm9vZi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VFRSUCBzZWVtcyB0byBub3QgYmUg dmVyc2lvbmVkOyBpZiwgc2F5LCBUQiAyLjAgdXNlcyBtdWx0aXBsZSByZWZlcnJlZCBiaW5kaW5n cyBwZXIgcmVxdWVzdCwgd2lsbCB3ZSBuZWVkIFRUUlAgMi4wIHdpdGggYWxsIG5ldyBoZWFkZXJz PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgc2VlbXMgdGhhdCBUVFJQIG5lZWRzIHRv IGJlIGVpdGhlciBUQiB2ZXJzaW9uLXNwZWNpZmljLCBpLmUuIGV4cGxpY2l0bHkgc2F5IOKAnHRo aXMgaXMgZm9yIFRCIDEuMCBvbmx5LCBhbmQgZnV0dXJlIFRCIHZlcnNpb25zIHdpbGwgcmVxdWly ZSBuZXcgVFRSUCBzcGVjc+KAnSwgb3IgYmUgZGVzaWduZWQgYXMgYQ0KIHBpcGVsaW5lLCBwYXNz aW5nIHdoYXRldmVyIGJpbmRpbmdzIHRoZSBwcm94eSB3YXMgYWJsZSB0byB2ZXJpZnksIHBvc3Np Ymx5IGFsb25nIHdpdGggdGhlIG5lZ290aWF0ZWQgVEIgcHJvdG9jb2wgdmVyc2lvbi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlNlY3VyaXR5IGFuZCBJQU5BIGNvbnNpZGVyYXRpb25zIGxv b2sgZ29vZCB0byBtZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoZWVycyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHJlaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+RnJvbTo8L2I+IFVuYmVhcmFibGUgJmx0OzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNl bnQ6PC9iPiBGcmlkYXksIEp1bmUgMSwgMjAxOCA5OjA3IEFNPGJyPg0KPGI+VG86PC9iPiBMZWlm IEpvaGFuc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlaWZqQG1udC5zZSIgdGFyZ2V0PSJfYmxh bmsiPmxlaWZqQG1udC5zZTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFRva2JpbmQgV0cg Jmx0OzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5i ZWFyYWJsZV0gdG9rYmluZCAtIE5ldyBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBmb3IgSUVURiAx MDI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQncyBwcmV0dHkg c2hvcnQhDQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWll dGYtdG9rYmluZC10dHJwLTAzJmFtcDtkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNy b3NvZnQuY29tJTdDYmU5YjQ1ZTU5NDIyNDEzMzBkMDkwOGQ1YzdkOWJiZDIlN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjM0NjYwMzM0MTIzNDQ5JmFtcDtz ZGF0YT1tZmw0RFJlQzg0Nk9vUVNkeUp2WFEwVWpNWVk5emVUOEhucDJqYlh2aWlzJTNEJmFtcDty ZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10b2tiaW5kLXR0cnAtMDM8L2E+IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIEp1 biAxLCAyMDE4IGF0IDg6MzIgQU0sIExlaWYgSm9oYW5zc29uICZsdDs8YSBocmVmPSJtYWlsdG86 bGVpZmpAbW50LnNlIiB0YXJnZXQ9Il9ibGFuayI+bGVpZmpAbW50LnNlPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyPg0KT24gMjAxOC0wNi0w MSAwMDo0OSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6PGJyPg0KJmd0OyBJJ2QgbGlrZSB0byByZXF1 ZXN0IHNvbWUgYWdlbmRhIHRpbWUgdG8gY292ZXIgdGhlIFRUUlAgZHJhZnQsIHdoaWNoIHdpbGw8 YnI+DQomZ3Q7IGxpa2VseSBjb25zaXN0IG9mIGFuJm5ic3A7b3ZlcnZpZXcgYW5kIHN0YXR1cyB1 cGRhdGUgKHdpdGggc29tZSBncmF0dWl0b3VzPGJyPg0KJmd0OyBwaG90b3Mgb2YgcmVjZW50IElF VEYgbWVldGluZyBsb2NhdGlvbnMpIGFuZCBhIHBsZWEgdG8gbW92ZSB0b3dhcmRzPGJyPg0KJmd0 OyBXR0xDLiBUaGFua3MhPGJyPg0KPGJyPg0KSW4gb3JkZXIgdG8gZmFjaWxpdGF0ZSB0aGF0Li4u IGNvdWxkIHdlIGdldCBzb21lIGZvbGtzIHRvIHJldmlldzxicj4NCnRoZSBUVFJQIGRyYWZ0IGJl Zm9yZSAxMDI/PGJyPg0KPGJyPg0KTWF5YmUuLi4gcGxlYXNlLi4uID8/PGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENoZWVycyBMZWlmPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi cj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5k b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQogQW55IHJldmlldywg dXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBh bmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIg Y29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLg0KIEFueSByZXZpZXcsIHVzZSwg ZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_DM5PR21MB0507D809A381912B03CDEB3C8C640DM5PR21MB0507namp_-- From nobody Thu Jun 7 15:23:18 2018 Return-Path: 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 C8E96131138 for ; Thu, 7 Jun 2018 15:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 YYMx26sPDhgr for ; Thu, 7 Jun 2018 15:23:11 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D226F130DD8 for ; Thu, 7 Jun 2018 15:23:10 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id a3-v6so26161itd.0 for ; Thu, 07 Jun 2018 15:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B2Z3sutyXUcOCB9hR+JPYPNs3Ftran5L/zJCzP1p5W8=; b=bWBW3qFP6kq5kVwz288pruTLGAoX/Bf3Ju0tubu6o2j2S2Ee1X/CHZXTQubtou9Pif 3syzl114pxm6YF5OUBoLEUY5N8x3rM1s1h9wghScTB+3T0Ou9EYo7Xvbzuk38FwTHVWs QaepAjHub0l/aPCNBHKkUFSATwqk5qDvODiyo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B2Z3sutyXUcOCB9hR+JPYPNs3Ftran5L/zJCzP1p5W8=; b=mVCYFgrhDE3PZgmU/UN/koV9mq1CX9+mqWFKS0SA22rNipjeBhd38xAImlA6TsK797 CVCfeykclbBAI1MuKWZh9QWZToHQepLxPNIgJ3Oju6yrwPLl0gbfVPvnagu9h/G4QYvP aML2PjOMjYZeMBvzmUVmBc9JImrst9vekN2jXCVw0uxKXpZrvPd6OdMVuggTiF4yD83z msCpb4hxUoF4mF8aroZyqmq1g8I/blKd43kHbmODP2Lkmv707RKgIoOOeXFhqBeL4U2R mDx1PNHPMNyQi+p9I5P90r7mYMtTr1vRCaOtBGwdP6xbFIeAwGHvqYBn3vkmyQHY7KQz qh2A== X-Gm-Message-State: APt69E3KZNxZvg7X/ej9gnq7RXeQ1+i50ljsSypjzllCK+T0dHKIze0Y QstN4RSr5MGqWdVkV7OZ0NXIoHq36YtjpCh6hvJ/qV33WtBdcP99X9xhwihUnB4w4W0E3iAEjuu Zo9XAHuTlrZ5J4rMl/Bky X-Google-Smtp-Source: ADUXVKIGEWzPLUjLpxIu9AGITj+WsOqQIoiApWUaxhXn8cRJrw9ahB5dd+cSsggCzJrRMa+VzJH2dDKNF9au6R/MAjE= X-Received: by 2002:a24:ed4a:: with SMTP id r71-v6mr3683663ith.53.1528410189877; Thu, 07 Jun 2018 15:23:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 15:22:39 -0700 (PDT) In-Reply-To: References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> From: Brian Campbell Date: Thu, 7 Jun 2018 16:22:39 -0600 Message-ID: To: Andrei Popov Cc: Leif Johansson , IETF Tokbind WG Content-Type: multipart/alternative; boundary="0000000000007074e0056e14baac" Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 22:23:16 -0000 --0000000000007074e0056e14baac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, that's pretty much the thinking. Hopefully, TTRP is supportable with TB X. Or the drivers for TB X can be accommodated in a way that continue to work with TTRP unchanged. But if not, TTRPnext will be the new way with the new TB X. And that likely will mean some new headers. On Thu, Jun 7, 2018 at 3:58 PM, Andrei Popov < Andrei.Popov=3D40microsoft.com@dmarc.ietf.org> wrote: > > - Gauging WG consensus isn't particularity easy in this WG at this > stage but in my mind consensus is there. > > Our awesome Chairs can probably help confirm one way or the other. > > > > - Nothing is future proof. > - Saying TTRP will work only with a specific version may or may not > prove true. > > Sure. Just trying to understand what the thinking is: if TTRP is not > supportable with TB X, we=E2=80=99ll just say =E2=80=9Cdon=E2=80=99t use = TTRP with TB X, use > TTRPbis instead=E2=80=9D? > > And TTRPbis will probably define some new headers? > > > > *From:* Brian Campbell > *Sent:* Thursday, June 7, 2018 12:09 PM > *To:* Andrei Popov > *Cc:* Leif Johansson ; IETF Tokbind WG > > *Subject:* Re: [Unbearable] tokbind - New Meeting Session Request for > IETF 102 > > > > Thanks for the review, Andrei. > > > > I'll incorporate the editorial suggestions. > > > > The design choice of having distinct Sec-Provided and Sec-Referred header= s > was intentional and aimed at making the most common cases simple at the > application layer dealing with HTTP. The vast majority of the time there'= s > going to be only the Provided and a single header that carries that value > unadorned makes accessing that very straightforward. Referred is the oth= er > defined type with defined usage in HTTPSTB so TTRP has Sec-Referred for > that. Then there are 254 other undefined types and there was a request fr= om > the WG (or a portion thereof) to allow for them somehow. A separate heade= r > for every one of them seemed prohibitive to say the least. That's where t= he > Sec-Other catch-all comes from. There are trade-offs any design choice an= d > this is a bit of a hybrid but I feel it strikes a good balance of > simplicity for the common defined cases while still accommodating others. > Gauging WG consensus isn't particularity easy in this WG at this stage bu= t > in my mind consensus is there. This would, of course, be a good time for > the WG to speak up to indicate otherwise, if that's not the case. > > > > Nothing is future proof. TTRP is intended to facilitate deployments of > HTTPSTB. HTTPSTB isn't future proof or versioned and would need to change > to allow for more than one referred TB ID. Saying TTRP will work only wit= h > a specific version may or may not prove true. And passing along the > negotiated TB protocol version may or may not accommodate future changes. > Future TB protocol versions may or may not even happen. > > > > The single HTTP header field-valued text was largely put in there with th= e > hope/expectation that it would ease the registration process (after Jeff > suggested something similar for the Sec-Token-Binding header, IIRC). But > also because it was inline with the "exactly one" restriction in HTTPSTB. > But that text could easily be removed, I think. > > > > > > > > On Wed, Jun 6, 2018 at 12:51 PM, Andrei Popov < > Andrei.Popov=3D40microsoft.com@dmarc.ietf.org> wrote: > > The document is well-written and clear, overall. I have a few editorial > comments and some design comments: > > > > =E2=80=9CToken Binding over HTTP [I-D.ietf-tokbind-https] provides a me= chanism > > that enables HTTP servers to cryptographically bind cookies and other > > security tokens to a key held by the browser or other HTTP client, > > possession of which is proven on the TLS [RFC5246] connections over > > which the tokens are used.=E2=80=9D > > > > Editorial suggestion: =E2=80=9C=E2=80=A6to a key generated by the client.= =E2=80=9D Whether the > browser, HTTP client, or underlying platform hold the TB key is > implementation-specific and probably unnecessary detail here. Proof of > possession is discussed in the next sentence. > > > > =E2=80=9CThe usage of the headers, both the reverse proxy adding _*it*_= and the > > application server using _*them*_ to bind cookies or other tokens, are > to > > be configuration options of the respective systems as they will not > > always be applicable.=E2=80=9D > > > > Editorial: this sentence confuses me, esp. around =E2=80=9Cit=E2=80=9D an= d =E2=80=9Cthem=E2=80=9D; perhaps > it=E2=80=99s possible to simplify. > > > > Section 2.2: Having three separate headers: Sec-Provided, Sec-Referred an= d > Sec-Other catch-all would not be my design choice. I=E2=80=99d suggest ei= ther one > header with a list of all TB IDs, or a separate header for each TB ID. Of > course, if WG consensus exists on the current design, then that=E2=80=99s= what it > is. > > > > =E2=80=9CBoth "Sec-Provided-Token-Binding-ID" and "Sec-Referred-Token-= Binding- > > ID" are single HTTP header field-valued=E2=80=A6=E2=80=9D > > > > Somewhat related to the previous comment: this seems to be saying that > there cannot be more than one referred TB ID, which is fine now, but not > necessarily future proof. > > TTRP seems to not be versioned; if, say, TB 2.0 uses multiple referred > bindings per request, will we need TTRP 2.0 with all new headers? > > > > It seems that TTRP needs to be either TB version-specific, i.e. explicitl= y > say =E2=80=9Cthis is for TB 1.0 only, and future TB versions will require= new TTRP > specs=E2=80=9D, or be designed as a pipeline, passing whatever bindings t= he proxy > was able to verify, possibly along with the negotiated TB protocol versio= n. > > > > Security and IANA considerations look good to me. > > > > Cheers, > > > > Andrei > > > > *From:* Unbearable *On Behalf Of *Brian > Campbell > *Sent:* Friday, June 1, 2018 9:07 AM > *To:* Leif Johansson > *Cc:* IETF Tokbind WG > *Subject:* Re: [Unbearable] tokbind - New Meeting Session Request for > IETF 102 > > > > It's pretty short! https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-03 > > > > > On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson wrote: > > > > On 2018-06-01 00:49, Brian Campbell wrote: > > I'd like to request some agenda time to cover the TTRP draft, which wil= l > > likely consist of an overview and status update (with some gratuitous > > photos of recent IETF meeting locations) and a plea to move towards > > WGLC. Thanks! > > In order to facilitate that... could we get some folks to review > the TTRP draft before 102? > > Maybe... please... ?? > > Cheers Leif > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000007074e0056e14baac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, that's pretty much the thinking. Hopefully,= TTRP is supportable with TB X. Or the drivers for TB X can be accommodated= in a way that continue to work with TTRP unchanged. But if not, TTRPnext w= ill be the new way with the new TB X. And that likely will mean some new he= aders.

On Thu, Jun 7, 2018 at 3:58 PM, Andrei Popov <Andrei.Popov=3D40microsoft.com@dmarc.ietf.org> wrote:
  • Gauging WG consensus isn't particularity easy in this WG at this sta= ge but in my mind consensus is there.

Our awesome Chairs can probably help confirm = one way or the other.

=C2=A0

  • Nothing is future proof.
  • Saying TT= RP will work only with a specific version may or may not prove true.=

Sure. Just trying to understand what the thinking is= : if TTRP is not supportable with TB X, we=E2=80=99ll just say =E2=80=9Cdon= =E2=80=99t use TTRP with TB X, use TTRPbis instead=E2=80=9D?

And TTRPbis will probably define some new headers?

=C2=A0

From: Brian Campbell <bcampbell=3D40pingident= ity.com@dmarc.ietf.org>
Sent: Thursday, June 7, 2018 12:09 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Leif Johansson <leifj@mnt.se>; IETF Tokbind WG <unbearable@ietf.org>


Subject: Re: [Unbearable] tokbind - New Meeting Session Request for = IETF 102

=C2=A0

Thanks for the review, Andrei.

=C2=A0

I'll incorporate the editorial suggestions. <= /u>

=C2=A0

The design choice of having distinct Sec-Provided an= d Sec-Referred headers was intentional and aimed at making the most common = cases simple at the application layer dealing with HTTP. The vast majority = of the time there's going to be only the=C2=A0Provided and a single header that carries that value unadorned ma= kes accessing that very straightforward.=C2=A0 Referred is the other define= d type with defined usage in HTTPSTB so TTRP has Sec-Referred for that. The= n there are 254 other undefined types and there was a request from the WG (or a portion thereof) to allow for them s= omehow. A separate header for every one of them seemed prohibitive to say t= he least. That's where the Sec-Other catch-all comes from. There are tr= ade-offs any design choice and this is a bit of a hybrid but I feel it strikes a good balance of simplicity fo= r the common defined cases while still accommodating others. Gauging WG con= sensus isn't particularity easy in this WG at this stage but in my mind= consensus is there. This would, of course, be a good time for the WG to speak up to indicate otherwise, if th= at's not the case.

=C2=A0

Nothing is future proof. TTRP is intended to facilit= ate deployments of HTTPSTB. HTTPSTB isn't future proof or versioned and= would need to change to allow for more than one referred TB ID. Saying TTR= P will work only with a specific version may or may not prove true. And passing along the negotiated TB protocol ve= rsion may or may not accommodate future changes. Future TB protocol version= s may or may not even happen.

=C2=A0

The single HTTP header field-valued text was largely= put in there with the hope/expectation that it would ease the registration= process (after Jeff suggested something similar for the Sec-Token-Binding = header, IIRC). But also because it was inline with the "exactly one" restriction in HTTPSTB. But th= at text could easily be removed, I think.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jun 6, 2018 at 12:51 PM, Andrei Popov <Andrei.Popov=3D40microsoft.com@dmarc.ietf.org> wrote:<= /u>

The document is well-written and clear, overall. I h= ave a few editorial comments and some design comments:

=C2=A0

=C2=A0 =E2=80=9CToken Binding over HTTP [I-D.ietf-to= kbind-https] provides a mechanism

=C2=A0=C2=A0 that enables HTTP servers to cryptograp= hically bind cookies and other

=C2=A0=C2=A0 security tokens to a key held by the br= owser or other HTTP client,

=C2=A0=C2=A0 possession of which is proven on the TL= S [RFC5246] connections over

=C2=A0=C2=A0 which the tokens are used.=E2=80=9D<= /u>

=C2=A0

Editorial suggestion: =E2=80=9C=E2=80=A6to a key gen= erated by the client.=E2=80=9D Whether the browser, HTTP client, or underly= ing platform hold the TB key is implementation-specific and probably unnece= ssary detail here. Proof of possession is discussed in the next sentence.=

=C2=A0

=C2=A0 =E2=80=9CThe usage of the headers, both the r= everse proxy adding _it_ and the

=C2=A0=C2=A0 application server using _them_ = to bind cookies or other tokens, are to

=C2=A0=C2=A0 be configuration options of the respect= ive systems as they will not

=C2=A0=C2=A0 always be applicable.=E2=80=9D

=C2=A0

Editorial: this sentence confuses me, esp. around = =E2=80=9Cit=E2=80=9D and =E2=80=9Cthem=E2=80=9D; perhaps it=E2=80=99s possi= ble to simplify.

=C2=A0

Section 2.2: Having three separate headers: Sec-Prov= ided, Sec-Referred and Sec-Other catch-all would not be my design choice. I= =E2=80=99d suggest either one header with a list of all TB IDs, or a separate header for each TB ID. Of course, if WG consensus exist= s on the current design, then that=E2=80=99s what it is.

=C2=A0

=C2=A0=C2=A0 =E2=80=9CBoth "Sec-Provided-Token-= Binding-ID" and "Sec-Referred-Token-Binding-

=C2=A0=C2=A0 ID" are single HTTP header field-v= alued=E2=80=A6=E2=80=9D

=C2=A0

Somewhat related to the previous comment: this seems= to be saying that there cannot be more than one referred TB ID, which is f= ine now, but not necessarily future proof.

TTRP seems to not be versioned; if, say, TB 2.0 uses= multiple referred bindings per request, will we need TTRP 2.0 with all new= headers?

=C2=A0

It seems that TTRP needs to be either TB version-spe= cific, i.e. explicitly say =E2=80=9Cthis is for TB 1.0 only, and future TB = versions will require new TTRP specs=E2=80=9D, or be designed as a pipeline, passing whatever bindings the proxy was able to verify, possibly= along with the negotiated TB protocol version.

=C2=A0

Security and IANA considerations look good to me.=

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable <unbearable-bounces@ietf.org>= ; On Behalf Of Brian Campbell
Sent: Friday, June 1, 2018 9:07 AM
To: Leif Johansson <leifj@mnt.se>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for = IETF 102

=C2=A0

=C2=A0

On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson <<= a href=3D"mailto:leifj@mnt.se" target=3D"_blank">leifj@mnt.se> wrote= :



On 2018-06-01 00:49, Brian Campbell wrote:
> I'd like to request some agenda time to cover the TTRP draft, whic= h will
> likely consist of an=C2=A0overview and status update (with some gratui= tous
> photos of recent IETF meeting locations) and a plea to move towards > WGLC. Thanks!

In order to facilitate that... could we get some folks to review
the TTRP draft before 102?

Maybe... please... ??

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif

=C2=A0


CONFIDENTIAL= ITY NOTICE: This email may contain confidential and privileged material for= the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed..=C2=A0 If you have received this communication in error, please notify = the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.

=C2=A0


CONFIDENTIAL= ITY NOTICE: This email may contain confidential and privileged material for= the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed..=C2=A0 If you have received this communication in error, please notify = the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000007074e0056e14baac-- From nobody Wed Jun 20 17:07:35 2018 Return-Path: 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 535E8130ECD for ; Wed, 20 Jun 2018 17:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 kj3Z4ySZem4D for ; Wed, 20 Jun 2018 17:07:31 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429BB130EBF for ; Wed, 20 Jun 2018 17:07:31 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id q62-v6so529897ybg.5 for ; Wed, 20 Jun 2018 17:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Aq8W/4NlTy1oxivldjCZRPzDzuBoklzDtt+xCin68pw=; b=qEzoHXNhWYhDCVHQboInlrRT84/ICwLoIFG0m8Du2ozSFcDmrVEHvDBBRWPLwrC6WY ml0eE726LOfHnIjooSTTNX39DyCC5WR+DJZnfl+sAqmmoTI6OFFcu23YHOEpxdR1qZf2 G39RO3ix/2wabJszKTkE7b4Hl5tbYv/eoPRjp+hk6ogEC9AQPNMN08dotC+TrZKUjEqm gsNhaAJuLGNlBWlKYcjvg81StLBy1+L/V+ifMqt/D8b1Bf8/aR42pHkLua+IWVY8Dmqe 4emgURp7TGfQk0uQO4OHzG1I/XMRxTguHL7yIvgdlIUulidOVa5sRluOvMKPePd4AC9Y CLKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Aq8W/4NlTy1oxivldjCZRPzDzuBoklzDtt+xCin68pw=; b=Br1T977+wSSfbIGI4E9cjrZC/7121QaFhy6jatHyXJNJdkgG2xfqFVLZ37Q6VW6KnZ TsZkhGMvKvfpJpXlHndU35pjmr07RT8Lb9mKIsBpAjriBDc5Gr8loc8XJRWyuI7uLo1p j4z7muu6GWHVcZbSfQ/1O78Hx4s7PrQDUUm5r1QR7zwAT71NrqWbODKmMA/LMyGxqxQS 2/9E8dhjN7AQ2T7Cn7DZERwURxvNebovckKvpfXYmfGl63sYu4U1dF5rygJg6qg3b2n4 AfQKC7SYOu7BbWfizCoi383Dv0XEOb9I1lBtYxBs29V5CF4VIlVJeN6J9mAnWlBVhKcx hv4g== X-Gm-Message-State: APt69E1206IQs3AUcz635+3/z1WudBmmSetHMT5wZV4zg+qNiax76YOp meca41ZsTPY1aTCLqPaJEayzk5hgtnBE7XZztWHVkg== X-Google-Smtp-Source: ADUXVKKTBUtRPa1/+aYSpM7j4KJ/mT2wS1J8vHdgMzWRUWs/5NWkTsN73KafrbyVnzaJrNa5FtD45k+fbZKYezGUjVU= X-Received: by 2002:a25:9a49:: with SMTP id r9-v6mr4318012ybo.451.1529539650509; Wed, 20 Jun 2018 17:07:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 17:06:50 -0700 (PDT) In-Reply-To: <152588844353.3985.1790443621473802523.idtracker@ietfa.amsl.com> References: <152588844353.3985.1790443621473802523.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 20 Jun 2018 17:06:50 -0700 Message-ID: To: Alissa Cooper Cc: The IESG , John Bradley , IETF Tokbind WG , tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org Content-Type: multipart/alternative; boundary="00000000000089f7a7056f1bb354" Archived-At: Subject: Re: [Unbearable] Alissa Cooper's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 00:07:34 -0000 --00000000000089f7a7056f1bb354 Content-Type: text/plain; charset="UTF-8" Alissa, does the latest draft address your DISCUSS? On Wed, May 9, 2018 at 10:54 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-tokbind-https-14: 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: > https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 2.1 says: > > "The scoping of Token Binding key pairs generated by Web browsers for > use in first-party and federation use cases defined in this > specification (Section 5), and intended for binding HTTP cookies, > MUST be no wider than the granularity of "effective top-level domain > (public suffix) + 1" (eTLD+1). I.e., the scope of Token Binding key > pairs is no wider than the scope at which cookies can be set (see > [RFC6265]), but MAY be more narrow if cookies are scoped more > narrowly." > > My reading of RFC 6265 is that it does not actually forbid cookie setting > at a > scope wider than eTLD+1, although I could be reading Section 5.3 of that > document wrong. That section says that if the user agent is configured to > reject public suffixes, then there is a case where a set-cookie request > should > be ignored. If the intent here is to normatively restrict the scope of > Token > Binding key pairs to eTLD+1 regardless of whether the user agent restricts > cookies to that scope, that needs to be stated clearly. > > I kind of hate to say this but with the way this is phrased I also think > you > need a normative reference for the concept of "effective top-level > domain." (I > suspect this would be considered a downref and may not already be in the > downref registry, but I'm not one to make a fuss about that.) > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I would also suggest s/but/and/ in the last sentence quoted from 2.1 above. > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --00000000000089f7a7056f1bb354 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alissa, does the latest draft address your DISCUSS?

On Wed, May 9,= 2018 at 10:54 AM, Alissa Cooper <alissa@cooperw.in> wrote:<= br>
Alissa Cooper has entered the following b= allot position for
draft-ietf-tokbind-https-14: 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/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-tokbind-https/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Section 2.1 says:

"The scoping of Token Binding key pairs generated by Web browsers for<= br> =C2=A0 =C2=A0use in first-party and federation use cases defined in this =C2=A0 =C2=A0specification (Section 5), and intended for binding HTTP cooki= es,
=C2=A0 =C2=A0MUST be no wider than the granularity of "effective top-l= evel domain
=C2=A0 =C2=A0(public suffix) + 1" (eTLD+1).=C2=A0 I.e., the scope of T= oken Binding key
=C2=A0 =C2=A0pairs is no wider than the scope at which cookies can be set (= see
=C2=A0 =C2=A0[RFC6265]), but MAY be more narrow if cookies are scoped more<= br> =C2=A0 =C2=A0narrowly."

My reading of RFC 6265 is that it does not actually forbid cookie setting a= t a
scope wider than eTLD+1, although I could be reading Section 5.3 of that document wrong. That section says that if the user agent is configured to reject public suffixes, then there is a case where a set-cookie request sho= uld
be ignored. If the intent here is to normatively restrict the scope of Toke= n
Binding key pairs to eTLD+1 regardless of whether the user agent restricts<= br> cookies to that scope, that needs to be stated clearly.

I kind of hate to say this but with the way this is phrased I also think yo= u
need a normative reference for the concept of "effective top-level dom= ain." (I
suspect this would be considered a downref and may not already be in the downref registry, but I'm not one to make a fuss about that.)


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I would also suggest s/but/and/ in the last sentence quoted from 2.1 above.=


_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e

--00000000000089f7a7056f1bb354-- From nobody Fri Jun 22 14:05:57 2018 Return-Path: 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 46996130EEB; Fri, 22 Jun 2018 14:05:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152970155025.3491.1920594649326917311@ietfa.amsl.com> Date: Fri, 22 Jun 2018 14:05:50 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-05.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 21:05:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : HTTPS Token Binding with TLS Terminating Reverse Proxies Author : Brian Campbell Filename : draft-ietf-tokbind-ttrp-05.txt Pages : 14 Date : 2018-06-22 Abstract: This document defines HTTP header fields that enable a TLS terminating reverse proxy to convey information to a backend server about the validated Token Binding Message received from a client, which enables that backend server to bind, or verify the binding of, cookies and other security tokens to the client's Token Binding key. This facilitates the reverse proxy and backend server functioning together as though they are a single logical server side deployment of HTTPS Token Binding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-05 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-ttrp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-ttrp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 22 14:11:43 2018 Return-Path: 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 B6337130EEB for ; Fri, 22 Jun 2018 14:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 h4k5rQFUUG5v for ; Fri, 22 Jun 2018 14:11:39 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71D3130EF1 for ; Fri, 22 Jun 2018 14:11:38 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id p185-v6so4721462itp.4 for ; Fri, 22 Jun 2018 14:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Jes1QFIFDQkbYSbLH+mmZk9KilDc48b20WcDDyAJG1g=; b=jM8X9XK+617Oj2oR/hl/CX1uk4PgI3KvpqIaK+kT0/2PD660YpeHv9DHW9yASgmUdO edB2AAY2ZvMAXNwA/oRQ81rajUvFdpHhoc6b+bRl20fAa2Vsm/r1oQxDWbuAvGIeYLEf a5NCNcdEnWqJ9yJ/d0af+1aB/r87YO1cA+aMI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Jes1QFIFDQkbYSbLH+mmZk9KilDc48b20WcDDyAJG1g=; b=q8pb+IaBXqUcg6GLOjnQA3TDZyzs7sc6bW9L6nk2TXwkGByUVWEZh08wBLpMlVaRbC kA9GCWWcB3XLWVh9Mx6C6Qln2zTz/ESUIVKZ82KQFPLzhMJX1G7kZKKutWacCKacvSQM cQLBtZaCwmKE/PaNYwr28PJoZtuh5z6XN4fgYBvk+dFokXPRTR+zkLz0UC8yO/A73R4d LHKKoUOX7sfsdKcl95v0SzouxniYjuFRuAqv/MLdjNzULbjXmIacQqjGpH4Waa5ylzRl 2Rpa40M/sexuSynXAgBCbyFCiNB2P26g7HIs3gXd7mq0dB2EasSXwrOlc5BEWhp2112K mwAA== X-Gm-Message-State: APt69E3K9hn51qW6lyTtNqdF5REAmO2+MouWthMpQUmLbs3nrd61B2Pb 2NkRxS61aOyrCrlTks0D48fLLcVjqTB+6iMTRQw0O4vt7BfCvSKlJGXeqFc2iVS2q9bty4e706L rdi6pD8kFddsHF+aptcGirhw= X-Google-Smtp-Source: AAOMgpfIa0Tsf+W34kpM3wchb2vNYtgHKH0cV9bE8oTJtMPDvDAcsvPjq+Sr+c3xxvXNGswLUNZaqM+mbPgFx8WZqC8= X-Received: by 2002:a24:ed4a:: with SMTP id r71-v6mr2899521ith.53.1529701897825; Fri, 22 Jun 2018 14:11:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:9785:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 14:11:07 -0700 (PDT) In-Reply-To: <152970155025.3491.1920594649326917311@ietfa.amsl.com> References: <152970155025.3491.1920594649326917311@ietfa.amsl.com> From: Brian Campbell Date: Fri, 22 Jun 2018 15:11:07 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary="0000000000003b9e61056f417a68" Archived-At: Subject: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-05.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 21:11:42 -0000 --0000000000003b9e61056f417a68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable -05 is a pretty minor update to the TTRP draft. Changes copied from the doc history are listed below for easy/lazy reference. draft-ietf-tokbind-ttrp-05 o Editorial updates. o Change one character in the last example to help emphasize the case-insensitivity of hex. o Add a TLS Versions and Best Practices section with BCP195 and also mention of ietf-tokbind-tls13 and ietf-tls-tls13. ---------- Forwarded message ---------- From: Date: Fri, Jun 22, 2018 at 3:05 PM Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-05.txt To: i-d-announce@ietf.org Cc: unbearable@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : HTTPS Token Binding with TLS Terminating Reverse Proxies Author : Brian Campbell Filename : draft-ietf-tokbind-ttrp-05.txt Pages : 14 Date : 2018-06-22 Abstract: This document defines HTTP header fields that enable a TLS terminating reverse proxy to convey information to a backend server about the validated Token Binding Message received from a client, which enables that backend server to bind, or verify the binding of, cookies and other security tokens to the client's Token Binding key. This facilitates the reverse proxy and backend server functioning together as though they are a single logical server side deployment of HTTPS Token Binding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-05 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-ttrp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tokbind-ttrp-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000003b9e61056f417a68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
-05 is a pretty minor update to the TTRP draft. Changes copied from the doc history are listed below for easy/lazy reference.


=C2=A0=C2=A0 draft-ietf-tokbind-ttrp-05
=
=C2=A0=C2=A0 o=C2=A0 Editorial updates.

=C2=A0=C2=A0 o=C2=A0 Cha= nge one character in the last example to help emphasize the
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 case-insensitivity of hex.

=C2=A0=C2=A0 o=C2=A0 A= dd a TLS Versions and Best Practices section with BCP195 and also
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 mention of ietf-tokbind-tls13 and ietf-tls-tls13.<= br>


---------= - Forwarded message ----------
From: = <internet-drafts@ietf.org>
Date: Fri, Jun 22, 2018= at 3:05 PM
Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-05= .txt
To: i-d-= announce@ietf.org
Cc: unbearable@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Token Binding WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= HTTPS Token Binding with TLS Terminating Reverse Proxies
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tokbind-ttrp-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-06-22

Abstract:
=C2=A0 =C2=A0This document defines HTTP header fields that enable a TLS
=C2=A0 =C2=A0terminating reverse proxy to convey information to a backend s= erver
=C2=A0 =C2=A0about the validated Token Binding Message received from a clie= nt,
=C2=A0 =C2=A0which enables that backend server to bind, or verify the bindi= ng of,
=C2=A0 =C2=A0cookies and other security tokens to the client's Token Bi= nding key.
=C2=A0 =C2=A0This facilitates the reverse proxy and backend server function= ing
=C2=A0 =C2=A0together as though they are a single logical server side deplo= yment
=C2=A0 =C2=A0of HTTPS Token Binding.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-tokbind-ttrp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-to= kbind-ttrp-05
https://datatracker.ietf.org/do= c/html/draft-ietf-tokbind-ttrp-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-tokbind-ttrp-05


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearabl= e


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000003b9e61056f417a68-- From nobody Mon Jun 25 16:10:05 2018 Return-Path: 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 5CEC5130F09 for ; Mon, 25 Jun 2018 16:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 YcLp3C_3bEXW for ; Mon, 25 Jun 2018 16:10:01 -0700 (PDT) Received: from m69-169.mailgun.net (m69-169.mailgun.net [166.78.69.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF39C130EF8 for ; Mon, 25 Jun 2018 16:10:01 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1529968201; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=dPw4zg/gAWLiatgLgqoAib1rmeGx09Uu12e4P0QGQ+w=; b=uJGyyqfMZEXz+8F4Tdbs9cau5I53cn/hy1oa9bvevRZ6UhKc7PNyc9blm+wPAN2IQVjNlHIC 8mEAa4Un/sPbIyHmXj9rGIfIdhZrLTC9Jc8GBP8jJRQBVT8p7iy0W04PWSko5Tb8TSnpGqPa 3vVdiZ/zNrZOPFLLe5gQt6vCULA= X-Mailgun-Sending-Ip: 166.78.69.169 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Sender: andreipo=microsoft.com@github.com Received: from github.com (Unknown [192.30.252.40]) by mxa.mailgun.org with ESMTP id 5b317649.7f593c569b70-smtp-out-n02; Mon, 25 Jun 2018 23:10:01 -0000 (UTC) Date: Mon, 25 Jun 2018 16:10:00 -0700 From: Andrei Popov Reply-To: Andrei Popov To: unbearable@ietf.org Message-ID: <5b317648244f5_673d2ae83e38dc081091ad@hookshot-fe-d2afb11.cp1-iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_5b317648240ca_673d2ae83e38dc081090e8"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 234d5c: Clarifying Section 6 per GEN-ART review comments. X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 23:10:04 -0000 ----==_mimepart_5b317648240ca_673d2ae83e38dc081090e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 234d5c7c1711e076187b362c69a0deb6f25f3424 https://github.com/TokenBinding/Internet-Drafts/commit/234d5c7c1711e076187b362c69a0deb6f25f3424 Author: Andrei Popov Date: 2018-06-25 (Mon, 25 Jun 2018) Changed paths: M README.md R draft-ietf-tokbind-https-17.xml A draft-ietf-tokbind-https-18.xml Log Message: ----------- Clarifying Section 6 per GEN-ART review comments. **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019. ----==_mimepart_5b317648240ca_673d2ae83e38dc081090e8-- From nobody Mon Jun 25 16:30:59 2018 Return-Path: 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 909C9130EF2 for ; Mon, 25 Jun 2018 16:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 EVkXrCBWtMzs for ; Mon, 25 Jun 2018 16:30:52 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D391130F01 for ; Mon, 25 Jun 2018 16:30:49 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id j5-v6so22087ywe.8 for ; Mon, 25 Jun 2018 16:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ckjKHFj78N0jiPXwEyJov8tQ9CyM99EjCu6pUnJUSys=; b=eJJa/QogazOA3N5K+Y7yjsME2OcBwTJHqjdmHyXo2/qsSEYZKoMWme13zowhU2kfDu vfLT379RkkuFg0Z+yOjxlwVsm9kTNMfW/8paz+Sr7gpGvJTyZ+erb1duDlINR+1dUJGy 9V8zWEnRl9YxFTZL3qSdUv3E07okID3IClrs2gHWX+GzJrbOZwBMLDXq/famZS59pXi9 86pNJzm2zClGcx8gR2DM0q/p88EHaWuCmr26VJgqn8JE/WmoFGbvHw60b6VrbJD5x0xb /nlv8E2UpwO2n5WoB66Qexk38zGJ686HGK17C9LkrKjAH78Et0mKbaKrwPmFr1tJRnTZ 4CLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ckjKHFj78N0jiPXwEyJov8tQ9CyM99EjCu6pUnJUSys=; b=K3IV/x7hAX200eXO3HnVUNHCoz4+mgqTN5yznW6M+1vgYzPOZ1mF5X2FXvCCY9rhgr EaTan+jIvLCl5obaucyQtWXYVTVlTW/T0bHEjP/y+hQR/aXK3kuwokmPv5qPJWscqQiN Yac9jI3EjrAJc47JfL/8BC48/ry5h8Ohqgwf/q2h9uGm/L30+AbR/kc7/WwmOe6JDoUW ApTe7JLlSa/eRZCV2GKWamtD3oFgia1kABYV984Chg+OysT3FlAfA+waoiLnBlO4m5+C Igsh9FYNOti+tgZjCaphmL5zb2l4/WJCrwIUAQgWhu3965nQAA93o0gKLGFR+F+dH3Z7 zZFg== X-Gm-Message-State: APt69E3qs5bUM6p1rqEdJ8cZI+evXZ1aPJsTCIHpmIj338mScxWh5rlR cOLPmKJ2J8Q8mpX47iAqeNU+GFJTd5qz8oCRTOHZ/Q== X-Google-Smtp-Source: AAOMgpc3e6LOQbR6Bn6uwmb9U8Vg0pLJ0EWhfnb/SA+Gk75mO0M1B9zIM0SSSXQcwpLS+a9KIDVLZVHU7IGmortI6aU= X-Received: by 2002:a81:9194:: with SMTP id i142-v6mr5179230ywg.175.1529969448625; Mon, 25 Jun 2018 16:30:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 16:30:08 -0700 (PDT) In-Reply-To: References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Mon, 25 Jun 2018 16:30:08 -0700 Message-ID: To: Dirk Balfanz Cc: Ben Campbell , John Bradley , Tokbind WG , The IESG , tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org Content-Type: multipart/alternative; boundary="00000000000080c170056f7fc531" Archived-At: Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 23:30:55 -0000 --00000000000080c170056f7fc531 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ben, Does the following new text address your concern: https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=3Dhtml/asci= i&url=3Dhttps://raw.githubusercontent.com/TokenBinding/Internet-Drafts/mast= er/draft-ietf-tokbind-https-18.xml On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz < balfanz=3D40google.com@dmarc.ietf.org> wrote: > Hi Ben, > > thanks for the feedback. Most of it is addressed in the new draft ( > https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below > (inline) for details. > > On Wed, May 9, 2018 at 1:38 PM Ben Campbell wrote: > >> Ben Campbell has entered the following ballot position for >> draft-ietf-tokbind-https-14: 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.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I plan to ballot "YES", but I want to clear up once concern first: >> >> After reading section 6 several times, I don't know what it means. I >> think it's [...] >> > > Addressed in new draft. > > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Substantive Comments: >> >> =C2=A71.1: Please consider using the boilerplate from 8174 across the cl= uster. >> Both >> this and the protocol draft have lower case keyword instances. >> > > Addressed in new draft. > > >> >> =C2=A78.2: >> - Does it really make sense to wait for a user to request the keys be >> expired? >> I suspect the average user does this about never. Did the working group >> discuss >> possibly making the keys default to expiring after some period of time? > > > Yes, we did discuss it. This was chosen consciously to be in sync with > cookies and their expirations / manual user-initiated purges. > > - Why >> is the SHOULD in paragraph 2 not a MUST? >> > > Addressed in new draft. > > >> >> Editorial Comments: >> >> =C2=A72: >> - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in >> [RFC7230] >> style, see also Section 8.3 of [RFC7231]):" The open parenthesis before >> "in" >> seems misplaced. Also, as written the comma after "style" creates a comm= a >> splice. (Note that this pattern occurs elsewhere in the document.) >> >> - Paragraph 3: The paragraph is a single hard-to-parse sentence. Please >> consider breaking into simpler sentences. >> > > Addressed in new draft. > > >> >> - example: Am I correct to assume the backslashes are just for print >> purposes >> and are not in the actual message? If so, please mention that. >> > > Addressed in new draft. > > >> >> =C2=A7 2.1: >> - first paragraph, "Within the latter context...": There was no former >> context. >> I suggest "Within that context..." > > > Addressed in new draft. > > >> - 2nd paragraph: The first sentence is hard >> to parse. I suggest breaking it into separate paragraphs, or restructure >> without the center-imbedding. > > > Addressed in new draft. > > >> - 2nd to last paragraph: Does "SHOULD generally" >> mean the same as just "SHOULD"? >> > > Addressed in new draft. > > >> >> =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to another serv= er..." >> > > Addressed in new draft. > > >> >> =C2=A75.2, >> - last bullet: " (between client and Token Consumer)" seems more than >> parenthetical. Please consider removing the parentheses. > > > Addressed in new draft. > > >> - paragraph after last >> bullet: The parenthetical phrase starting with "(proving possession...) = is >> quite long and makes the sentence hard to parse. Given that the concept = is >> covered in the immediately preceding paragraph, can it be removed? >> > > Addressed in new draft. > > >> >> =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or resta= te >> requirements >> in) the protocol and negotiation drafts. Can they be included by referen= ce >> instead, or at least attributed? >> > > Addressed in new draft. > > >> >> =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77.1. >> > > Addressed in new draft. > > >> =C2=A78.3: Unneeded comma in first sentence. >> > > Addressed in new draft. > > Thanks again for the thoughtful comments! > > Dirk. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --00000000000080c170056f7fc531 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ben,

Does the following new = text address your concern:


On Mon, Ju= n 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=3D40google= .com@dmarc.ietf.org> wrote:
Hi Ben,=C2=A0

thanks for the feedback.= Most of it is addressed in the new draft (https://tools.ietf.or= g/html/draft-ietf-tokbind-https-16). See below (inline) for detail= s.

On W= ed, May 9, 2018 at 1:38 PM Ben Campbell <ben@nostrum.com> wrote:
Ben Campbell h= as entered the following ballot position for
draft-ietf-tokbind-https-14: 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/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-tokbind-https/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

I plan to ballot "YES", but I want to clear up once concern first= :

 After reading section 6 several times, I don't know what it means. I th= ink it's [...]

Addressed in new dra= ft.
=C2=A0

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Substantive Comments:

=C2=A71.1: Please consider using the boilerplate from 8174 across the clust= er. Both
this and the protocol draft have lower case keyword instances.

Addressed in new draft.
=C2=A0

=C2=A78.2:
- Does it really make sense to wait for a user to request the keys be expir= ed?
I suspect the average user does this about never. Did the working group dis= cuss
possibly making the keys default to expiring after some period of time?

Yes, we did discuss it. This was chose= n consciously to be in sync with cookies and their expirations / manual use= r-initiated purges.

- Why
is the SHOULD in paragraph 2 not a MUST?

Addressed in new draft.
=C2=A0

Editorial Comments:

=C2=A72:
- Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in = [RFC7230]
style, see also Section 8.3 of [RFC7231]):" The open parenthesis befor= e "in"
seems misplaced. Also, as written the comma after "style" creates= a comma
splice. (Note that this pattern occurs elsewhere in the document.)

- Paragraph 3: The paragraph is a single hard-to-parse sentence. Please
consider breaking into simpler sentences.

Addressed in new draft.
=C2=A0

- example: Am I correct to assume the backslashes are just for print purpos= es
and are not in the actual message? If so, please mention that.

Addressed in new draft.
=C2=A0

=C2=A7 2.1:
- first paragraph, "Within the latter context...": There was no f= ormer context.
I suggest "Within that context..."

Addr= essed in new draft.
=C2=A0
- 2nd paragraph: The first sen= tence is hard
to parse. I suggest breaking it into separate paragraphs, or restructure without the center-imbedding.

Addressed in new dr= aft.
=C2=A0
- 2nd to last paragraph: Does "SHOULD ge= nerally"
mean the same as just "SHOULD"?

Addr= essed in new draft.
=C2=A0

=C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to another se= rver..."

Addressed in new draft.
=C2=A0

=C2=A75.2,
- last bullet: " (between client and Token Consumer)" seems more = than
parenthetical. Please consider removing the parentheses.
=
Addressed in new draft.
=C2= =A0
- paragraph afte= r last
bullet: The parenthetical phrase starting with "(proving possession...= ) is
quite long and makes the sentence hard to parse. Given that the concept is<= br> covered in the immediately preceding paragraph, can it be removed?

Addressed in new draft.
<= div>=C2=A0

=C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or restate = requirements
in) the protocol and negotiation drafts. Can they be included by reference<= br> instead, or at least attributed?

Addressed in = new draft.
=C2=A0

=C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77.1.

Addressed in new draft.=C2=A0


=C2=A78.3: Unneeded comma in first sentence.

A= ddressed in new draft.

Thanks again for the= thoughtful comments!
<= div>
Dirk.

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e


--00000000000080c170056f7fc531-- From nobody Tue Jun 26 11:41:45 2018 Return-Path: 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 485621310FC; Tue, 26 Jun 2018 11:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bzfV0r-arR-V; Tue, 26 Jun 2018 11:41:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6E81310FD; Tue, 26 Jun 2018 11:41:34 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5QIfGjO082135 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Jun 2018 13:41:20 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B0A8960D-3DE0-4750-9190-5D1A6175276F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 26 Jun 2018 13:41:09 -0500 In-Reply-To: Cc: Dirk Balfanz , draft-ietf-tokbind-https@ietf.org, Tokbind WG , The IESG , John Bradley , tokbind-chairs@ietf.org To: Eric Rescorla References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:41:39 -0000 --Apple-Mail=_B0A8960D-3DE0-4750-9190-5D1A6175276F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, thanks for the pointer. The text in version 18 is sufficient to clear my discuss. I have one = remaining (or maybe new) non-blocking question for section 6: Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as = those from paragraph 2? It seems like paragraph 2 is talking more about = local APIs (at least, I see that was mentioned in the text in version 17 = but not in 18), but paragraph 3 uses an example of a signal from a = server. (I can accept that the difference in control may be weak enough = for web applications that the distinction does not matter.) I did not check my editorial comments. Thanks! Ben. > On Jun 25, 2018, at 6:30 PM, Eric Rescorla wrote: >=20 > Ben, >=20 > Does the following new text address your concern: > = https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=3Dhtml/asc= ii&url=3Dhttps://raw.githubusercontent.com/TokenBinding/Internet-Drafts/ma= ster/draft-ietf-tokbind-https-18.xml >=20 >=20 > On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz = wrote: > Hi Ben, >=20 > thanks for the feedback. Most of it is addressed in the new draft = (https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below = (inline) for details. >=20 > On Wed, May 9, 2018 at 1:38 PM Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-tokbind-https-14: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I plan to ballot "YES", but I want to clear up once concern first: >=20 > After reading section 6 several times, I don't know what it means. I = think it's [...] >=20 > Addressed in new draft. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Substantive Comments: >=20 > =C2=A71.1: Please consider using the boilerplate from 8174 across the = cluster. Both > this and the protocol draft have lower case keyword instances. >=20 > Addressed in new draft. >=20 >=20 > =C2=A78.2: > - Does it really make sense to wait for a user to request the keys be = expired? > I suspect the average user does this about never. Did the working = group discuss > possibly making the keys default to expiring after some period of = time? >=20 > Yes, we did discuss it. This was chosen consciously to be in sync with = cookies and their expirations / manual user-initiated purges. >=20 > - Why > is the SHOULD in paragraph 2 not a MUST? >=20 > Addressed in new draft. >=20 >=20 > Editorial Comments: >=20 > =C2=A72: > - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in = [RFC7230] > style, see also Section 8.3 of [RFC7231]):" The open parenthesis = before "in" > seems misplaced. Also, as written the comma after "style" creates a = comma > splice. (Note that this pattern occurs elsewhere in the document.) >=20 > - Paragraph 3: The paragraph is a single hard-to-parse sentence. = Please > consider breaking into simpler sentences. >=20 > Addressed in new draft. >=20 >=20 > - example: Am I correct to assume the backslashes are just for print = purposes > and are not in the actual message? If so, please mention that. >=20 > Addressed in new draft. >=20 >=20 > =C2=A7 2.1: > - first paragraph, "Within the latter context...": There was no former = context. > I suggest "Within that context..." >=20 > Addressed in new draft. >=20 > - 2nd paragraph: The first sentence is hard > to parse. I suggest breaking it into separate paragraphs, or = restructure > without the center-imbedding. >=20 > Addressed in new draft. >=20 > - 2nd to last paragraph: Does "SHOULD generally" > mean the same as just "SHOULD"? >=20 > Addressed in new draft. >=20 >=20 > =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to another = server..." >=20 > Addressed in new draft. >=20 >=20 > =C2=A75.2, > - last bullet: " (between client and Token Consumer)" seems more than > parenthetical. Please consider removing the parentheses. >=20 > Addressed in new draft. >=20 > - paragraph after last > bullet: The parenthetical phrase starting with "(proving = possession...) is > quite long and makes the sentence hard to parse. Given that the = concept is > covered in the immediately preceding paragraph, can it be removed? >=20 > Addressed in new draft. >=20 >=20 > =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or = restate requirements > in) the protocol and negotiation drafts. Can they be included by = reference > instead, or at least attributed? >=20 > Addressed in new draft. >=20 >=20 > =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77.1. >=20 > Addressed in new draft. >=20 >=20 > =C2=A78.3: Unneeded comma in first sentence. >=20 > Addressed in new draft. >=20 > Thanks again for the thoughtful comments! >=20 > Dirk. >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable >=20 >=20 --Apple-Mail=_B0A8960D-3DE0-4750-9190-5D1A6175276F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsyiMUACgkQgFZKbJXz 1A0kTA//ehwM2fcF8je+J7LajNC3bbfKdqr/kyhcMa369BFqNCZL8gnmFqLXJAuS AseQFKUT3+eKSHOE6rgQ3yJ4T0cVIEXcBJ89cZIcTg47Dsgksjohvzk1+cB1Suy/ wIKms+OfljLcX+RSp5u9XH+bHn+0oD+3pHZ7c3LSWsdkm4/PpsPNk7trpYHLPVmx tnGIaItzGka9qXaMaIfvE4lB0jZ30DS0nmLzB5lz8dm3trrJnjm7RUurjWCu52uK bwUnNCoa4FddHiLaic2ezQnVtu14BD/Ji6Yvo5DnNU7qf+R8Js6LlFqm4ZY8Kn9g 0NCZUiBas5+5NvJTxCiz4gluHc6nDhJlIECUOimclBWxHDwFcJwR1DofZMSPf3GC /BlE1vi0VTot4MF4Dk923KI3ylXnIShlmGa1eGT5bLCagyvnHbF0ltUs4GsMExLY JFWfUCpUHSzLdUuLm0SHH5P6v5tbitKEXiyhZZn3aniFUAUstbyiNl0PvjyP4zex z9BuvfjSjnzRaCtRntDMf2UJtDqtxGiS9iUiBfEMnCidhUIU3jC7M8AY6LcdZONq 28ZjoARtP/0OhMtQVuXlDA1u8jUv/yIQ2O+ao/fR1GFQ+Gcl9c052oSGgW5uxkzU pASmLfaJH2lNaCP4N9UD76v/15D9d7ZWPpXM98JEhRv0SnS8P5w= =JYkm -----END PGP SIGNATURE----- --Apple-Mail=_B0A8960D-3DE0-4750-9190-5D1A6175276F-- From nobody Tue Jun 26 11:43:07 2018 Return-Path: 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 32ACE13110D; Tue, 26 Jun 2018 11:42:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-tokbind-https@ietf.org, John Bradley , tokbind-chairs@ietf.org, ve7jtb@ve7jtb.com, unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153003857719.18839.13626712531775084980.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2018 11:42:57 -0700 Archived-At: Subject: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-https-17: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:43:04 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tokbind-https-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://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: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and substantive comments in pre-submission text. I did not check editorial comments. I have one remaining (non-blocking) question on section 6: Are the “applications” from paragraph 3 the same as those from paragraph 2? It seems like paragraph 2 is talking more about local APIs (at least, I see that was mentioned in the text in version 17 but not in 18), but paragraph 3 uses an example of a signal from a server. (I can accept that the difference in control may be weak enough for web applications that the distinction does not matter.) From nobody Tue Jun 26 11:55:18 2018 Return-Path: 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 834AE13111B; Tue, 26 Jun 2018 11:54:55 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 JnDf_zSShoU3; Tue, 26 Jun 2018 11:54:50 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680091.outbound.protection.outlook.com [40.107.68.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703F9130E14; Tue, 26 Jun 2018 11:54:50 -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:X-MS-Exchange-SenderADCheck; bh=F316XmDLTte21G2eJRWux+I5TRPaGIb0p9tkWipWi/k=; b=Vo0mgwX+Y18UWsSO8le8jmOP8vtDLI5ef9x1cxFIrmqVR5KWcRArF4QEipS1KR25qVjHuR3gtdVtY2Q3qNpZiYTfq3BHEuNRL9+fhJd4RGMSj1n3KhPy8/0yPeOGNaoS2dYOt+bI3wUh79whAnG3VDz/jrsrE5XC6+8DIbmJHHw= Received: from CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) by CY4PR21MB0776.namprd21.prod.outlook.com (10.173.192.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.2; Tue, 26 Jun 2018 18:54:48 +0000 Received: from CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::9d01:113b:290a:750b]) by CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::9d01:113b:290a:750b%3]) with mapi id 15.20.0930.005; Tue, 26 Jun 2018 18:54:48 +0000 From: Andrei Popov To: Ben Campbell , Eric Rescorla CC: Dirk Balfanz , "draft-ietf-tokbind-https@ietf.org" , Tokbind WG , The IESG , John Bradley , "tokbind-chairs@ietf.org" Thread-Topic: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) Thread-Index: AQHT59XA5IIayh1w/kSwtbPg5+4zz6RQtRGAgCE0KwCAAUGXgIAAAMlw Date: Tue, 26 Jun 2018 18:54:47 +0000 Message-ID: References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> In-Reply-To: <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:8:28b5:a023:971b:e42c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0776; 7:DjXpLgRc5EUIsz4ucG3wFp9pwL86kBTk/gQLAEx+8m9sf4lh7DBqbxNE5aCwxbB4Wc5BE+u/6L8G+7QAeSMEu24czw3ZIqa/X3+rAM7N0oapzvnFQDJtNe2v78fjyhJ1IhM9F6KfsIG10I5pTjObOpfsqIYjSBV2MIphAQbMOqZDc5uobBNV/aDFPPL4DgSqic/nWWUFBcj5mvguoZ0j4jdLapucLOqYPpOzwHYPjrlfUWM1rw6jpJEKZQkyBKFj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6569ec09-6894-4dbc-6934-08d5db964a42 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0776; x-ms-traffictypediagnostic: CY4PR21MB0776: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(120809045254105)(275740015457677); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:CY4PR21MB0776; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0776; x-forefront-prvs: 071518EF63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(136003)(366004)(396003)(346002)(51914003)(199004)(13464003)(189003)(256004)(186003)(486006)(55016002)(99286004)(2906002)(11346002)(476003)(14444005)(446003)(6306002)(9686003)(53546011)(8936002)(7696005)(6116002)(229853002)(76176011)(68736007)(86362001)(6436002)(5660300001)(106356001)(110136005)(10090500001)(5250100002)(97736004)(54906003)(86612001)(53936002)(46003)(33656002)(6246003)(22452003)(316002)(72206003)(478600001)(14454004)(305945005)(6506007)(4326008)(966005)(81156014)(7736002)(81166006)(74316002)(8676002)(10290500003)(8990500004)(2900100001)(93886005)(25786009)(105586002)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0776; H:CY4PR21MB0774.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) x-microsoft-antispam-message-info: B+2Nu40W3KtmQIRX8uRo54vPzInPH0OLZ3RDLvH/QdqmVOwzz9vcz8K/XIfteowwrIa+CFzH7TggFu2/eMf5jQriX8+nQ3AHZcBMI4ommVmVIIhDxQJIoqXcUAHJA6nEepnAHyo2B19io2sdEUR0tYOYED2gzSLKdaPcp2S5tqaMeK6Lv1QJt5XeETL/WD+pNQ6mvr+9AjLqc+N7is6Pam80TAxwv+UOh4EQHU+2QV3bGVhioM8r5gbyYbcReFrPtoeq9YUcKEXmxcBBeDTMOiMWMaE3s/CpOieZQO5IM3FYDY2KwE3wWbRQAxK6Mc8WyQo9z+XwdgZSS/r7dmab9nzDE1RBMKJgGVviwSMoCm0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6569ec09-6894-4dbc-6934-08d5db964a42 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 18:54:47.8185 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0776 Archived-At: Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:55:05 -0000 SGkgQmVuLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuDQoNCj4gQXJlIHRoZSDigJxhcHBsaWNh dGlvbnPigJ0gZnJvbSBwYXJhZ3JhcGggMyB0aGUgc2FtZSBhcyB0aG9zZSBmcm9tIHBhcmFncmFw aCAyPw0KDQpZZXMsIHRoZSBzYW1lIHRocm91Z2hvdXQgcGFyYWdyYXBocyAxLCAyIGFuZCAzLg0K DQo+IEl0IHNlZW1zIGxpa2UgcGFyYWdyYXBoIDIgaXMgdGFsa2luZyBtb3JlIGFib3V0IGxvY2Fs IEFQSXMgKGF0IGxlYXN0LCBJIHNlZSB0aGF0IHdhcyBtZW50aW9uZWQgaW4gdGhlIHRleHQgaW4g dmVyc2lvbiAxNyBidXQgbm90IGluIDE4KSwgYnV0IHBhcmFncmFwaCAzIHVzZXMgYW4gZXhhbXBs ZSBvZiBhIHNpZ25hbCBmcm9tIGEgc2VydmVyLiAoSSBjYW4gYWNjZXB0IHRoYXQgdGhlIGRpZmZl cmVuY2UgaW4gY29udHJvbCBtYXkgYmUgd2VhayBlbm91Z2ggZm9yIHdlYiBhcHBsaWNhdGlvbnMg dGhhdCB0aGUgZGlzdGluY3Rpb24gZG9lcyBub3QgbWF0dGVyLikNCg0KVGhlIEFQSXMgcHJvdmlk ZWQgYnkgdGhlIFRCIGltcGxlbWVudGF0aW9uIGFuZCBjYWxsZWQgYnkgdGhlIGFwcGxpY2F0aW9u IGFyZSBsb2NhbCBBUElzLg0KVGhlIGFwcGxpY2F0aW9uIG5lZWRzIHRvIG1ha2UgYSBkZWNpc2lv biB3aGV0aGVyIHRvIHJlcXVlc3QgdGhhdCB0aGUgVEIgaW1wbGVtZW50YXRpb24gaW5jbHVkZSBh IFJlZmVycmVkIGJpbmRpbmcgaW4gdGhlIFRCIG1lc3NhZ2Ugb3Igbm90Lg0KSW4gdGhlIGV4YW1w bGUsIHRoZSBzZXJ2ZXIgcHJvdmlkZXMgYSBzaWduYWwgdG8gdGhlIGFwcGxpY2F0aW9uIHVzaW5n IHRoZSBJbmNsdWRlLVJlZmVycmVkLVRva2VuLUJpbmRpbmctSUQgSFRUUCByZXNwb25zZSBoZWFk ZXIuDQpUaGUgc2lnbmFsIGNvdWxkIGJlIGRpZmZlcmVudCwgb3IgYW4gYXBwbGljYXRpb24gbWF5 IGhhdmUgb3V0LW9mLWJhbmQgd2F5cyB0byBkZXRlcm1pbmUgdGhpcyAoZS5nLiBhIGxvY2FsIGRh dGFiYXNlIG9mIFJQLT5JRFAgYXNzb2NpYXRpb25zKS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3Ry dW0uY29tPiANClNlbnQ6IFR1ZXNkYXksIEp1bmUgMjYsIDIwMTggMTE6NDEgQU0NClRvOiBFcmlj IFJlc2NvcmxhIDxla3JAcnRmbS5jb20+DQpDYzogRGlyayBCYWxmYW56IDxiYWxmYW56PTQwZ29v Z2xlLmNvbUBkbWFyYy5pZXRmLm9yZz47IGRyYWZ0LWlldGYtdG9rYmluZC1odHRwc0BpZXRmLm9y ZzsgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPjsgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT47IHRva2JpbmQtY2hhaXJzQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTE0OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KQ0KDQpIaSwgdGhhbmtzIGZvciB0aGUgcG9pbnRlci4NCg0KVGhlIHRleHQgaW4gdmVyc2lvbiAx OCBpcyBzdWZmaWNpZW50IHRvIGNsZWFyIG15IGRpc2N1c3MuIEkgaGF2ZSBvbmUgcmVtYWluaW5n IChvciBtYXliZSBuZXcpIG5vbi1ibG9ja2luZyBxdWVzdGlvbiBmb3Igc2VjdGlvbiA2Og0KDQpB cmUgdGhlIOKAnGFwcGxpY2F0aW9uc+KAnSBmcm9tIHBhcmFncmFwaCAzIHRoZSBzYW1lIGFzIHRo b3NlIGZyb20gcGFyYWdyYXBoIDI/IEl0IHNlZW1zIGxpa2UgcGFyYWdyYXBoIDIgaXMgdGFsa2lu ZyBtb3JlIGFib3V0IGxvY2FsIEFQSXMgKGF0IGxlYXN0LCBJIHNlZSB0aGF0IHdhcyBtZW50aW9u ZWQgaW4gdGhlIHRleHQgaW4gdmVyc2lvbiAxNyBidXQgbm90IGluIDE4KSwgYnV0IHBhcmFncmFw aCAzIHVzZXMgYW4gZXhhbXBsZSBvZiBhIHNpZ25hbCBmcm9tIGEgc2VydmVyLiAoSSBjYW4gYWNj ZXB0IHRoYXQgdGhlIGRpZmZlcmVuY2UgaW4gY29udHJvbCBtYXkgYmUgd2VhayBlbm91Z2ggZm9y IHdlYiBhcHBsaWNhdGlvbnMgdGhhdCB0aGUgZGlzdGluY3Rpb24gZG9lcyBub3QgbWF0dGVyLikN Cg0KSSBkaWQgbm90IGNoZWNrIG15IGVkaXRvcmlhbCBjb21tZW50cy4NCg0KVGhhbmtzIQ0KDQpC ZW4uDQoNCj4gT24gSnVuIDI1LCAyMDE4LCBhdCA2OjMwIFBNLCBFcmljIFJlc2NvcmxhIDxla3JA cnRmbS5jb20+IHdyb3RlOg0KPiANCj4gQmVuLA0KPiANCj4gRG9lcyB0aGUgZm9sbG93aW5nIG5l dyB0ZXh0IGFkZHJlc3MgeW91ciBjb25jZXJuOg0KPiBodHRwczovL3htbDJyZmMudG9vbHMuaWV0 Zi5vcmcvY2dpLWJpbi94bWwycmZjLmNnaT9tb2RlQXNGb3JtYXQ9aHRtbC9hDQo+IHNjaWkmdXJs PWh0dHBzOi8vcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQt RHJhZnQNCj4gcy9tYXN0ZXIvZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTE4LnhtbA0KPiANCj4g DQo+IE9uIE1vbiwgSnVuIDQsIDIwMTggYXQgMToyNiBQTSwgRGlyayBCYWxmYW56IDxiYWxmYW56 PTQwZ29vZ2xlLi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiBIaSBCZW4sDQo+IA0KPiB0 aGFua3MgZm9yIHRoZSBmZWVkYmFjay4gTW9zdCBvZiBpdCBpcyBhZGRyZXNzZWQgaW4gdGhlIG5l dyBkcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1o dHRwcy0xNikuIFNlZSBiZWxvdyAoaW5saW5lKSBmb3IgZGV0YWlscy4NCj4gDQo+IE9uIFdlZCwg TWF5IDksIDIwMTggYXQgMTozOCBQTSBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4gd3Jv dGU6DQo+IEJlbiBDYW1wYmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCj4gZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTE0OiBEaXNjdXNzDQo+IA0KPiBX aGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCBy ZXBseSB0byBhbGwgDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCANCj4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBo LCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiAN Cj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBj YW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi10b2tiaW5kLWh0dHBzLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJ U0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEkgcGxhbiB0byBiYWxsb3QgIllFUyIsIGJ1 dCBJIHdhbnQgdG8gY2xlYXIgdXAgb25jZSBjb25jZXJuIGZpcnN0Og0KPiANCj4gQWZ0ZXIgcmVh ZGluZyBzZWN0aW9uIDYgc2V2ZXJhbCB0aW1lcywgSSBkb24ndCBrbm93IHdoYXQgaXQgbWVhbnMu IEkgDQo+IHRoaW5rIGl0J3MgWy4uLl0NCj4gDQo+IEFkZHJlc3NlZCBpbiBuZXcgZHJhZnQuDQo+ IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K PiBTdWJzdGFudGl2ZSBDb21tZW50czoNCj4gDQo+IMKnMS4xOiBQbGVhc2UgY29uc2lkZXIgdXNp bmcgdGhlIGJvaWxlcnBsYXRlIGZyb20gODE3NCBhY3Jvc3MgdGhlIA0KPiBjbHVzdGVyLiBCb3Ro IHRoaXMgYW5kIHRoZSBwcm90b2NvbCBkcmFmdCBoYXZlIGxvd2VyIGNhc2Uga2V5d29yZCBpbnN0 YW5jZXMuDQo+IA0KPiBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Lg0KPiANCj4gDQo+IMKnOC4yOg0K PiAtIERvZXMgaXQgcmVhbGx5IG1ha2Ugc2Vuc2UgdG8gd2FpdCBmb3IgYSB1c2VyIHRvIHJlcXVl c3QgdGhlIGtleXMgYmUgZXhwaXJlZD8NCj4gSSBzdXNwZWN0IHRoZSBhdmVyYWdlIHVzZXIgZG9l cyB0aGlzIGFib3V0IG5ldmVyLiBEaWQgdGhlIHdvcmtpbmcgDQo+IGdyb3VwIGRpc2N1c3MgcG9z c2libHkgbWFraW5nIHRoZSBrZXlzIGRlZmF1bHQgdG8gZXhwaXJpbmcgYWZ0ZXIgc29tZSBwZXJp b2Qgb2YgdGltZT8NCj4gDQo+IFllcywgd2UgZGlkIGRpc2N1c3MgaXQuIFRoaXMgd2FzIGNob3Nl biBjb25zY2lvdXNseSB0byBiZSBpbiBzeW5jIHdpdGggY29va2llcyBhbmQgdGhlaXIgZXhwaXJh dGlvbnMgLyBtYW51YWwgdXNlci1pbml0aWF0ZWQgcHVyZ2VzLg0KPiANCj4gLSBXaHkNCj4gaXMg dGhlIFNIT1VMRCBpbiBwYXJhZ3JhcGggMiBub3QgYSBNVVNUPw0KPiANCj4gQWRkcmVzc2VkIGlu IG5ldyBkcmFmdC4NCj4gDQo+IA0KPiBFZGl0b3JpYWwgQ29tbWVudHM6DQo+IA0KPiDCpzI6DQo+ IC0gUGFyYWdyYXBoIDE6ICJUaGUgQUJORiBvZiB0aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVy IGZpZWxkIGlzIChpbiANCj4gW1JGQzcyMzBdIHN0eWxlLCBzZWUgYWxzbyBTZWN0aW9uIDguMyBv ZiBbUkZDNzIzMV0pOiIgVGhlIG9wZW4gcGFyZW50aGVzaXMgYmVmb3JlICJpbiINCj4gc2VlbXMg bWlzcGxhY2VkLiBBbHNvLCBhcyB3cml0dGVuIHRoZSBjb21tYSBhZnRlciAic3R5bGUiIGNyZWF0 ZXMgYSANCj4gY29tbWEgc3BsaWNlLiAoTm90ZSB0aGF0IHRoaXMgcGF0dGVybiBvY2N1cnMgZWxz ZXdoZXJlIGluIHRoZSANCj4gZG9jdW1lbnQuKQ0KPiANCj4gLSBQYXJhZ3JhcGggMzogVGhlIHBh cmFncmFwaCBpcyBhIHNpbmdsZSBoYXJkLXRvLXBhcnNlIHNlbnRlbmNlLiANCj4gUGxlYXNlIGNv bnNpZGVyIGJyZWFraW5nIGludG8gc2ltcGxlciBzZW50ZW5jZXMuDQo+IA0KPiBBZGRyZXNzZWQg aW4gbmV3IGRyYWZ0Lg0KPiANCj4gDQo+IC0gZXhhbXBsZTogQW0gSSBjb3JyZWN0IHRvIGFzc3Vt ZSB0aGUgYmFja3NsYXNoZXMgYXJlIGp1c3QgZm9yIHByaW50IA0KPiBwdXJwb3NlcyBhbmQgYXJl IG5vdCBpbiB0aGUgYWN0dWFsIG1lc3NhZ2U/IElmIHNvLCBwbGVhc2UgbWVudGlvbiB0aGF0Lg0K PiANCj4gQWRkcmVzc2VkIGluIG5ldyBkcmFmdC4NCj4gDQo+IA0KPiDCpyAyLjE6DQo+IC0gZmly c3QgcGFyYWdyYXBoLCAiV2l0aGluIHRoZSBsYXR0ZXIgY29udGV4dC4uLiI6IFRoZXJlIHdhcyBu byBmb3JtZXIgY29udGV4dC4NCj4gSSBzdWdnZXN0ICJXaXRoaW4gdGhhdCBjb250ZXh0Li4uIg0K PiANCj4gQWRkcmVzc2VkIGluIG5ldyBkcmFmdC4NCj4gDQo+IC0gMm5kIHBhcmFncmFwaDogVGhl IGZpcnN0IHNlbnRlbmNlIGlzIGhhcmQgdG8gcGFyc2UuIEkgc3VnZ2VzdCANCj4gYnJlYWtpbmcg aXQgaW50byBzZXBhcmF0ZSBwYXJhZ3JhcGhzLCBvciByZXN0cnVjdHVyZSB3aXRob3V0IHRoZSAN Cj4gY2VudGVyLWltYmVkZGluZy4NCj4gDQo+IEFkZHJlc3NlZCBpbiBuZXcgZHJhZnQuDQo+IA0K PiAtIDJuZCB0byBsYXN0IHBhcmFncmFwaDogRG9lcyAiU0hPVUxEIGdlbmVyYWxseSINCj4gbWVh biB0aGUgc2FtZSBhcyBqdXN0ICJTSE9VTEQiPw0KPiANCj4gQWRkcmVzc2VkIGluIG5ldyBkcmFm dC4NCj4gDQo+IA0KPiDCpzUuMTogMm5kIHBhcmFncmFwaDogVW5uZWVkZWQgY29tbWEgaW4gIi4u LiBpdHNlbGYsIHRvIGFub3RoZXIgc2VydmVyLi4uIg0KPiANCj4gQWRkcmVzc2VkIGluIG5ldyBk cmFmdC4NCj4gDQo+IA0KPiDCpzUuMiwNCj4gLSBsYXN0IGJ1bGxldDogIiAoYmV0d2VlbiBjbGll bnQgYW5kIFRva2VuIENvbnN1bWVyKSIgc2VlbXMgbW9yZSB0aGFuIA0KPiBwYXJlbnRoZXRpY2Fs LiBQbGVhc2UgY29uc2lkZXIgcmVtb3ZpbmcgdGhlIHBhcmVudGhlc2VzLg0KPiANCj4gQWRkcmVz c2VkIGluIG5ldyBkcmFmdC4NCj4gDQo+IC0gcGFyYWdyYXBoIGFmdGVyIGxhc3QNCj4gYnVsbGV0 OiBUaGUgcGFyZW50aGV0aWNhbCBwaHJhc2Ugc3RhcnRpbmcgd2l0aCAiKHByb3ZpbmcgDQo+IHBv c3Nlc3Npb24uLi4pIGlzIHF1aXRlIGxvbmcgYW5kIG1ha2VzIHRoZSBzZW50ZW5jZSBoYXJkIHRv IHBhcnNlLiANCj4gR2l2ZW4gdGhhdCB0aGUgY29uY2VwdCBpcyBjb3ZlcmVkIGluIHRoZSBpbW1l ZGlhdGVseSBwcmVjZWRpbmcgcGFyYWdyYXBoLCBjYW4gaXQgYmUgcmVtb3ZlZD8NCj4gDQo+IEFk ZHJlc3NlZCBpbiBuZXcgZHJhZnQuDQo+IA0KPiANCj4gwqc3LjEgYW5kIMKnNy4yOiBUaGVzZSBz ZWN0aW9ucyBzZWVtIHRvIGJlIGNvcGllZCBmcm9tIChvciByZXN0YXRlIA0KPiByZXF1aXJlbWVu dHMNCj4gaW4pIHRoZSBwcm90b2NvbCBhbmQgbmVnb3RpYXRpb24gZHJhZnRzLiBDYW4gdGhleSBi ZSBpbmNsdWRlZCBieSANCj4gcmVmZXJlbmNlIGluc3RlYWQsIG9yIGF0IGxlYXN0IGF0dHJpYnV0 ZWQ/DQo+IA0KPiBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Lg0KPiANCj4gDQo+IMKnNy4yLCAybmQg cGFyYWdyYXBoOiBUaGlzIHNlYW1zIGxpa2UgYSByZXN0YXRlbWVudCBvZiDCpzcuMS4NCj4gDQo+ IEFkZHJlc3NlZCBpbiBuZXcgZHJhZnQuDQo+IA0KPiANCj4gwqc4LjM6IFVubmVlZGVkIGNvbW1h IGluIGZpcnN0IHNlbnRlbmNlLg0KPiANCj4gQWRkcmVzc2VkIGluIG5ldyBkcmFmdC4NCj4gDQo+ IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIHRob3VnaHRmdWwgY29tbWVudHMhDQo+IA0KPiBEaXJrLg0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g VW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNCj4gVW5iZWFyYWJsZUBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCj4gDQo+IA0KDQo= From nobody Tue Jun 26 11:58:36 2018 Return-Path: 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 8B2451310FF; Tue, 26 Jun 2018 11:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7JzoaN8dHsWc; Tue, 26 Jun 2018 11:58:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E55D13112A; Tue, 26 Jun 2018 11:58:26 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5QIwLKV085852 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Jun 2018 13:58:22 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8123AB76-087C-486C-A9F5-CD243AE1B04C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 26 Jun 2018 13:58:20 -0500 In-Reply-To: Cc: Eric Rescorla , Dirk Balfanz , "draft-ietf-tokbind-https@ietf.org" , Tokbind WG , The IESG , John Bradley , "tokbind-chairs@ietf.org" To: Andrei Popov References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:58:32 -0000 --Apple-Mail=_8123AB76-087C-486C-A9F5-CD243AE1B04C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 26, 2018, at 1:54 PM, Andrei Popov = wrote: >=20 > Hi Ben, >=20 > Thanks for the review. >=20 >> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as = those from paragraph 2? >=20 > Yes, the same throughout paragraphs 1, 2 and 3. >=20 >> It seems like paragraph 2 is talking more about local APIs (at least, = I see that was mentioned in the text in version 17 but not in 18), but = paragraph 3 uses an example of a signal from a server. (I can accept = that the difference in control may be weak enough for web applications = that the distinction does not matter.) >=20 > The APIs provided by the TB implementation and called by the = application are local APIs. > The application needs to make a decision whether to request that the = TB implementation include a Referred binding in the TB message or not. > In the example, the server provides a signal to the application using = the Include-Referred-Token-Binding-ID HTTP response header. > The signal could be different, or an application may have out-of-band = ways to determine this (e.g. a local database of RP->IDP associations). I just re-read the 3rd paragraph, and I think I missed the =E2=80=9Cthen=E2= =80=9D in =E2=80=9Cwhich then signals=E2=80=9D on the first reading. = It=E2=80=99s fine as is. Thanks! Ben. >=20 > Cheers, >=20 > Andrei >=20 > -----Original Message----- > From: Ben Campbell > Sent: Tuesday, June 26, 2018 11:41 AM > To: Eric Rescorla > Cc: Dirk Balfanz ; = draft-ietf-tokbind-https@ietf.org; Tokbind WG ; The = IESG ; John Bradley ; = tokbind-chairs@ietf.org > Subject: Re: [Unbearable] Ben Campbell's Discuss on = draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) >=20 > Hi, thanks for the pointer. >=20 > The text in version 18 is sufficient to clear my discuss. I have one = remaining (or maybe new) non-blocking question for section 6: >=20 > Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as = those from paragraph 2? It seems like paragraph 2 is talking more about = local APIs (at least, I see that was mentioned in the text in version 17 = but not in 18), but paragraph 3 uses an example of a signal from a = server. (I can accept that the difference in control may be weak enough = for web applications that the distinction does not matter.) >=20 > I did not check my editorial comments. >=20 > Thanks! >=20 > Ben. >=20 >> On Jun 25, 2018, at 6:30 PM, Eric Rescorla wrote: >>=20 >> Ben, >>=20 >> Does the following new text address your concern: >> = https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=3Dhtml/a >> = scii&url=3Dhttps://raw.githubusercontent.com/TokenBinding/Internet-Draft >> s/master/draft-ietf-tokbind-https-18.xml >>=20 >>=20 >> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz = wrote: >> Hi Ben, >>=20 >> thanks for the feedback. Most of it is addressed in the new draft = (https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below = (inline) for details. >>=20 >> On Wed, May 9, 2018 at 1:38 PM Ben Campbell wrote: >> Ben Campbell has entered the following ballot position for >> draft-ietf-tokbind-https-14: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I plan to ballot "YES", but I want to clear up once concern first: >>=20 >> After reading section 6 several times, I don't know what it means. I >> think it's [...] >>=20 >> Addressed in new draft. >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Substantive Comments: >>=20 >> =C2=A71.1: Please consider using the boilerplate from 8174 across the >> cluster. Both this and the protocol draft have lower case keyword = instances. >>=20 >> Addressed in new draft. >>=20 >>=20 >> =C2=A78.2: >> - Does it really make sense to wait for a user to request the keys be = expired? >> I suspect the average user does this about never. Did the working >> group discuss possibly making the keys default to expiring after some = period of time? >>=20 >> Yes, we did discuss it. This was chosen consciously to be in sync = with cookies and their expirations / manual user-initiated purges. >>=20 >> - Why >> is the SHOULD in paragraph 2 not a MUST? >>=20 >> Addressed in new draft. >>=20 >>=20 >> Editorial Comments: >>=20 >> =C2=A72: >> - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in >> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The open = parenthesis before "in" >> seems misplaced. Also, as written the comma after "style" creates a >> comma splice. (Note that this pattern occurs elsewhere in the >> document.) >>=20 >> - Paragraph 3: The paragraph is a single hard-to-parse sentence. >> Please consider breaking into simpler sentences. >>=20 >> Addressed in new draft. >>=20 >>=20 >> - example: Am I correct to assume the backslashes are just for print >> purposes and are not in the actual message? If so, please mention = that. >>=20 >> Addressed in new draft. >>=20 >>=20 >> =C2=A7 2.1: >> - first paragraph, "Within the latter context...": There was no = former context. >> I suggest "Within that context..." >>=20 >> Addressed in new draft. >>=20 >> - 2nd paragraph: The first sentence is hard to parse. I suggest >> breaking it into separate paragraphs, or restructure without the >> center-imbedding. >>=20 >> Addressed in new draft. >>=20 >> - 2nd to last paragraph: Does "SHOULD generally" >> mean the same as just "SHOULD"? >>=20 >> Addressed in new draft. >>=20 >>=20 >> =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to another = server..." >>=20 >> Addressed in new draft. >>=20 >>=20 >> =C2=A75.2, >> - last bullet: " (between client and Token Consumer)" seems more than >> parenthetical. Please consider removing the parentheses. >>=20 >> Addressed in new draft. >>=20 >> - paragraph after last >> bullet: The parenthetical phrase starting with "(proving >> possession...) is quite long and makes the sentence hard to parse. >> Given that the concept is covered in the immediately preceding = paragraph, can it be removed? >>=20 >> Addressed in new draft. >>=20 >>=20 >> =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or = restate >> requirements >> in) the protocol and negotiation drafts. Can they be included by >> reference instead, or at least attributed? >>=20 >> Addressed in new draft. >>=20 >>=20 >> =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77.1. >>=20 >> Addressed in new draft. >>=20 >>=20 >> =C2=A78.3: Unneeded comma in first sentence. >>=20 >> Addressed in new draft. >>=20 >> Thanks again for the thoughtful comments! >>=20 >> Dirk. >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >>=20 >>=20 >=20 --Apple-Mail=_8123AB76-087C-486C-A9F5-CD243AE1B04C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsyjMwACgkQgFZKbJXz 1A09mxAAgY/BcyqQfm6Eov+sVQc0NQcCQJgsN9cyRdqPkBaqSibp3Ry7D9uKvkOR K54vQpj+dueU+VIvjZNnkn8SJWN5SpbrgUgSxLUNj+e7ymbMojGgWcbs6rCo4005 DrnmL/Zck9pXgpWAEKNUw16VtmBtuqsIXtzVBbBpAP49FQA0HjlYJlBGQx5KYf8W 0/CfR6UurSTSgV5Ee37+JgwsWyqOskkZRRg2C54dwNy7f0aGtXmwa0qtQ1powj5X xs59DDcQ8h0FUEPfxKv0wnxie+2YAxGVKee6e5MFD3jlETBq8hYPHP0kaTM8Is4x HtoFIogy4sktCR6RqdfazYOC5P85143ePSdUmFo43LPpbMHg1xMAnHoEKUA6HQVI 2q7dstzINq8hRssGaZE/5TaqohpNOrmELkKHl9xl6ur+mXAh+IUqU+V400Yzzw0I ztc0gooUyjr+Nw/dD6aJRxEMkHs6rIA/sFKhWXlb8Lp0uPY87ec5OqlTbscBEl8i A/fMQ4zinE1Qndxp1hvRJKKcJdxOxbZRO1RL57Rr+q0oPuc8cm2AbvD9vglHC6a0 GL5iMCvBpFNI0HbBtDAjw9607V0VPDtcLtb204rpsCIeWURjO6shuaZ5CqpBAo9v aR4p9QS5X7OLfaAgujcOePXNduAKR23HWOVb37O3iA9Izondazg= =BNe1 -----END PGP SIGNATURE----- --Apple-Mail=_8123AB76-087C-486C-A9F5-CD243AE1B04C-- From nobody Tue Jun 26 14:13:05 2018 Return-Path: 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 5BA83130E42 for ; Tue, 26 Jun 2018 14:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 doHPS-3RUyjp for ; Tue, 26 Jun 2018 14:13:00 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3971130ECD for ; Tue, 26 Jun 2018 14:12:59 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id f16-v6so18613565wrm.3 for ; Tue, 26 Jun 2018 14:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tl+SWfC9Zllkf7Dhiirj71H1HLWKFlVqrniqKfCRgFQ=; b=erGHzvKHJWrBQfWkmHzAXqp78nsD2CSy7+MWmQu6c482TE5gWrgkVW0TpAQO3VwyFR u0cPl2yOS7NDnWyMFsYppmwm6QXQXcEzLcWHSh8ADjFpfPlnZLM/qfUh7QAf9Y+NEnRg MJ+CTwfTv1MJsE9ALgPaRKHUhRHXDukaMtSkx8/RMxcORfbMfiAih5V5P9L/h/67EwGr +VJhxyXS4z10eoKm5rCaSzFzKdEfdIC084R9l+iMuaSFYKTkqfFRdUKBO07+yJhDWDoL IZzvhWOgueIQYhET0ySgk4Cs167+7Sx44DPxP/dkhGnMkO9UOPSQQ5cn1HLzR1g6MzuY eO7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tl+SWfC9Zllkf7Dhiirj71H1HLWKFlVqrniqKfCRgFQ=; b=ThYrxlvGtyM1H1iUmdXKT93+qdHXxJSEcCX1gB5D5P4plX0sDMFnci7axrHadFASWk 85wdWJf3jugn04yan7EZ4i2ZcHwsfOKGqc2Rs4n+BY/3GiQx0iND9t3NTf3rjj7QhOEY umMqFwVNGeS5BvdeFxzYLfoNZQHCWQz3pqTyoArtQDAvJWHgfyStLVWNvTqBGVjp/CNM dJVK+Nmv8pSXd4+HQZx1hV2ohaNCW77FGpqUf+xDauIKlADjQqGjMobDDXOD63ylnaje V+9t3N3pCpfR/dPiJwNaetNdWkD61P3JyTTwHjaGTzhlr6epph9Jzn3u3wmQyAGTevSL ytmQ== X-Gm-Message-State: APt69E15VIQ16IiaqBmXgESX9ZHTc9c+9Q8xPJ4fWOSfvGYBv4zcWPvx CVqlh8IsBkqcaapREp+O1ScR5gt/AOFxAF9OfB4oTm5h X-Google-Smtp-Source: AAOMgpfsv15ghIVrO8Dt2phnztlq69TcxcmIt56+JDs/CJgv2Fo/3+Jzm0sNQFUA4HzbUH2KUxkpAnPE8kpWmEhBeVc= X-Received: by 2002:adf:84c5:: with SMTP id 63-v6mr2917941wrg.50.1530047578108; Tue, 26 Jun 2018 14:12:58 -0700 (PDT) MIME-Version: 1.0 References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com> In-Reply-To: <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com> From: John Bradley Date: Tue, 26 Jun 2018 17:12:46 -0400 Message-ID: To: Ben Campbell Cc: Andrei Popov , Eric Rescorla , Dirk Balfanz , "draft-ietf-tokbind-https@ietf.org" , Tokbind WG , The IESG , "tokbind-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000620e13056f91f655" Archived-At: Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:13:04 -0000 --000000000000620e13056f91f655 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ben. EKR once this Discuss is cleared are we good to move on to the final embrace of the RFC editor? Regards John B. On Tue, Jun 26, 2018, 2:58 PM Ben Campbell wrote: > > > > On Jun 26, 2018, at 1:54 PM, Andrei Popov > wrote: > > > > Hi Ben, > > > > Thanks for the review. > > > >> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as th= ose from > paragraph 2? > > > > Yes, the same throughout paragraphs 1, 2 and 3. > > > >> It seems like paragraph 2 is talking more about local APIs (at least, = I > see that was mentioned in the text in version 17 but not in 18), but > paragraph 3 uses an example of a signal from a server. (I can accept that > the difference in control may be weak enough for web applications that th= e > distinction does not matter.) > > > > The APIs provided by the TB implementation and called by the applicatio= n > are local APIs. > > The application needs to make a decision whether to request that the TB > implementation include a Referred binding in the TB message or not. > > In the example, the server provides a signal to the application using > the Include-Referred-Token-Binding-ID HTTP response header. > > The signal could be different, or an application may have out-of-band > ways to determine this (e.g. a local database of RP->IDP associations). > > I just re-read the 3rd paragraph, and I think I missed the =E2=80=9Cthen= =E2=80=9D in > =E2=80=9Cwhich then signals=E2=80=9D on the first reading. It=E2=80=99s f= ine as is. > > Thanks! > > Ben. > > > > > Cheers, > > > > Andrei > > > > -----Original Message----- > > From: Ben Campbell > > Sent: Tuesday, June 26, 2018 11:41 AM > > To: Eric Rescorla > > Cc: Dirk Balfanz ; > draft-ietf-tokbind-https@ietf.org; Tokbind WG ; The > IESG ; John Bradley ; > tokbind-chairs@ietf.org > > Subject: Re: [Unbearable] Ben Campbell's Discuss on > draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) > > > > Hi, thanks for the pointer. > > > > The text in version 18 is sufficient to clear my discuss. I have one > remaining (or maybe new) non-blocking question for section 6: > > > > Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as tho= se from paragraph > 2? It seems like paragraph 2 is talking more about local APIs (at least, = I > see that was mentioned in the text in version 17 but not in 18), but > paragraph 3 uses an example of a signal from a server. (I can accept that > the difference in control may be weak enough for web applications that th= e > distinction does not matter.) > > > > I did not check my editorial comments. > > > > Thanks! > > > > Ben. > > > >> On Jun 25, 2018, at 6:30 PM, Eric Rescorla wrote: > >> > >> Ben, > >> > >> Does the following new text address your concern: > >> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=3Dhtml= /a > >> scii&url=3Dhttps://raw.githubusercontent.com/TokenBinding/Internet-Dra= ft > >> s/master/draft-ietf-tokbind-https-18.xml > >> > >> > >> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz 40google..com@dmarc.ietf.org> wrote: > >> Hi Ben, > >> > >> thanks for the feedback. Most of it is addressed in the new draft ( > https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below > (inline) for details. > >> > >> On Wed, May 9, 2018 at 1:38 PM Ben Campbell wrote: > >> Ben Campbell has entered the following ballot position for > >> draft-ietf-tokbind-https-14: 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: > >> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> I plan to ballot "YES", but I want to clear up once concern first: > >> > >> After reading section 6 several times, I don't know what it means. I > >> think it's [...] > >> > >> Addressed in new draft. > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Substantive Comments: > >> > >> =C2=A71.1: Please consider using the boilerplate from 8174 across the > >> cluster. Both this and the protocol draft have lower case keyword > instances. > >> > >> Addressed in new draft. > >> > >> > >> =C2=A78.2: > >> - Does it really make sense to wait for a user to request the keys be > expired? > >> I suspect the average user does this about never. Did the working > >> group discuss possibly making the keys default to expiring after some > period of time? > >> > >> Yes, we did discuss it. This was chosen consciously to be in sync with > cookies and their expirations / manual user-initiated purges. > >> > >> - Why > >> is the SHOULD in paragraph 2 not a MUST? > >> > >> Addressed in new draft. > >> > >> > >> Editorial Comments: > >> > >> =C2=A72: > >> - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in > >> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The open > parenthesis before "in" > >> seems misplaced. Also, as written the comma after "style" creates a > >> comma splice. (Note that this pattern occurs elsewhere in the > >> document.) > >> > >> - Paragraph 3: The paragraph is a single hard-to-parse sentence. > >> Please consider breaking into simpler sentences. > >> > >> Addressed in new draft. > >> > >> > >> - example: Am I correct to assume the backslashes are just for print > >> purposes and are not in the actual message? If so, please mention that= . > >> > >> Addressed in new draft. > >> > >> > >> =C2=A7 2.1: > >> - first paragraph, "Within the latter context...": There was no former > context. > >> I suggest "Within that context..." > >> > >> Addressed in new draft. > >> > >> - 2nd paragraph: The first sentence is hard to parse. I suggest > >> breaking it into separate paragraphs, or restructure without the > >> center-imbedding. > >> > >> Addressed in new draft. > >> > >> - 2nd to last paragraph: Does "SHOULD generally" > >> mean the same as just "SHOULD"? > >> > >> Addressed in new draft. > >> > >> > >> =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to another > server..." > >> > >> Addressed in new draft. > >> > >> > >> =C2=A75.2, > >> - last bullet: " (between client and Token Consumer)" seems more than > >> parenthetical. Please consider removing the parentheses. > >> > >> Addressed in new draft. > >> > >> - paragraph after last > >> bullet: The parenthetical phrase starting with "(proving > >> possession...) is quite long and makes the sentence hard to parse. > >> Given that the concept is covered in the immediately preceding > paragraph, can it be removed? > >> > >> Addressed in new draft. > >> > >> > >> =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or res= tate > >> requirements > >> in) the protocol and negotiation drafts. Can they be included by > >> reference instead, or at least attributed? > >> > >> Addressed in new draft. > >> > >> > >> =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77.1. > >> > >> Addressed in new draft. > >> > >> > >> =C2=A78.3: Unneeded comma in first sentence. > >> > >> Addressed in new draft. > >> > >> Thanks again for the thoughtful comments! > >> > >> Dirk. > >> > >> _______________________________________________ > >> Unbearable mailing list > >> Unbearable@ietf.org > >> https://www.ietf.org/mailman/listinfo/unbearable > >> > >> > > > > --000000000000620e13056f91f655 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ben.

= EKR once this Discuss is cleared are we good to move on to the final embrac= e of the RFC editor?

Reg= ards=C2=A0
John B.=C2=A0=C2=A0

On Tue, Jun 26, 2018, 2:58 PM Ben Cam= pbell <ben@nostrum.com> wrote:=


> On Jun 26, 2018, at 1:54 PM, Andrei Popov <Andrei.Popov@mic= rosoft.com> wrote:
>
> Hi Ben,
>
> Thanks for the review.
>
>> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same a= s those from paragraph 2?
>
> Yes, the same throughout paragraphs 1, 2 and 3.
>
>> It seems like paragraph 2 is talking more about local APIs (at lea= st, I see that was mentioned in the text in version 17 but not in 18), but = paragraph 3 uses an example of a signal from a server. (I can accept that t= he difference in control may be weak enough for web applications that the d= istinction does not matter.)
>
> The APIs provided by the TB implementation and called by the applicati= on are local APIs.
> The application needs to make a decision whether to request that the T= B implementation include a Referred binding in the TB message or not.
> In the example, the server provides a signal to the application using = the Include-Referred-Token-Binding-ID HTTP response header.
> The signal could be different, or an application may have out-of-band = ways to determine this (e.g. a local database of RP->IDP associations).<= br>
I just re-read the 3rd paragraph, and I think I missed the =E2=80=9Cthen=E2= =80=9D in =E2=80=9Cwhich then signals=E2=80=9D on the first reading. It=E2= =80=99s fine as is.

Thanks!

Ben.

>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: Ben Campbell <ben@nostrum.com>
> Sent: Tuesday, June 26, 2018 11:41 AM
> To: Eric Rescorla <ekr@rtfm.com>
> Cc: Dirk Balfanz <balfanz=3D40google.com@dmarc.ietf.org>; draft-ietf-tokbind-https@ietf.org; Tokbind WG <= ;unbearable@ietf.org>; The IESG <iesg@ietf.org>; John Bradley = <ve7jtb@ve7jtb.com>; tokbind-chairs@ietf.org
> Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tok= bind-https-14: (with DISCUSS and COMMENT)
>
> Hi, thanks for the pointer.
>
> The text in version 18 is sufficient to clear my discuss. I have one r= emaining (or maybe new) non-blocking question for section 6:
>
> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as th= ose from paragraph 2? It seems like paragraph 2 is talking more about local= APIs (at least, I see that was mentioned in the text in version 17 but not= in 18), but paragraph 3 uses an example of a signal from a server. (I can = accept that the difference in control may be weak enough for web applicatio= ns that the distinction does not matter.)
>
> I did not check my editorial comments.
>
> Thanks!
>
> Ben.
>
>> On Jun 25, 2018, at 6:30 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:
>>
>> Ben,
>>
>> Does the following new text address your concern:
>> https://= xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=3Dhtml/a
>> scii&url=3Dhttp= s://raw.githubusercontent.com/TokenBinding/Internet-Draft
>> s/master/draft-ietf-tokbind-https-18.xml
>>
>>
>> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=3D40google..com@dmarc.ietf.org> wrote:
>> Hi Ben,
>>
>> thanks for the feedback. Most of it is addressed in the new draft = (https://tools.ietf.org/html/draft= -ietf-tokbind-https-16). See below (inline) for details.
>>
>> On Wed, May 9, 2018 at 1:38 PM Ben Campbell <ben@nostrum.com&g= t; wrote:
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-tokbind-https-14: 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/ie= sg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here= :
>> https://datatracker.ie= tf.org/doc/draft-ietf-tokbind-https/
>>
>>
>>
>> ------------------------------------------------------------------= ----
>> DISCUSS:
>> ------------------------------------------------------------------= ----
>>
>> I plan to ballot "YES", but I want to clear up once conc= ern first:
>>
>> After reading section 6 several times, I don't know what it me= ans. I
>> think it's [...]
>>
>> Addressed in new draft.
>>
>>
>> ------------------------------------------------------------------= ----
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>> Substantive Comments:
>>
>> =C2=A71.1: Please consider using the boilerplate from 8174 across = the
>> cluster. Both this and the protocol draft have lower case keyword = instances.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A78.2:
>> - Does it really make sense to wait for a user to request the keys= be expired?
>> I suspect the average user does this about never. Did the working<= br> >> group discuss possibly making the keys default to expiring after s= ome period of time?
>>
>> Yes, we did discuss it. This was chosen consciously to be in sync = with cookies and their expirations / manual user-initiated purges.
>>
>> - Why
>> is the SHOULD in paragraph 2 not a MUST?
>>
>> Addressed in new draft.
>>
>>
>> Editorial Comments:
>>
>> =C2=A72:
>> - Paragraph 1: "The ABNF of the Sec-Token-Binding header fiel= d is (in
>> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The ope= n parenthesis before "in"
>> seems misplaced. Also, as written the comma after "style"= ; creates a
>> comma splice. (Note that this pattern occurs elsewhere in the
>> document.)
>>
>> - Paragraph 3: The paragraph is a single hard-to-parse sentence. >> Please consider breaking into simpler sentences.
>>
>> Addressed in new draft.
>>
>>
>> - example: Am I correct to assume the backslashes are just for pri= nt
>> purposes and are not in the actual message? If so, please mention = that.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A7 2.1:
>> - first paragraph, "Within the latter context...": There= was no former context.
>> I suggest "Within that context..."
>>
>> Addressed in new draft.
>>
>> - 2nd paragraph: The first sentence is hard to parse. I suggest >> breaking it into separate paragraphs, or restructure without the >> center-imbedding.
>>
>> Addressed in new draft.
>>
>> - 2nd to last paragraph: Does "SHOULD generally"
>> mean the same as just "SHOULD"?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to a= nother server..."
>>
>> Addressed in new draft.
>>
>>
>> =C2=A75.2,
>> - last bullet: " (between client and Token Consumer)" se= ems more than
>> parenthetical. Please consider removing the parentheses.
>>
>> Addressed in new draft.
>>
>> - paragraph after last
>> bullet: The parenthetical phrase starting with "(proving
>> possession...) is quite long and makes the sentence hard to parse.=
>> Given that the concept is covered in the immediately preceding par= agraph, can it be removed?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or= restate
>> requirements
>> in) the protocol and negotiation drafts. Can they be included by >> reference instead, or at least attributed?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77= .1.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A78.3: Unneeded comma in first sentence.
>>
>> Addressed in new draft.
>>
>> Thanks again for the thoughtful comments!
>>
>> Dirk.
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/l= istinfo/unbearable
>>
>>
>

--000000000000620e13056f91f655-- From nobody Tue Jun 26 14:14:46 2018 Return-Path: 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 D57FC130E5D for ; Tue, 26 Jun 2018 14:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 nQYCMo8Dejge for ; Tue, 26 Jun 2018 14:14:42 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03779130E3F for ; Tue, 26 Jun 2018 14:14:42 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id p1-v6so3008046wrs.9 for ; Tue, 26 Jun 2018 14:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gM14tQ1tcQG1L1jXGeRhnkdZszUsBE+idfrIrwIZkxg=; b=ZvRRn8ZTRVOm3DzIY218HzY3Fw6nYqILub4xRQHDCCYCuISsJ4MeUEL65gF51mvqiZ 5KfShk+hPyKWPKU77ITMb5/fTpS2viC0zGFObHHv4MR389bDruNR2mtta+6K2Bfs2PXI UB96ysunOJGJxv69ShDIM4sxpnKYWGG3pWABjmr17Zj7gvsK84DwfiQIGcOiknwhwUF2 pe1sgjHBwdHUnr54DuzNSeLC/0q8Y38pOykYjnZmM/brUsO8SHjsk/A0WegC8L1CzWOO hRBX8ox6PzSCp8cvsKs/Gj/7MZ+/YXgV+FpUqrbzqly0ryJ+XNqjObp0GJMuzN6cG+Po NSoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gM14tQ1tcQG1L1jXGeRhnkdZszUsBE+idfrIrwIZkxg=; b=okwHMr0W1ZXYtM/DfxqcjTszvkL8LEfbnpUMqDxmxvSw4owYv3wmchy4uF8C2ahQ+b FU9oAKBEzmuevKXAwWxQKwzgjB75W0Is0eQn3MaG9wQFqj1bGXdoEWHGSkYWX25Acbml Y2R47uYzJ22qfMqocj6try59WX7GzcChhx8SKRPtCDQziIJWX93RJ9yEjhZ4yloNbSs6 PGrqJdvfan6idiCjyp9yk8EBhePwA52rD/F3sbiC0D/XsHiy94VA9DoZbcf0wRLWqPVh SqpD0Q1Jt8KZ608Q/3f5ypguEacjcVVLR0u6aqklz3ovZKErNsiDmU0Mwvdv41/tADEX U2Yg== X-Gm-Message-State: APt69E0RDqEYYAJgRfOUvz8cromWHgNokwiyu2dHEFBlTJHpynWJp6KU 4xiZEyI71dr0uU9v18fHQJtZIWjD3yy6vnZhFEUUEQ== X-Google-Smtp-Source: AAOMgpeiGrdXRXfogvx5j/onALUXAMVfjGvRQ+frZzYKWwuaiu6sV0YEWJ4b0Pm8PdIXhNuslGrG7fWf+WbiiBjjIXU= X-Received: by 2002:adf:9ed0:: with SMTP id b16-v6mr224535wrf.170.1530047680162; Tue, 26 Jun 2018 14:14:40 -0700 (PDT) MIME-Version: 1.0 References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com> In-Reply-To: From: John Bradley Date: Tue, 26 Jun 2018 17:14:28 -0400 Message-ID: To: Ben Campbell Cc: Andrei Popov , Eric Rescorla , Dirk Balfanz , draft-ietf-tokbind-https@ietf.org, Tokbind WG , IESG , tokbind-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000077487c056f91fce8" Archived-At: Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:14:45 -0000 --00000000000077487c056f91fce8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable PS I suppose we need DIRK OR Andre to push a version with the changes. John B. On Tue, Jun 26, 2018, 5:12 PM John Bradley wrote: > Thanks Ben. > > EKR once this Discuss is cleared are we good to move on to the final > embrace of the RFC editor? > > Regards > John B. > > On Tue, Jun 26, 2018, 2:58 PM Ben Campbell wrote: > >> >> >> > On Jun 26, 2018, at 1:54 PM, Andrei Popov >> wrote: >> > >> > Hi Ben, >> > >> > Thanks for the review. >> > >> >> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as t= hose from >> paragraph 2? >> > >> > Yes, the same throughout paragraphs 1, 2 and 3. >> > >> >> It seems like paragraph 2 is talking more about local APIs (at least, >> I see that was mentioned in the text in version 17 but not in 18), but >> paragraph 3 uses an example of a signal from a server. (I can accept tha= t >> the difference in control may be weak enough for web applications that t= he >> distinction does not matter.) >> > >> > The APIs provided by the TB implementation and called by the >> application are local APIs. >> > The application needs to make a decision whether to request that the T= B >> implementation include a Referred binding in the TB message or not. >> > In the example, the server provides a signal to the application using >> the Include-Referred-Token-Binding-ID HTTP response header. >> > The signal could be different, or an application may have out-of-band >> ways to determine this (e.g. a local database of RP->IDP associations). >> >> I just re-read the 3rd paragraph, and I think I missed the =E2=80=9Cthen= =E2=80=9D in >> =E2=80=9Cwhich then signals=E2=80=9D on the first reading. It=E2=80=99s = fine as is. >> >> Thanks! >> >> Ben. >> >> > >> > Cheers, >> > >> > Andrei >> > >> > -----Original Message----- >> > From: Ben Campbell >> > Sent: Tuesday, June 26, 2018 11:41 AM >> > To: Eric Rescorla >> > Cc: Dirk Balfanz ; >> draft-ietf-tokbind-https@ietf.org; Tokbind WG ; The >> IESG ; John Bradley ; >> tokbind-chairs@ietf.org >> > Subject: Re: [Unbearable] Ben Campbell's Discuss on >> draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) >> > >> > Hi, thanks for the pointer. >> > >> > The text in version 18 is sufficient to clear my discuss. I have one >> remaining (or maybe new) non-blocking question for section 6: >> > >> > Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as th= ose from >> paragraph 2? It seems like paragraph 2 is talking more about local APIs = (at >> least, I see that was mentioned in the text in version 17 but not in 18)= , >> but paragraph 3 uses an example of a signal from a server. (I can accept >> that the difference in control may be weak enough for web applications t= hat >> the distinction does not matter.) >> > >> > I did not check my editorial comments. >> > >> > Thanks! >> > >> > Ben. >> > >> >> On Jun 25, 2018, at 6:30 PM, Eric Rescorla wrote: >> >> >> >> Ben, >> >> >> >> Does the following new text address your concern: >> >> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=3Dhtm= l/a >> >> scii&url=3Dhttps://raw.githubusercontent.com/TokenBinding/Internet-Dr= aft >> >> s/master/draft-ietf-tokbind-https-18.xml >> >> >> >> >> >> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz > 40google..com@dmarc.ietf.org> wrote: >> >> Hi Ben, >> >> >> >> thanks for the feedback. Most of it is addressed in the new draft ( >> https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below >> (inline) for details. >> >> >> >> On Wed, May 9, 2018 at 1:38 PM Ben Campbell wrote: >> >> Ben Campbell has entered the following ballot position for >> >> draft-ietf-tokbind-https-14: 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: >> >> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ >> >> >> >> >> >> >> >> ---------------------------------------------------------------------= - >> >> DISCUSS: >> >> ---------------------------------------------------------------------= - >> >> >> >> I plan to ballot "YES", but I want to clear up once concern first: >> >> >> >> After reading section 6 several times, I don't know what it means. I >> >> think it's [...] >> >> >> >> Addressed in new draft. >> >> >> >> >> >> ---------------------------------------------------------------------= - >> >> COMMENT: >> >> ---------------------------------------------------------------------= - >> >> >> >> Substantive Comments: >> >> >> >> =C2=A71.1: Please consider using the boilerplate from 8174 across the >> >> cluster. Both this and the protocol draft have lower case keyword >> instances. >> >> >> >> Addressed in new draft. >> >> >> >> >> >> =C2=A78.2: >> >> - Does it really make sense to wait for a user to request the keys be >> expired? >> >> I suspect the average user does this about never. Did the working >> >> group discuss possibly making the keys default to expiring after some >> period of time? >> >> >> >> Yes, we did discuss it. This was chosen consciously to be in sync wit= h >> cookies and their expirations / manual user-initiated purges. >> >> >> >> - Why >> >> is the SHOULD in paragraph 2 not a MUST? >> >> >> >> Addressed in new draft. >> >> >> >> >> >> Editorial Comments: >> >> >> >> =C2=A72: >> >> - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in >> >> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The open >> parenthesis before "in" >> >> seems misplaced. Also, as written the comma after "style" creates a >> >> comma splice. (Note that this pattern occurs elsewhere in the >> >> document.) >> >> >> >> - Paragraph 3: The paragraph is a single hard-to-parse sentence. >> >> Please consider breaking into simpler sentences. >> >> >> >> Addressed in new draft. >> >> >> >> >> >> - example: Am I correct to assume the backslashes are just for print >> >> purposes and are not in the actual message? If so, please mention tha= t. >> >> >> >> Addressed in new draft. >> >> >> >> >> >> =C2=A7 2.1: >> >> - first paragraph, "Within the latter context...": There was no forme= r >> context. >> >> I suggest "Within that context..." >> >> >> >> Addressed in new draft. >> >> >> >> - 2nd paragraph: The first sentence is hard to parse. I suggest >> >> breaking it into separate paragraphs, or restructure without the >> >> center-imbedding. >> >> >> >> Addressed in new draft. >> >> >> >> - 2nd to last paragraph: Does "SHOULD generally" >> >> mean the same as just "SHOULD"? >> >> >> >> Addressed in new draft. >> >> >> >> >> >> =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to another >> server..." >> >> >> >> Addressed in new draft. >> >> >> >> >> >> =C2=A75.2, >> >> - last bullet: " (between client and Token Consumer)" seems more than >> >> parenthetical. Please consider removing the parentheses. >> >> >> >> Addressed in new draft. >> >> >> >> - paragraph after last >> >> bullet: The parenthetical phrase starting with "(proving >> >> possession...) is quite long and makes the sentence hard to parse. >> >> Given that the concept is covered in the immediately preceding >> paragraph, can it be removed? >> >> >> >> Addressed in new draft. >> >> >> >> >> >> =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or re= state >> >> requirements >> >> in) the protocol and negotiation drafts. Can they be included by >> >> reference instead, or at least attributed? >> >> >> >> Addressed in new draft. >> >> >> >> >> >> =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77.1. >> >> >> >> Addressed in new draft. >> >> >> >> >> >> =C2=A78.3: Unneeded comma in first sentence. >> >> >> >> Addressed in new draft. >> >> >> >> Thanks again for the thoughtful comments! >> >> >> >> Dirk. >> >> >> >> _______________________________________________ >> >> Unbearable mailing list >> >> Unbearable@ietf.org >> >> https://www.ietf.org/mailman/listinfo/unbearable >> >> >> >> >> > >> >> --00000000000077487c056f91fce8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
PS I suppose we need DIRK OR Andre to push a version= with the changes.

John = B.=C2=A0

On= Tue, Jun 26, 2018, 5:12 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
Thanks Ben.

EKR once this Discuss is cleared are we good to move on to the final e= mbrace of the RFC editor?

Regards=C2=A0
John B.=C2=A0=C2=A0

<= div class=3D"gmail_quote">
On Tue, Jun 26, 2018, 2:58 PM Be= n Campbell <ben@nostrum.com> wrote:


> On Jun 26, 2018, at 1:54 PM, Andrei Popov <Andre= i.Popov@microsoft.com> wrote:
>
> Hi Ben,
>
> Thanks for the review.
>
>> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same a= s those from paragraph 2?
>
> Yes, the same throughout paragraphs 1, 2 and 3.
>
>> It seems like paragraph 2 is talking more about local APIs (at lea= st, I see that was mentioned in the text in version 17 but not in 18), but = paragraph 3 uses an example of a signal from a server. (I can accept that t= he difference in control may be weak enough for web applications that the d= istinction does not matter.)
>
> The APIs provided by the TB implementation and called by the applicati= on are local APIs.
> The application needs to make a decision whether to request that the T= B implementation include a Referred binding in the TB message or not.
> In the example, the server provides a signal to the application using = the Include-Referred-Token-Binding-ID HTTP response header.
> The signal could be different, or an application may have out-of-band = ways to determine this (e.g. a local database of RP->IDP associations).<= br>
I just re-read the 3rd paragraph, and I think I missed the =E2=80=9Cthen=E2= =80=9D in =E2=80=9Cwhich then signals=E2=80=9D on the first reading. It=E2= =80=99s fine as is.

Thanks!

Ben.

>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: Ben Campbell <ben@nostrum.com>
> Sent: Tuesday, June 26, 2018 11:41 AM
> To: Eric Rescorla <ekr@rtfm.com>
> Cc: Dirk Balfanz <balfanz=3D40google.com@dmarc.= ietf.org>; draft-ietf-tokbind-https@ietf.= org; Tokbind WG <unbearable@ietf.org>; The IESG &= lt;iesg@ietf.org>; John Bradley <ve7jtb@ve7jtb.co= m>; tokbind-chairs@ietf.org
> Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tok= bind-https-14: (with DISCUSS and COMMENT)
>
> Hi, thanks for the pointer.
>
> The text in version 18 is sufficient to clear my discuss. I have one r= emaining (or maybe new) non-blocking question for section 6:
>
> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as th= ose from paragraph 2? It seems like paragraph 2 is talking more about local= APIs (at least, I see that was mentioned in the text in version 17 but not= in 18), but paragraph 3 uses an example of a signal from a server. (I can = accept that the difference in control may be weak enough for web applicatio= ns that the distinction does not matter.)
>
> I did not check my editorial comments.
>
> Thanks!
>
> Ben.
>
>> On Jun 25, 2018, at 6:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Ben,
>>
>> Does the following new text address your concern:
>> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=3Dhtml/a=
>> scii&url=3Dhttps://raw.githubusercontent.com/TokenBinding/Internet-Draft >> s/master/draft-ietf-tokbind-https-18.xml
>>
>>
>> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=3D40google..com@dmarc.ietf.org> wrote:
>> Hi Ben,
>>
>> thanks for the feedback. Most of it is addressed in the new draft = (https://tools.ietf.org= /html/draft-ietf-tokbind-https-16). See below (inline) for details.
>>
>> On Wed, May 9, 2018 at 1:38 PM Ben Campbell <ben@nostru= m.com> wrote:
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-tokbind-https-14: 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= :
>> https://dat= atracker.ietf.org/doc/draft-ietf-tokbind-https/
>>
>>
>>
>> ------------------------------------------------------------------= ----
>> DISCUSS:
>> ------------------------------------------------------------------= ----
>>
>> I plan to ballot "YES", but I want to clear up once conc= ern first:
>>
>> After reading section 6 several times, I don't know what it me= ans. I
>> think it's [...]
>>
>> Addressed in new draft.
>>
>>
>> ------------------------------------------------------------------= ----
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>> Substantive Comments:
>>
>> =C2=A71.1: Please consider using the boilerplate from 8174 across = the
>> cluster. Both this and the protocol draft have lower case keyword = instances.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A78.2:
>> - Does it really make sense to wait for a user to request the keys= be expired?
>> I suspect the average user does this about never. Did the working<= br> >> group discuss possibly making the keys default to expiring after s= ome period of time?
>>
>> Yes, we did discuss it. This was chosen consciously to be in sync = with cookies and their expirations / manual user-initiated purges.
>>
>> - Why
>> is the SHOULD in paragraph 2 not a MUST?
>>
>> Addressed in new draft.
>>
>>
>> Editorial Comments:
>>
>> =C2=A72:
>> - Paragraph 1: "The ABNF of the Sec-Token-Binding header fiel= d is (in
>> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The ope= n parenthesis before "in"
>> seems misplaced. Also, as written the comma after "style"= ; creates a
>> comma splice. (Note that this pattern occurs elsewhere in the
>> document.)
>>
>> - Paragraph 3: The paragraph is a single hard-to-parse sentence. >> Please consider breaking into simpler sentences.
>>
>> Addressed in new draft.
>>
>>
>> - example: Am I correct to assume the backslashes are just for pri= nt
>> purposes and are not in the actual message? If so, please mention = that.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A7 2.1:
>> - first paragraph, "Within the latter context...": There= was no former context.
>> I suggest "Within that context..."
>>
>> Addressed in new draft.
>>
>> - 2nd paragraph: The first sentence is hard to parse. I suggest >> breaking it into separate paragraphs, or restructure without the >> center-imbedding.
>>
>> Addressed in new draft.
>>
>> - 2nd to last paragraph: Does "SHOULD generally"
>> mean the same as just "SHOULD"?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to a= nother server..."
>>
>> Addressed in new draft.
>>
>>
>> =C2=A75.2,
>> - last bullet: " (between client and Token Consumer)" se= ems more than
>> parenthetical. Please consider removing the parentheses.
>>
>> Addressed in new draft.
>>
>> - paragraph after last
>> bullet: The parenthetical phrase starting with "(proving
>> possession...) is quite long and makes the sentence hard to parse.=
>> Given that the concept is covered in the immediately preceding par= agraph, can it be removed?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or= restate
>> requirements
>> in) the protocol and negotiation drafts. Can they be included by >> reference instead, or at least attributed?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77= .1.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A78.3: Unneeded comma in first sentence.
>>
>> Addressed in new draft.
>>
>> Thanks again for the thoughtful comments!
>>
>> Dirk.
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.or= g/mailman/listinfo/unbearable
>>
>>
>

--00000000000077487c056f91fce8-- From nobody Tue Jun 26 14:19:23 2018 Return-Path: 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 5F4D1130EFF; Tue, 26 Jun 2018 14:19:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153004794334.18865.3504048883262335022@ietfa.amsl.com> Date: Tue, 26 Jun 2018 14:19:03 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-18.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:19:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : Token Binding over HTTP Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Nick Harper Jeff Hodges Filename : draft-ietf-tokbind-https-18.txt Pages : 25 Date : 2018-06-26 Abstract: This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections. We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token. This document is a companion document to The Token Binding Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-https-18 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 26 14:19:59 2018 Return-Path: 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 98D3C130EEF; Tue, 26 Jun 2018 14:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 oiLEHKF3o8hj; Tue, 26 Jun 2018 14:19:36 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0138.outbound.protection.outlook.com [104.47.32.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E77130EF3; Tue, 26 Jun 2018 14:19:36 -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:X-MS-Exchange-SenderADCheck; bh=7/V4ut8Y4ghjVemliDbTDD0xsqVJgkM/HsXJ7nqn6YU=; b=E/QptJCA2breoU5aLh+pecqikIwSuv+wmWYSblidoH1aRPjV4ryoXhN7cs47s7SY/01HSOwFmfvz3Hs/GcKkpW6HoSUC/EdennXQmcpnqzl7tN+To3Af+VRdx4BfyS2xxERwTKMccWpYEX5/JXm7Ve7REh9hPxvFbZChHyBfQ+Y= Received: from CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) by CY4PR21MB0472.namprd21.prod.outlook.com (10.172.121.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.0; Tue, 26 Jun 2018 21:19:34 +0000 Received: from CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::9d01:113b:290a:750b]) by CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::9d01:113b:290a:750b%3]) with mapi id 15.20.0930.005; Tue, 26 Jun 2018 21:19:34 +0000 From: Andrei Popov To: John Bradley , Ben Campbell CC: Eric Rescorla , Dirk Balfanz , "draft-ietf-tokbind-https@ietf.org" , Tokbind WG , IESG , "tokbind-chairs@ietf.org" Thread-Topic: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) Thread-Index: AQHT59XA5IIayh1w/kSwtbPg5+4zz6RQtRGAgCE0KwCAAUGXgIAAAMlwgAAEBACAACWQAIAAAHkAgAABTlA= Date: Tue, 26 Jun 2018 21:19:34 +0000 Message-ID: References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:8:28b5:a023:971b:e42c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0472; 7:37tOsQ8iSD0uVT5F0GB41dkUNOmAzY7ICp6FmcVtj+r20q8HNalfivlTnosBHawSdmcnpPwSukxGLinW3GHAxv8GS/Vr43cq71L/65SxJlHykrOgO9RK/BF2GaVBv1D0hW41/gzFX4Cqa5qkmdd3e2EQowpGY932d10QRskT2y1BEDzh7G6mCuWKxO17fftHirto6+6d7cbEc4ESbVIZ9NY1HGmgLhMBqpR+8A9L0RUh/26ZIrxMG3hFnqr4yjwp x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 307f44fa-ca8b-492d-c109-08d5dbaa83ac x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0472; x-ms-traffictypediagnostic: CY4PR21MB0472: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(278428928389397)(89211679590171)(120809045254105)(275740015457677)(189930954265078)(219752817060721)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:CY4PR21MB0472; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0472; x-forefront-prvs: 071518EF63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(136003)(376002)(366004)(13464003)(189003)(51914003)(199004)(5250100002)(6436002)(97736004)(8936002)(25786009)(606006)(4326008)(8990500004)(81166006)(81156014)(99286004)(2906002)(229853002)(86612001)(86362001)(476003)(11346002)(14444005)(54896002)(486006)(55016002)(256004)(6306002)(22452003)(316002)(5660300001)(93886005)(54906003)(110136005)(446003)(6116002)(19609705001)(6346003)(33656002)(72206003)(53936002)(478600001)(46003)(76176011)(2900100001)(68736007)(53546011)(186003)(7696005)(10090500001)(106356001)(105586002)(8676002)(6246003)(790700001)(10290500003)(7736002)(14454004)(966005)(74316002)(9686003)(236005)(102836004)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0472; H:CY4PR21MB0774.namprd21.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=Andrei.Popov@microsoft.com; x-microsoft-antispam-message-info: n3M/c25Qg5EZTGkepp9pT+N5ahkkm7VFelMcZu9nbKV0OA7B/TwF6PETLpK80uy0JGTjO2bmxMxgw4YDIU21KMXIn7XqY882Z0x/F61KfQWkhkAl3h5UMF1NVSlGGS2J0Swcg3AjKuuuI+pNzkjboAZ+D98fA+1rAGsAIewJUYJo3fN1RLeo9nC7PhdCzlORbs/OQdqdnFbaJzlpxMyO75qEmjoagmNZTPeZpqO0pbpaBSykhQxWFH7nQQVoYNrYIksM1XfqEye8syaWkg97axFvRfQ8nJjVGMK4n4mISR58TK9wttDTbWWjdUrp15lLJfucbkeGRvJ7iQlgwpkJgf0XHDi/jdILFzFEe8jUGxg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB077453A70AC47C98C59C21088C490CY4PR21MB0774namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 307f44fa-ca8b-492d-c109-08d5dbaa83ac X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 21:19:34.1722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0472 Archived-At: Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:19:58 -0000 --_000_CY4PR21MB077453A70AC47C98C59C21088C490CY4PR21MB0774namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9uZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10b2tiaW5k LWh0dHBzLy4NCg0KRnJvbTogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT4NClNlbnQ6 IFR1ZXNkYXksIEp1bmUgMjYsIDIwMTggMjoxNCBQTQ0KVG86IEJlbiBDYW1wYmVsbCA8YmVuQG5v c3RydW0uY29tPg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+ OyBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBEaXJrIEJhbGZhbnogPGJhbGZhbno9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnPjsgZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzQGlldGYu b3JnOyBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPjsgSUVTRyA8aWVzZ0BpZXRmLm9y Zz47IHRva2JpbmQtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIEJl biBDYW1wYmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTE0OiAod2l0 aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpQUyBJIHN1cHBvc2Ugd2UgbmVlZCBESVJLIE9SIEFu ZHJlIHRvIHB1c2ggYSB2ZXJzaW9uIHdpdGggdGhlIGNoYW5nZXMuDQoNCkpvaG4gQi4NCk9uIFR1 ZSwgSnVuIDI2LCAyMDE4LCA1OjEyIFBNIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208 bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQpUaGFua3MgQmVuLg0KDQpFS1Igb25j ZSB0aGlzIERpc2N1c3MgaXMgY2xlYXJlZCBhcmUgd2UgZ29vZCB0byBtb3ZlIG9uIHRvIHRoZSBm aW5hbCBlbWJyYWNlIG9mIHRoZSBSRkMgZWRpdG9yPw0KDQpSZWdhcmRzDQpKb2huIEIuDQoNCk9u IFR1ZSwgSnVuIDI2LCAyMDE4LCAyOjU4IFBNIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29t PG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+PiB3cm90ZToNCg0KDQo+IE9uIEp1biAyNiwgMjAxOCwg YXQgMTo1NCBQTSwgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWls dG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4NCj4gSGkgQmVuLA0KPg0K PiBUaGFua3MgZm9yIHRoZSByZXZpZXcuDQo+DQo+PiBBcmUgdGhlIOKAnGFwcGxpY2F0aW9uc+KA nSBmcm9tIHBhcmFncmFwaCAzIHRoZSBzYW1lIGFzIHRob3NlIGZyb20gcGFyYWdyYXBoIDI/DQo+ DQo+IFllcywgdGhlIHNhbWUgdGhyb3VnaG91dCBwYXJhZ3JhcGhzIDEsIDIgYW5kIDMuDQo+DQo+ PiBJdCBzZWVtcyBsaWtlIHBhcmFncmFwaCAyIGlzIHRhbGtpbmcgbW9yZSBhYm91dCBsb2NhbCBB UElzIChhdCBsZWFzdCwgSSBzZWUgdGhhdCB3YXMgbWVudGlvbmVkIGluIHRoZSB0ZXh0IGluIHZl cnNpb24gMTcgYnV0IG5vdCBpbiAxOCksIGJ1dCBwYXJhZ3JhcGggMyB1c2VzIGFuIGV4YW1wbGUg b2YgYSBzaWduYWwgZnJvbSBhIHNlcnZlci4gKEkgY2FuIGFjY2VwdCB0aGF0IHRoZSBkaWZmZXJl bmNlIGluIGNvbnRyb2wgbWF5IGJlIHdlYWsgZW5vdWdoIGZvciB3ZWIgYXBwbGljYXRpb25zIHRo YXQgdGhlIGRpc3RpbmN0aW9uIGRvZXMgbm90IG1hdHRlci4pDQo+DQo+IFRoZSBBUElzIHByb3Zp ZGVkIGJ5IHRoZSBUQiBpbXBsZW1lbnRhdGlvbiBhbmQgY2FsbGVkIGJ5IHRoZSBhcHBsaWNhdGlv biBhcmUgbG9jYWwgQVBJcy4NCj4gVGhlIGFwcGxpY2F0aW9uIG5lZWRzIHRvIG1ha2UgYSBkZWNp c2lvbiB3aGV0aGVyIHRvIHJlcXVlc3QgdGhhdCB0aGUgVEIgaW1wbGVtZW50YXRpb24gaW5jbHVk ZSBhIFJlZmVycmVkIGJpbmRpbmcgaW4gdGhlIFRCIG1lc3NhZ2Ugb3Igbm90Lg0KPiBJbiB0aGUg ZXhhbXBsZSwgdGhlIHNlcnZlciBwcm92aWRlcyBhIHNpZ25hbCB0byB0aGUgYXBwbGljYXRpb24g dXNpbmcgdGhlIEluY2x1ZGUtUmVmZXJyZWQtVG9rZW4tQmluZGluZy1JRCBIVFRQIHJlc3BvbnNl IGhlYWRlci4NCj4gVGhlIHNpZ25hbCBjb3VsZCBiZSBkaWZmZXJlbnQsIG9yIGFuIGFwcGxpY2F0 aW9uIG1heSBoYXZlIG91dC1vZi1iYW5kIHdheXMgdG8gZGV0ZXJtaW5lIHRoaXMgKGUuZy4gYSBs b2NhbCBkYXRhYmFzZSBvZiBSUC0+SURQIGFzc29jaWF0aW9ucykuDQoNCkkganVzdCByZS1yZWFk IHRoZSAzcmQgcGFyYWdyYXBoLCBhbmQgSSB0aGluayBJIG1pc3NlZCB0aGUg4oCcdGhlbuKAnSBp biDigJx3aGljaCB0aGVuIHNpZ25hbHPigJ0gb24gdGhlIGZpcnN0IHJlYWRpbmcuIEl04oCZcyBm aW5lIGFzIGlzLg0KDQpUaGFua3MhDQoNCkJlbi4NCg0KPg0KPiBDaGVlcnMsDQo+DQo+IEFuZHJl aQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW4gQ2FtcGJlbGwg PGJlbkBub3N0cnVtLmNvbTxtYWlsdG86YmVuQG5vc3RydW0uY29tPj4NCj4gU2VudDogVHVlc2Rh eSwgSnVuZSAyNiwgMjAxOCAxMTo0MSBBTQ0KPiBUbzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0u Y29tPG1haWx0bzpla3JAcnRmbS5jb20+Pg0KPiBDYzogRGlyayBCYWxmYW56IDxiYWxmYW56PTQw Z29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYu b3JnPj47IGRyYWZ0LWlldGYtdG9rYmluZC1odHRwc0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0 Zi10b2tiaW5kLWh0dHBzQGlldGYub3JnPjsgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9y ZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZzxt YWlsdG86aWVzZ0BpZXRmLm9yZz4+OyBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1h aWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+OyB0b2tiaW5kLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86 dG9rYmluZC1jaGFpcnNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gQmVu IENhbXBiZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMTQ6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+DQo+IEhpLCB0aGFua3MgZm9yIHRoZSBwb2ludGVyLg0K Pg0KPiBUaGUgdGV4dCBpbiB2ZXJzaW9uIDE4IGlzIHN1ZmZpY2llbnQgdG8gY2xlYXIgbXkgZGlz Y3Vzcy4gSSBoYXZlIG9uZSByZW1haW5pbmcgKG9yIG1heWJlIG5ldykgbm9uLWJsb2NraW5nIHF1 ZXN0aW9uIGZvciBzZWN0aW9uIDY6DQo+DQo+IEFyZSB0aGUg4oCcYXBwbGljYXRpb25z4oCdIGZy b20gcGFyYWdyYXBoIDMgdGhlIHNhbWUgYXMgdGhvc2UgZnJvbSBwYXJhZ3JhcGggMj8gSXQgc2Vl bXMgbGlrZSBwYXJhZ3JhcGggMiBpcyB0YWxraW5nIG1vcmUgYWJvdXQgbG9jYWwgQVBJcyAoYXQg bGVhc3QsIEkgc2VlIHRoYXQgd2FzIG1lbnRpb25lZCBpbiB0aGUgdGV4dCBpbiB2ZXJzaW9uIDE3 IGJ1dCBub3QgaW4gMTgpLCBidXQgcGFyYWdyYXBoIDMgdXNlcyBhbiBleGFtcGxlIG9mIGEgc2ln bmFsIGZyb20gYSBzZXJ2ZXIuIChJIGNhbiBhY2NlcHQgdGhhdCB0aGUgZGlmZmVyZW5jZSBpbiBj b250cm9sIG1heSBiZSB3ZWFrIGVub3VnaCBmb3Igd2ViIGFwcGxpY2F0aW9ucyB0aGF0IHRoZSBk aXN0aW5jdGlvbiBkb2VzIG5vdCBtYXR0ZXIuKQ0KPg0KPiBJIGRpZCBub3QgY2hlY2sgbXkgZWRp dG9yaWFsIGNvbW1lbnRzLg0KPg0KPiBUaGFua3MhDQo+DQo+IEJlbi4NCj4NCj4+IE9uIEp1biAy NSwgMjAxOCwgYXQgNjozMCBQTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpl a3JAcnRmbS5jb20+PiB3cm90ZToNCj4+DQo+PiBCZW4sDQo+Pg0KPj4gRG9lcyB0aGUgZm9sbG93 aW5nIG5ldyB0ZXh0IGFkZHJlc3MgeW91ciBjb25jZXJuOg0KPj4gaHR0cHM6Ly94bWwycmZjLnRv b2xzLmlldGYub3JnL2NnaS1iaW4veG1sMnJmYy5jZ2k/bW9kZUFzRm9ybWF0PWh0bWwvYTxodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnhtbDJyZmMudG9vbHMuaWV0Zi5vcmclMkZjZ2ktYmluJTJGeG1sMnJmYy5jZ2klM0Ztb2Rl QXNGb3JtYXQlM0RodG1sJTJGYSZkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3Nv ZnQuY29tJTdDZjU3YTkwNWFlODhlNDg1MGZiODgwOGQ1ZGJhOWQ1MjQlN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjU2NDQ0ODQyMTY0MjYzJnNkYXRhPVkl MkJSRXA1VUU1Sm05eVVlc2hGSjFlWGJsbmZzMEM1VzMxdUclMkZrNm10SU8wJTNEJnJlc2VydmVk PTA+DQo+PiBzY2lpJnVybD1odHRwczovL3Jhdy5naXRodWJ1c2VyY29udGVudC5jb20vVG9rZW5C aW5kaW5nL0ludGVybmV0LURyYWZ0PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSUy RlRva2VuQmluZGluZyUyRkludGVybmV0LURyYWZ0JmRhdGE9MDIlN0MwMSU3Q0FuZHJlaS5Qb3Bv diU0MG1pY3Jvc29mdC5jb20lN0NmNTdhOTA1YWU4OGU0ODUwZmI4ODA4ZDVkYmE5ZDUyNCU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2NTY0NDQ4NDIxNzQy NzEmc2RhdGE9TGc3WUJEdjJ5RVpQM3BZTWt6dHhldzl1MzR4aHROblk4b2N2THV1akQ4TSUzRCZy ZXNlcnZlZD0wPg0KPj4gcy9tYXN0ZXIvZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTE4LnhtbA0K Pj4NCj4+DQo+PiBPbiBNb24sIEp1biA0LCAyMDE4IGF0IDE6MjYgUE0sIERpcmsgQmFsZmFueiA8 YmFsZmFuej00MGdvb2dsZS4uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGdvb2dsZS4uY29t QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+PiBIaSBCZW4sDQo+Pg0KPj4gdGhhbmtzIGZvciB0 aGUgZmVlZGJhY2suIE1vc3Qgb2YgaXQgaXMgYWRkcmVzc2VkIGluIHRoZSBuZXcgZHJhZnQgKGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMTY8aHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMTYm ZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3Q2Y1N2E5MDVhZTg4 ZTQ4NTBmYjg4MDhkNWRiYTlkNTI0JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjY1NjQ0NDg0MjE4NDI3OSZzZGF0YT1JSkhZREpTV29VeTVBbzhFV2oxbEhu OHM1V3VxVENEJTJGSDVoQVZibU1kVmslM0QmcmVzZXJ2ZWQ9MD4pLiBTZWUgYmVsb3cgKGlubGlu ZSkgZm9yIGRldGFpbHMuDQo+Pg0KPj4gT24gV2VkLCBNYXkgOSwgMjAxOCBhdCAxOjM4IFBNIEJl biBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+PiB3cm90 ZToNCj4+IEJlbiBDYW1wYmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCj4+IGRyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0xNDogRGlzY3Vzcw0KPj4NCj4+ IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbA0KPj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0DQo+PiB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KPj4NCj4+DQo+PiBQbGVhc2UgcmVmZXIgdG8NCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDxodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3 dy5pZXRmLm9yZyUyRmllc2clMkZzdGF0ZW1lbnQlMkZkaXNjdXNzLWNyaXRlcmlhLmh0bWwmZGF0 YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3Q2Y1N2E5MDVhZTg4ZTQ4 NTBmYjg4MDhkNWRiYTlkNTI0JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjY1NjQ0NDg0MjE4NDI3OSZzZGF0YT1pcnNEMGJlb1IxdmJuTW0lMkZCNXZyREY0 Z3dBczRISHVsWEV1bXpqRkpqME0lM0QmcmVzZXJ2ZWQ9MD4NCj4+IGZvciBtb3JlIGluZm9ybWF0 aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+Pg0KPj4NCj4+ IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg Zm91bmQgaGVyZToNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdG9rYmluZC1odHRwcy88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRy YWZ0LWlldGYtdG9rYmluZC1odHRwcyUyRiZkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBt aWNyb3NvZnQuY29tJTdDZjU3YTkwNWFlODhlNDg1MGZiODgwOGQ1ZGJhOWQ1MjQlN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjU2NDQ0ODQyMTk0Mjg4JnNk YXRhPW0zYXEyTGVXaXM0UFpteXNVWmVWYiUyRmFpJTJCcUVhZXdnJTJCQWx2OEJCNjglMkZ4TSUz RCZyZXNlcnZlZD0wPg0KPj4NCj4+DQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gRElTQ1VTUzoN Cj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+PiBJIHBsYW4gdG8gYmFsbG90ICJZRVMiLCBidXQgSSB3 YW50IHRvIGNsZWFyIHVwIG9uY2UgY29uY2VybiBmaXJzdDoNCj4+DQo+PiBBZnRlciByZWFkaW5n IHNlY3Rpb24gNiBzZXZlcmFsIHRpbWVzLCBJIGRvbid0IGtub3cgd2hhdCBpdCBtZWFucy4gSQ0K Pj4gdGhpbmsgaXQncyBbLi4uXQ0KPj4NCj4+IEFkZHJlc3NlZCBpbiBuZXcgZHJhZnQuDQo+Pg0K Pj4NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IENPTU1FTlQ6DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0K Pj4gU3Vic3RhbnRpdmUgQ29tbWVudHM6DQo+Pg0KPj4gwqcxLjE6IFBsZWFzZSBjb25zaWRlciB1 c2luZyB0aGUgYm9pbGVycGxhdGUgZnJvbSA4MTc0IGFjcm9zcyB0aGUNCj4+IGNsdXN0ZXIuIEJv dGggdGhpcyBhbmQgdGhlIHByb3RvY29sIGRyYWZ0IGhhdmUgbG93ZXIgY2FzZSBrZXl3b3JkIGlu c3RhbmNlcy4NCj4+DQo+PiBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Lg0KPj4NCj4+DQo+PiDCpzgu MjoNCj4+IC0gRG9lcyBpdCByZWFsbHkgbWFrZSBzZW5zZSB0byB3YWl0IGZvciBhIHVzZXIgdG8g cmVxdWVzdCB0aGUga2V5cyBiZSBleHBpcmVkPw0KPj4gSSBzdXNwZWN0IHRoZSBhdmVyYWdlIHVz ZXIgZG9lcyB0aGlzIGFib3V0IG5ldmVyLiBEaWQgdGhlIHdvcmtpbmcNCj4+IGdyb3VwIGRpc2N1 c3MgcG9zc2libHkgbWFraW5nIHRoZSBrZXlzIGRlZmF1bHQgdG8gZXhwaXJpbmcgYWZ0ZXIgc29t ZSBwZXJpb2Qgb2YgdGltZT8NCj4+DQo+PiBZZXMsIHdlIGRpZCBkaXNjdXNzIGl0LiBUaGlzIHdh cyBjaG9zZW4gY29uc2Npb3VzbHkgdG8gYmUgaW4gc3luYyB3aXRoIGNvb2tpZXMgYW5kIHRoZWly IGV4cGlyYXRpb25zIC8gbWFudWFsIHVzZXItaW5pdGlhdGVkIHB1cmdlcy4NCj4+DQo+PiAtIFdo eQ0KPj4gaXMgdGhlIFNIT1VMRCBpbiBwYXJhZ3JhcGggMiBub3QgYSBNVVNUPw0KPj4NCj4+IEFk ZHJlc3NlZCBpbiBuZXcgZHJhZnQuDQo+Pg0KPj4NCj4+IEVkaXRvcmlhbCBDb21tZW50czoNCj4+ DQo+PiDCpzI6DQo+PiAtIFBhcmFncmFwaCAxOiAiVGhlIEFCTkYgb2YgdGhlIFNlYy1Ub2tlbi1C aW5kaW5nIGhlYWRlciBmaWVsZCBpcyAoaW4NCj4+IFtSRkM3MjMwXSBzdHlsZSwgc2VlIGFsc28g U2VjdGlvbiA4LjMgb2YgW1JGQzcyMzFdKToiIFRoZSBvcGVuIHBhcmVudGhlc2lzIGJlZm9yZSAi aW4iDQo+PiBzZWVtcyBtaXNwbGFjZWQuIEFsc28sIGFzIHdyaXR0ZW4gdGhlIGNvbW1hIGFmdGVy ICJzdHlsZSIgY3JlYXRlcyBhDQo+PiBjb21tYSBzcGxpY2UuIChOb3RlIHRoYXQgdGhpcyBwYXR0 ZXJuIG9jY3VycyBlbHNld2hlcmUgaW4gdGhlDQo+PiBkb2N1bWVudC4pDQo+Pg0KPj4gLSBQYXJh Z3JhcGggMzogVGhlIHBhcmFncmFwaCBpcyBhIHNpbmdsZSBoYXJkLXRvLXBhcnNlIHNlbnRlbmNl Lg0KPj4gUGxlYXNlIGNvbnNpZGVyIGJyZWFraW5nIGludG8gc2ltcGxlciBzZW50ZW5jZXMuDQo+ Pg0KPj4gQWRkcmVzc2VkIGluIG5ldyBkcmFmdC4NCj4+DQo+Pg0KPj4gLSBleGFtcGxlOiBBbSBJ IGNvcnJlY3QgdG8gYXNzdW1lIHRoZSBiYWNrc2xhc2hlcyBhcmUganVzdCBmb3IgcHJpbnQNCj4+ IHB1cnBvc2VzIGFuZCBhcmUgbm90IGluIHRoZSBhY3R1YWwgbWVzc2FnZT8gSWYgc28sIHBsZWFz ZSBtZW50aW9uIHRoYXQuDQo+Pg0KPj4gQWRkcmVzc2VkIGluIG5ldyBkcmFmdC4NCj4+DQo+Pg0K Pj4gwqcgMi4xOg0KPj4gLSBmaXJzdCBwYXJhZ3JhcGgsICJXaXRoaW4gdGhlIGxhdHRlciBjb250 ZXh0Li4uIjogVGhlcmUgd2FzIG5vIGZvcm1lciBjb250ZXh0Lg0KPj4gSSBzdWdnZXN0ICJXaXRo aW4gdGhhdCBjb250ZXh0Li4uIg0KPj4NCj4+IEFkZHJlc3NlZCBpbiBuZXcgZHJhZnQuDQo+Pg0K Pj4gLSAybmQgcGFyYWdyYXBoOiBUaGUgZmlyc3Qgc2VudGVuY2UgaXMgaGFyZCB0byBwYXJzZS4g SSBzdWdnZXN0DQo+PiBicmVha2luZyBpdCBpbnRvIHNlcGFyYXRlIHBhcmFncmFwaHMsIG9yIHJl c3RydWN0dXJlIHdpdGhvdXQgdGhlDQo+PiBjZW50ZXItaW1iZWRkaW5nLg0KPj4NCj4+IEFkZHJl c3NlZCBpbiBuZXcgZHJhZnQuDQo+Pg0KPj4gLSAybmQgdG8gbGFzdCBwYXJhZ3JhcGg6IERvZXMg IlNIT1VMRCBnZW5lcmFsbHkiDQo+PiBtZWFuIHRoZSBzYW1lIGFzIGp1c3QgIlNIT1VMRCI/DQo+ Pg0KPj4gQWRkcmVzc2VkIGluIG5ldyBkcmFmdC4NCj4+DQo+Pg0KPj4gwqc1LjE6IDJuZCBwYXJh Z3JhcGg6IFVubmVlZGVkIGNvbW1hIGluICIuLi4gaXRzZWxmLCB0byBhbm90aGVyIHNlcnZlci4u LiINCj4+DQo+PiBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Lg0KPj4NCj4+DQo+PiDCpzUuMiwNCj4+ IC0gbGFzdCBidWxsZXQ6ICIgKGJldHdlZW4gY2xpZW50IGFuZCBUb2tlbiBDb25zdW1lcikiIHNl ZW1zIG1vcmUgdGhhbg0KPj4gcGFyZW50aGV0aWNhbC4gUGxlYXNlIGNvbnNpZGVyIHJlbW92aW5n IHRoZSBwYXJlbnRoZXNlcy4NCj4+DQo+PiBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Lg0KPj4NCj4+ IC0gcGFyYWdyYXBoIGFmdGVyIGxhc3QNCj4+IGJ1bGxldDogVGhlIHBhcmVudGhldGljYWwgcGhy YXNlIHN0YXJ0aW5nIHdpdGggIihwcm92aW5nDQo+PiBwb3NzZXNzaW9uLi4uKSBpcyBxdWl0ZSBs b25nIGFuZCBtYWtlcyB0aGUgc2VudGVuY2UgaGFyZCB0byBwYXJzZS4NCj4+IEdpdmVuIHRoYXQg dGhlIGNvbmNlcHQgaXMgY292ZXJlZCBpbiB0aGUgaW1tZWRpYXRlbHkgcHJlY2VkaW5nIHBhcmFn cmFwaCwgY2FuIGl0IGJlIHJlbW92ZWQ/DQo+Pg0KPj4gQWRkcmVzc2VkIGluIG5ldyBkcmFmdC4N Cj4+DQo+Pg0KPj4gwqc3LjEgYW5kIMKnNy4yOiBUaGVzZSBzZWN0aW9ucyBzZWVtIHRvIGJlIGNv cGllZCBmcm9tIChvciByZXN0YXRlDQo+PiByZXF1aXJlbWVudHMNCj4+IGluKSB0aGUgcHJvdG9j b2wgYW5kIG5lZ290aWF0aW9uIGRyYWZ0cy4gQ2FuIHRoZXkgYmUgaW5jbHVkZWQgYnkNCj4+IHJl ZmVyZW5jZSBpbnN0ZWFkLCBvciBhdCBsZWFzdCBhdHRyaWJ1dGVkPw0KPj4NCj4+IEFkZHJlc3Nl ZCBpbiBuZXcgZHJhZnQuDQo+Pg0KPj4NCj4+IMKnNy4yLCAybmQgcGFyYWdyYXBoOiBUaGlzIHNl YW1zIGxpa2UgYSByZXN0YXRlbWVudCBvZiDCpzcuMS4NCj4+DQo+PiBBZGRyZXNzZWQgaW4gbmV3 IGRyYWZ0Lg0KPj4NCj4+DQo+PiDCpzguMzogVW5uZWVkZWQgY29tbWEgaW4gZmlyc3Qgc2VudGVu Y2UuDQo+Pg0KPj4gQWRkcmVzc2VkIGluIG5ldyBkcmFmdC4NCj4+DQo+PiBUaGFua3MgYWdhaW4g Zm9yIHRoZSB0aG91Z2h0ZnVsIGNvbW1lbnRzIQ0KPj4NCj4+IERpcmsuDQo+Pg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFVuYmVhcmFibGUg bWFpbGluZyBsaXN0DQo+PiBVbmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGll dGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJh YmxlPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdW5iZWFyYWJs ZSZkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdDZjU3YTkwNWFl ODhlNDg1MGZiODgwOGQ1ZGJhOWQ1MjQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2NjU2NDQ0ODQyMTk0Mjg4JnNkYXRhPU5MWXpxTEljOWQ5cUgwVlRiRGND JTJCWWRZYVNSJTJCczY1M2VCcFE2QWxrJTJGYkElM0QmcmVzZXJ2ZWQ9MD4NCj4+DQo+Pg0KPg0K --_000_CY4PR21MB077453A70AC47C98C59C21088C490CY4PR21MB0774namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5E b25lOiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LXRva2JpbmQtaHR0cHMvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtdG9rYmluZC1odHRwcy88L2E+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDsgPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEp1bmUgMjYsIDIwMTggMjoxNCBQTTxicj4NCjxiPlRvOjwvYj4gQmVu IENhbXBiZWxsICZsdDtiZW5Abm9zdHJ1bS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBbmRyZWkg UG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0OzsgRXJpYyBSZXNjb3JsYSAm bHQ7ZWtyQHJ0Zm0uY29tJmd0OzsgRGlyayBCYWxmYW56ICZsdDtiYWxmYW56PTQwZ29vZ2xlLmNv bUBkbWFyYy5pZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtdG9rYmluZC1odHRwc0BpZXRmLm9yZzsg VG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs7IElFU0cgJmx0O2llc2dAaWV0 Zi5vcmcmZ3Q7OyB0b2tiaW5kLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW1VuYmVhcmFibGVdIEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10b2ti aW5kLWh0dHBzLTE0OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBTIEkgc3VwcG9zZSB3ZSBuZWVkIERJUksgT1IgQW5kcmUg dG8gcHVzaCBhIHZlcnNpb24gd2l0aCB0aGUgY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5Kb2huIEIuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVuIDI2LCAyMDE4LCA1OjEyIFBNIEpvaG4gQnJhZGxleSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBCZW4uPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FS1Igb25jZSB0aGlzIERpc2N1c3MgaXMgY2xlYXJlZCBh cmUgd2UgZ29vZCB0byBtb3ZlIG9uIHRvIHRoZSBmaW5hbCBlbWJyYWNlIG9mIHRoZSBSRkMgZWRp dG9yPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SZWdhcmRzJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Kb2huIEIuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVuIDI2LCAyMDE4LCAyOjU4IFBN IEJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbkBub3N0cnVtLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmJlbkBub3N0cnVtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQomZ3Q7IE9uIEp1biAyNiwgMjAxOCwgYXQgMTo1NCBQ TSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29m dC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBCZW4sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoYW5rcyBmb3IgdGhlIHJldmlldy48YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IEFyZSB0aGUg 4oCcYXBwbGljYXRpb25z4oCdIGZyb20gcGFyYWdyYXBoIDMgdGhlIHNhbWUgYXMgdGhvc2UgZnJv bSBwYXJhZ3JhcGggMj88YnI+DQomZ3Q7IDxicj4NCiZndDsgWWVzLCB0aGUgc2FtZSB0aHJvdWdo b3V0IHBhcmFncmFwaHMgMSwgMiBhbmQgMy48YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IEl0IHNl ZW1zIGxpa2UgcGFyYWdyYXBoIDIgaXMgdGFsa2luZyBtb3JlIGFib3V0IGxvY2FsIEFQSXMgKGF0 IGxlYXN0LCBJIHNlZSB0aGF0IHdhcyBtZW50aW9uZWQgaW4gdGhlIHRleHQgaW4gdmVyc2lvbiAx NyBidXQgbm90IGluIDE4KSwgYnV0IHBhcmFncmFwaCAzIHVzZXMgYW4gZXhhbXBsZSBvZiBhIHNp Z25hbCBmcm9tIGEgc2VydmVyLiAoSSBjYW4gYWNjZXB0IHRoYXQgdGhlIGRpZmZlcmVuY2UgaW4g Y29udHJvbCBtYXkgYmUgd2VhayBlbm91Z2gNCiBmb3Igd2ViIGFwcGxpY2F0aW9ucyB0aGF0IHRo ZSBkaXN0aW5jdGlvbiBkb2VzIG5vdCBtYXR0ZXIuKTxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUg QVBJcyBwcm92aWRlZCBieSB0aGUgVEIgaW1wbGVtZW50YXRpb24gYW5kIGNhbGxlZCBieSB0aGUg YXBwbGljYXRpb24gYXJlIGxvY2FsIEFQSXMuPGJyPg0KJmd0OyBUaGUgYXBwbGljYXRpb24gbmVl ZHMgdG8gbWFrZSBhIGRlY2lzaW9uIHdoZXRoZXIgdG8gcmVxdWVzdCB0aGF0IHRoZSBUQiBpbXBs ZW1lbnRhdGlvbiBpbmNsdWRlIGEgUmVmZXJyZWQgYmluZGluZyBpbiB0aGUgVEIgbWVzc2FnZSBv ciBub3QuPGJyPg0KJmd0OyBJbiB0aGUgZXhhbXBsZSwgdGhlIHNlcnZlciBwcm92aWRlcyBhIHNp Z25hbCB0byB0aGUgYXBwbGljYXRpb24gdXNpbmcgdGhlIEluY2x1ZGUtUmVmZXJyZWQtVG9rZW4t QmluZGluZy1JRCBIVFRQIHJlc3BvbnNlIGhlYWRlci48YnI+DQomZ3Q7IFRoZSBzaWduYWwgY291 bGQgYmUgZGlmZmVyZW50LCBvciBhbiBhcHBsaWNhdGlvbiBtYXkgaGF2ZSBvdXQtb2YtYmFuZCB3 YXlzIHRvIGRldGVybWluZSB0aGlzIChlLmcuIGEgbG9jYWwgZGF0YWJhc2Ugb2YgUlAtJmd0O0lE UCBhc3NvY2lhdGlvbnMpLjxicj4NCjxicj4NCkkganVzdCByZS1yZWFkIHRoZSAzcmQgcGFyYWdy YXBoLCBhbmQgSSB0aGluayBJIG1pc3NlZCB0aGUg4oCcdGhlbuKAnSBpbiDigJx3aGljaCB0aGVu IHNpZ25hbHPigJ0gb24gdGhlIGZpcnN0IHJlYWRpbmcuIEl04oCZcyBmaW5lIGFzIGlzLjxicj4N Cjxicj4NClRoYW5rcyE8YnI+DQo8YnI+DQpCZW4uPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IENoZWVycyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgQW5kcmVpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBCZW4gQ2FtcGJlbGwg Jmx0OzxhIGhyZWY9Im1haWx0bzpiZW5Abm9zdHJ1bS5jb20iIHRhcmdldD0iX2JsYW5rIj5iZW5A bm9zdHJ1bS5jb208L2E+Jmd0Ozxicj4NCiZndDsgU2VudDogVHVlc2RheSwgSnVuZSAyNiwgMjAx OCAxMTo0MSBBTTxicj4NCiZndDsgVG86IEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0 bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0Ozxicj4N CiZndDsgQ2M6IERpcmsgQmFsZmFueiAmbHQ7YmFsZmFuej08YSBocmVmPSJtYWlsdG86NDBnb29n bGUuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBnb29nbGUuY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi10b2tiaW5kLWh0 dHBzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzQGll dGYub3JnPC9hPjsgVG9rYmluZCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPiZndDs7IFRoZSBJ RVNHICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmll c2dAaWV0Zi5vcmc8L2E+Jmd0OzsNCiBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2 ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZn dDs7DQo8YSBocmVmPSJtYWlsdG86dG9rYmluZC1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj50b2tiaW5kLWNoYWlyc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBb VW5iZWFyYWJsZV0gQmVuIENhbXBiZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRva2JpbmQt aHR0cHMtMTQ6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEhpLCB0aGFua3MgZm9yIHRoZSBwb2ludGVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgdGV4 dCBpbiB2ZXJzaW9uIDE4IGlzIHN1ZmZpY2llbnQgdG8gY2xlYXIgbXkgZGlzY3Vzcy4gSSBoYXZl IG9uZSByZW1haW5pbmcgKG9yIG1heWJlIG5ldykgbm9uLWJsb2NraW5nIHF1ZXN0aW9uIGZvciBz ZWN0aW9uIDY6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFyZSB0aGUg4oCcYXBwbGljYXRpb25z4oCd IGZyb20gcGFyYWdyYXBoIDMgdGhlIHNhbWUgYXMgdGhvc2UgZnJvbSBwYXJhZ3JhcGggMj8gSXQg c2VlbXMgbGlrZSBwYXJhZ3JhcGggMiBpcyB0YWxraW5nIG1vcmUgYWJvdXQgbG9jYWwgQVBJcyAo YXQgbGVhc3QsIEkgc2VlIHRoYXQgd2FzIG1lbnRpb25lZCBpbiB0aGUgdGV4dCBpbiB2ZXJzaW9u IDE3IGJ1dCBub3QgaW4gMTgpLCBidXQgcGFyYWdyYXBoIDMgdXNlcyBhbiBleGFtcGxlIG9mIGEg c2lnbmFsDQogZnJvbSBhIHNlcnZlci4gKEkgY2FuIGFjY2VwdCB0aGF0IHRoZSBkaWZmZXJlbmNl IGluIGNvbnRyb2wgbWF5IGJlIHdlYWsgZW5vdWdoIGZvciB3ZWIgYXBwbGljYXRpb25zIHRoYXQg dGhlIGRpc3RpbmN0aW9uIGRvZXMgbm90IG1hdHRlci4pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkg ZGlkIG5vdCBjaGVjayBteSBlZGl0b3JpYWwgY29tbWVudHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoYW5rcyE8YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVuLjxicj4NCiZndDsgPGJyPg0KJmd0OyZn dDsgT24gSnVuIDI1LCAyMDE4LCBhdCA2OjMwIFBNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVm PSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQmVuLDxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IERvZXMgdGhlIGZvbGxvd2luZyBuZXcgdGV4dCBhZGRyZXNzIHlvdXIg Y29uY2Vybjo8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnhtbDJyZmMudG9vbHMuaWV0 Zi5vcmclMkZjZ2ktYmluJTJGeG1sMnJmYy5jZ2klM0Ztb2RlQXNGb3JtYXQlM0RodG1sJTJGYSZh bXA7ZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3Q2Y1N2E5MDVh ZTg4ZTQ4NTBmYjg4MDhkNWRiYTlkNTI0JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN0MxJTdDMCU3QzYzNjY1NjQ0NDg0MjE2NDI2MyZhbXA7c2RhdGE9WSUyQlJFcDVVRTVKbTl5 VWVzaEZKMWVYYmxuZnMwQzVXMzF1RyUyRms2bXRJTzAlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8veG1sMnJmYy50b29scy5pZXRmLm9yZy9jZ2ktYmluL3htbDJy ZmMuY2dpP21vZGVBc0Zvcm1hdD1odG1sL2E8L2E+PGJyPg0KJmd0OyZndDsgc2NpaSZhbXA7dXJs PTxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSUyRlRva2VuQmluZGlu ZyUyRkludGVybmV0LURyYWZ0JmFtcDtkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNy b3NvZnQuY29tJTdDZjU3YTkwNWFlODhlNDg1MGZiODgwOGQ1ZGJhOWQ1MjQlN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjU2NDQ0ODQyMTc0MjcxJmFtcDtz ZGF0YT1MZzdZQkR2MnlFWlAzcFlNa3p0eGV3OXUzNHhodE5uWThvY3ZMdXVqRDhNJTNEJmFtcDty ZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQu Y29tL1Rva2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdDwvYT48YnI+DQomZ3Q7Jmd0OyBzL21hc3Rl ci9kcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMTgueG1sPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgT24gTW9uLCBKdW4gNCwgMjAxOCBhdCAxOjI2IFBNLCBEaXJr IEJhbGZhbnogJmx0O2JhbGZhbno9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLi5jb21AZG1hcmMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGdvb2dsZS4uY29tQGRtYXJjLmlldGYub3JnPC9h PiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgSGkgQmVuLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IHRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBNb3N0IG9mIGl0IGlzIGFkZHJlc3NlZCBp biB0aGUgbmV3IGRyYWZ0ICg8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUy RmRyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0xNiZhbXA7ZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBv cG92JTQwbWljcm9zb2Z0LmNvbSU3Q2Y1N2E5MDVhZTg4ZTQ4NTBmYjg4MDhkNWRiYTlkNTI0JTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY1NjQ0NDg0MjE4 NDI3OSZhbXA7c2RhdGE9SUpIWURKU1dvVXk1QW84RVdqMWxIbjhzNVd1cVRDRCUyRkg1aEFWYm1N ZFZrJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0xNjwvYT4pLg0KIFNlZSBiZWxvdyAo aW5saW5lKSBmb3IgZGV0YWlscy48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBPbiBXZWQs IE1heSA5LCAyMDE4IGF0IDE6MzggUE0gQmVuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86 YmVuQG5vc3RydW0uY29tIiB0YXJnZXQ9Il9ibGFuayI+YmVuQG5vc3RydW0uY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KJmd0OyZndDsgQmVuIENhbXBiZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj4NCiZndDsmZ3Q7IGRyYWZ0LWlldGYtdG9rYmluZC1o dHRwcy0xNDogRGlzY3Vzczxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFdoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFs bDxicj4NCiZndDsmZ3Q7IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dDxicj4NCiZndDsmZ3Q7IHRoaXMgaW50cm9kdWN0b3J5 IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgUGxlYXNlIHJlZmVyIHRvPGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3 d3cuaWV0Zi5vcmclMkZpZXNnJTJGc3RhdGVtZW50JTJGZGlzY3Vzcy1jcml0ZXJpYS5odG1sJmFt cDtkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdDZjU3YTkwNWFl ODhlNDg1MGZiODgwOGQ1ZGJhOWQ1MjQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2NjU2NDQ0ODQyMTg0Mjc5JmFtcDtzZGF0YT1pcnNEMGJlb1IxdmJuTW0l MkZCNXZyREY0Z3dBczRISHVsWEV1bXpqRkpqME0lM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3Jp dGVyaWEuaHRtbDwvYT48YnI+DQomZ3Q7Jmd0OyBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxs b3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi10b2tiaW5kLWh0 dHBzJTJGJmFtcDtkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdD ZjU3YTkwNWFlODhlNDg1MGZiODgwOGQ1ZGJhOWQ1MjQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjU2NDQ0ODQyMTk0Mjg4JmFtcDtzZGF0YT1tM2FxMkxl V2lzNFBabXlzVVplVmIlMkZhaSUyQnFFYWV3ZyUyQkFsdjhCQjY4JTJGeE0lM0QmYW1wO3Jlc2Vy dmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy88L2E+PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsm Z3Q7IERJU0NVU1M6PGJyPg0KJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7IEkgcGxhbiB0byBiYWxsb3QgJnF1b3Q7WUVTJnF1b3Q7LCBidXQgSSB3YW50 IHRvIGNsZWFyIHVwIG9uY2UgY29uY2VybiBmaXJzdDo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyBBZnRlciByZWFkaW5nIHNlY3Rpb24gNiBzZXZlcmFsIHRpbWVzLCBJIGRvbid0IGtub3cg d2hhdCBpdCBtZWFucy4gSTxicj4NCiZndDsmZ3Q7IHRoaW5rIGl0J3MgWy4uLl08YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0 OyBDT01NRU5UOjxicj4NCiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyBTdWJzdGFudGl2ZSBDb21tZW50czo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyDCpzEuMTogUGxlYXNlIGNvbnNpZGVyIHVzaW5nIHRoZSBib2lsZXJwbGF0ZSBmcm9tIDgx NzQgYWNyb3NzIHRoZTxicj4NCiZndDsmZ3Q7IGNsdXN0ZXIuIEJvdGggdGhpcyBhbmQgdGhlIHBy b3RvY29sIGRyYWZ0IGhhdmUgbG93ZXIgY2FzZSBrZXl3b3JkIGluc3RhbmNlcy48YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IMKnOC4yOjxicj4NCiZndDsmZ3Q7IC0gRG9l cyBpdCByZWFsbHkgbWFrZSBzZW5zZSB0byB3YWl0IGZvciBhIHVzZXIgdG8gcmVxdWVzdCB0aGUg a2V5cyBiZSBleHBpcmVkPzxicj4NCiZndDsmZ3Q7IEkgc3VzcGVjdCB0aGUgYXZlcmFnZSB1c2Vy IGRvZXMgdGhpcyBhYm91dCBuZXZlci4gRGlkIHRoZSB3b3JraW5nPGJyPg0KJmd0OyZndDsgZ3Jv dXAgZGlzY3VzcyBwb3NzaWJseSBtYWtpbmcgdGhlIGtleXMgZGVmYXVsdCB0byBleHBpcmluZyBh ZnRlciBzb21lIHBlcmlvZCBvZiB0aW1lPzxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFll cywgd2UgZGlkIGRpc2N1c3MgaXQuIFRoaXMgd2FzIGNob3NlbiBjb25zY2lvdXNseSB0byBiZSBp biBzeW5jIHdpdGggY29va2llcyBhbmQgdGhlaXIgZXhwaXJhdGlvbnMgLyBtYW51YWwgdXNlci1p bml0aWF0ZWQgcHVyZ2VzLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC0gV2h5PGJyPg0K Jmd0OyZndDsgaXMgdGhlIFNIT1VMRCBpbiBwYXJhZ3JhcGggMiBub3QgYSBNVVNUPzxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEFkZHJlc3NlZCBpbiBuZXcgZHJhZnQuPGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgRWRpdG9yaWFsIENvbW1lbnRzOjxicj4N CiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IMKnMjo8YnI+DQomZ3Q7Jmd0OyAtIFBhcmFncmFwaCAx OiAmcXVvdDtUaGUgQUJORiBvZiB0aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVyIGZpZWxkIGlz IChpbjxicj4NCiZndDsmZ3Q7IFtSRkM3MjMwXSBzdHlsZSwgc2VlIGFsc28gU2VjdGlvbiA4LjMg b2YgW1JGQzcyMzFdKTomcXVvdDsgVGhlIG9wZW4gcGFyZW50aGVzaXMgYmVmb3JlICZxdW90O2lu JnF1b3Q7PGJyPg0KJmd0OyZndDsgc2VlbXMgbWlzcGxhY2VkLiBBbHNvLCBhcyB3cml0dGVuIHRo ZSBjb21tYSBhZnRlciAmcXVvdDtzdHlsZSZxdW90OyBjcmVhdGVzIGE8YnI+DQomZ3Q7Jmd0OyBj b21tYSBzcGxpY2UuIChOb3RlIHRoYXQgdGhpcyBwYXR0ZXJuIG9jY3VycyBlbHNld2hlcmUgaW4g dGhlPGJyPg0KJmd0OyZndDsgZG9jdW1lbnQuKTxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 IC0gUGFyYWdyYXBoIDM6IFRoZSBwYXJhZ3JhcGggaXMgYSBzaW5nbGUgaGFyZC10by1wYXJzZSBz ZW50ZW5jZS48YnI+DQomZ3Q7Jmd0OyBQbGVhc2UgY29uc2lkZXIgYnJlYWtpbmcgaW50byBzaW1w bGVyIHNlbnRlbmNlcy48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBZGRyZXNzZWQgaW4g bmV3IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC0g ZXhhbXBsZTogQW0gSSBjb3JyZWN0IHRvIGFzc3VtZSB0aGUgYmFja3NsYXNoZXMgYXJlIGp1c3Qg Zm9yIHByaW50PGJyPg0KJmd0OyZndDsgcHVycG9zZXMgYW5kIGFyZSBub3QgaW4gdGhlIGFjdHVh bCBtZXNzYWdlPyBJZiBzbywgcGxlYXNlIG1lbnRpb24gdGhhdC48YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IMKnIDIuMTo8YnI+DQomZ3Q7Jmd0OyAtIGZpcnN0IHBhcmFn cmFwaCwgJnF1b3Q7V2l0aGluIHRoZSBsYXR0ZXIgY29udGV4dC4uLiZxdW90OzogVGhlcmUgd2Fz IG5vIGZvcm1lciBjb250ZXh0Ljxicj4NCiZndDsmZ3Q7IEkgc3VnZ2VzdCAmcXVvdDtXaXRoaW4g dGhhdCBjb250ZXh0Li4uJnF1b3Q7PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQWRkcmVz c2VkIGluIG5ldyBkcmFmdC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAtIDJuZCBwYXJh Z3JhcGg6IFRoZSBmaXJzdCBzZW50ZW5jZSBpcyBoYXJkIHRvIHBhcnNlLiBJIHN1Z2dlc3Q8YnI+ DQomZ3Q7Jmd0OyBicmVha2luZyBpdCBpbnRvIHNlcGFyYXRlIHBhcmFncmFwaHMsIG9yIHJlc3Ry dWN0dXJlIHdpdGhvdXQgdGhlPGJyPg0KJmd0OyZndDsgY2VudGVyLWltYmVkZGluZy48YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Ljxicj4NCiZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7IC0gMm5kIHRvIGxhc3QgcGFyYWdyYXBoOiBEb2VzICZxdW90O1NI T1VMRCBnZW5lcmFsbHkmcXVvdDs8YnI+DQomZ3Q7Jmd0OyBtZWFuIHRoZSBzYW1lIGFzIGp1c3Qg JnF1b3Q7U0hPVUxEJnF1b3Q7Pzxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEFkZHJlc3Nl ZCBpbiBuZXcgZHJhZnQuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgwqc1LjE6IDJuZCBwYXJhZ3JhcGg6IFVubmVlZGVkIGNvbW1hIGluICZxdW90Oy4uLiBpdHNl bGYsIHRvIGFub3RoZXIgc2VydmVyLi4uJnF1b3Q7PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgQWRkcmVzc2VkIGluIG5ldyBkcmFmdC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyDCpzUuMiw8YnI+DQomZ3Q7Jmd0OyAtIGxhc3QgYnVsbGV0OiAmcXVvdDsg KGJldHdlZW4gY2xpZW50IGFuZCBUb2tlbiBDb25zdW1lcikmcXVvdDsgc2VlbXMgbW9yZSB0aGFu PGJyPg0KJmd0OyZndDsgcGFyZW50aGV0aWNhbC4gUGxlYXNlIGNvbnNpZGVyIHJlbW92aW5nIHRo ZSBwYXJlbnRoZXNlcy48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBZGRyZXNzZWQgaW4g bmV3IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC0gcGFyYWdyYXBoIGFmdGVy IGxhc3Q8YnI+DQomZ3Q7Jmd0OyBidWxsZXQ6IFRoZSBwYXJlbnRoZXRpY2FsIHBocmFzZSBzdGFy dGluZyB3aXRoICZxdW90Oyhwcm92aW5nPGJyPg0KJmd0OyZndDsgcG9zc2Vzc2lvbi4uLikgaXMg cXVpdGUgbG9uZyBhbmQgbWFrZXMgdGhlIHNlbnRlbmNlIGhhcmQgdG8gcGFyc2UuPGJyPg0KJmd0 OyZndDsgR2l2ZW4gdGhhdCB0aGUgY29uY2VwdCBpcyBjb3ZlcmVkIGluIHRoZSBpbW1lZGlhdGVs eSBwcmVjZWRpbmcgcGFyYWdyYXBoLCBjYW4gaXQgYmUgcmVtb3ZlZD88YnI+DQomZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IMKnNy4xIGFuZCDCpzcuMjogVGhlc2Ugc2VjdGlvbnMg c2VlbSB0byBiZSBjb3BpZWQgZnJvbSAob3IgcmVzdGF0ZTxicj4NCiZndDsmZ3Q7IHJlcXVpcmVt ZW50czxicj4NCiZndDsmZ3Q7IGluKSB0aGUgcHJvdG9jb2wgYW5kIG5lZ290aWF0aW9uIGRyYWZ0 cy4gQ2FuIHRoZXkgYmUgaW5jbHVkZWQgYnk8YnI+DQomZ3Q7Jmd0OyByZWZlcmVuY2UgaW5zdGVh ZCwgb3IgYXQgbGVhc3QgYXR0cmlidXRlZD88YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBB ZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7IMKnNy4yLCAybmQgcGFyYWdyYXBoOiBUaGlzIHNlYW1zIGxpa2UgYSByZXN0YXRl bWVudCBvZiDCpzcuMS48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBZGRyZXNzZWQgaW4g bmV3IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IMKn OC4zOiBVbm5lZWRlZCBjb21tYSBpbiBmaXJzdCBzZW50ZW5jZS48YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyBBZGRyZXNzZWQgaW4gbmV3IGRyYWZ0Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIHRob3VnaHRmdWwgY29tbWVudHMhPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgRGlyay48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsm Z3Q7IFVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRv OlVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5VbmJlYXJhYmxlQGlldGYub3Jn PC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1h biUyRmxpc3RpbmZvJTJGdW5iZWFyYWJsZSZhbXA7ZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92 JTQwbWljcm9zb2Z0LmNvbSU3Q2Y1N2E5MDVhZTg4ZTQ4NTBmYjg4MDhkNWRiYTlkNTI0JTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY1NjQ0NDg0MjE5NDI4 OCZhbXA7c2RhdGE9TkxZenFMSWM5ZDlxSDBWVGJEY0MlMkJZZFlhU1IlMkJzNjUzZUJwUTZBbGsl MkZiQSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7IDxicj4NCiZndDsgPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_CY4PR21MB077453A70AC47C98C59C21088C490CY4PR21MB0774namp_-- From nobody Tue Jun 26 14:22:28 2018 Return-Path: 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 40D62130E3E for ; Tue, 26 Jun 2018 14:22:26 -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, HTML_MESSAGE=0.001, 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 G8NHv55JKf2n for ; Tue, 26 Jun 2018 14:22:24 -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 156C0130E2E for ; Tue, 26 Jun 2018 14:22:24 -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:X-MS-Exchange-SenderADCheck; bh=aG1brBqYyGALQUJo1BJXkL65V0lcp8AgBj1jZ7J7rIA=; b=g6JYzW3qzxeBb5ENpATUJGKbUAc+eFFJzxkLSYgoc8X2p4r/fojOMycln2p1/zQGUJ3W6JRX+aprE44Z+0ls6fMjOKaw1CcDilvf6+LRgQ/yXkg5dD9wM88Gol7sQRRg0CQjwsinBdMsR9H9rrs6jUSKhxsQJAJcqvaTlmsbaEI= Received: from CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) by CY4PR21MB0757.namprd21.prod.outlook.com (10.173.192.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.930.0; Tue, 26 Jun 2018 21:22:22 +0000 Received: from CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::9d01:113b:290a:750b]) by CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::9d01:113b:290a:750b%3]) with mapi id 15.20.0930.005; Tue, 26 Jun 2018 21:22:22 +0000 From: Andrei Popov To: Tokbind WG Thread-Topic: HTTPSTB-18 Thread-Index: AdQNk5H8p5oo2RcgQv2QVz9fJITo4w== Date: Tue, 26 Jun 2018 21:22:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:8:28b5:a023:971b:e42c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0757; 7:7pXgy5Fqq3PbZvmfZvq/GeRcRlWnVKvFQru9dSJE7FPAB9MSoy/lngbQIBt9uGazWqsv0Toth1O17eKquvEX+Yb/Z6W6460lx76gqF+OaiLB2inHs2U4tEfbmpuFXYCwY74QERtd32M0ulOYD8tMI13aRhaotIKCi2rI5gWXNjxVxE+IjbGmROBopWzltsAeUcYQkGbwu9bKy44+WQxt1Ra+ykuRAE8R6cI36upAeq8uryXvVbZJZ8cch79LzkfN x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d8f5a592-c21c-421a-e9bb-08d5dbaae7fd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:CY4PR21MB0757; x-ms-traffictypediagnostic: CY4PR21MB0757: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(2018427008)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:CY4PR21MB0757; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0757; x-forefront-prvs: 071518EF63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(366004)(39860400002)(136003)(189003)(199004)(2906002)(105586002)(6506007)(97736004)(102836004)(99286004)(25786009)(53936002)(106356001)(86612001)(186003)(7696005)(8990500004)(10290500003)(5250100002)(33656002)(68736007)(478600001)(22452003)(316002)(46003)(558084003)(6916009)(14454004)(5660300001)(6436002)(6116002)(486006)(790700001)(476003)(7736002)(2900100001)(8936002)(81166006)(86362001)(72206003)(81156014)(9686003)(10090500001)(54896002)(55016002)(8676002)(74316002)(6306002)(14444005)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0757; H:CY4PR21MB0774.namprd21.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) x-microsoft-antispam-message-info: u66hzLtInGw21Yc2nItoXjK0hOKxJhLbRR6m1ZupoKCdvaDVQxh6A4zyTa0INwZCD9XlMWQsAsmec3S8nqyGlfwKkxPuBi/JoEGyCpJirWY36yz49k/X1tFyApddr10lwKyhzC1vwhgIpzgYKCccnrqwcp1vZq0Ke+qkTKkD2pw4BoBoR1kkRxYm8a6IowVctF1GghyOFYAS/NPKjCmmMY6o3iRHhxdYpIvJoraznUDhJ7gDYKwfzY98L10rerlaN+Iskh7x7T7V0LW7HJ+3Zuw2KR47TGWrXvXh8VjXIRqPkxNGz3zoityBJARYqE//ECI2h/52lMmwvsrJx0dRbOcALHJREIJPshdTCoA1vns= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0774BB9DCFE944A2013C5C278C490CY4PR21MB0774namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: d8f5a592-c21c-421a-e9bb-08d5dbaae7fd X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 21:22:22.4652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0757 Archived-At: Subject: [Unbearable] HTTPSTB-18 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:22:27 -0000 --_000_CY4PR21MB0774BB9DCFE944A2013C5C278C490CY4PR21MB0774namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another editorial update of HTTPSTB has been uploaded, with Section 6 clari= fied in response to GEN-ART review. Cheers, Andrei --_000_CY4PR21MB0774BB9DCFE944A2013C5C278C490CY4PR21MB0774namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another editorial update of HTTPSTB has been uploade= d, with Section 6 clarified in response to GEN-ART review.

 

Cheers,

 

Andrei

--_000_CY4PR21MB0774BB9DCFE944A2013C5C278C490CY4PR21MB0774namp_-- From nobody Tue Jun 26 14:25:56 2018 Return-Path: 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 9DBA3130E3C for ; Tue, 26 Jun 2018 14:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.081 X-Spam-Level: X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 SC4G1UED2_uE for ; Tue, 26 Jun 2018 14:25:51 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32393130E40 for ; Tue, 26 Jun 2018 14:25:48 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id x15-v6so3902823ybm.2 for ; Tue, 26 Jun 2018 14:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eZ+shD6W2hfgrBNJlP4V4eT6FLHRwWuCc/WEv1aTZJs=; b=qHSTtOlhWChtzzMcxiL29+X5OPgJoIx5xPZxOL9waTK7Vi0jyh4xstPJgpYoQjwvmT bOfF+QjrLyk+7LWfWco4qdZNYZAsl2wfgvoYSRB3xIZ4oS65yoDpuQdRsoorVVUqCP8O KeA/fWyAML8G7Jo/J8PQSQookGjgdV7MnVbO9/M918cuzywl+ny4qmcyDFAmZHIXtrjs WGi2WodRugr3KeSo3N+4PPfzOjQoSbBMzFnex16RfIOL/e+8HT48GobL6UuZOtb0+6uN Lkb3zUdCEjVLJEGnVhGOWVqJGqcjrtM9zUYx/h+U6vqqw5clo6Q3XRrzymPShBdgEtFf 6goA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eZ+shD6W2hfgrBNJlP4V4eT6FLHRwWuCc/WEv1aTZJs=; b=rrSKrkgP2GieSJmyVH8BhUDyF+B0ss8k4pDp0m9i/mP0mtINE8Sr9U7ET343GnFbj8 Za2L4nBWHegKxe7/xt+lycEWbtdBYqvdJCvNXiLjxn0Wskrm+0jfN3oyRU6c+la7RyJu ChbQj+FgpPEhN6Z38/wMaQUwdDj+isNjsSX9wWM00oxrSlhHEVAAb6K60JhSXhPd7LzS 5SKsR4xyZCnSQqQwNf7oX0vm6eU8qLUefIFMobKVAspIR9+oBI/hObNb40Pc8Tzw/8kN zlcahPEm6InZ59zhZvryL/LjPw6WryuJqEIrr33z7vjUFYAPeDmNh8LTMWG52vcHPGFj CV/Q== X-Gm-Message-State: APt69E2DlSF37VWs4ZHBRfjDiwQfhjhnoMOQZB5VMa5H2IZNKoxfnmtb BXQqCvMozM9dKHO+sDde3cN1liHEBgb+y8W5HBbTCA== X-Google-Smtp-Source: ADUXVKJjbLoShFjDqq7bvOy/G5aJ2Ppwpp52bFaU1TYuShngXTeILEuyoabMSsAjp/g5tyrnCszb0NKvGP7IO0dK50c= X-Received: by 2002:a25:7c4:: with SMTP id 187-v6mr1798957ybh.73.1530048347313; Tue, 26 Jun 2018 14:25:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 14:25:06 -0700 (PDT) In-Reply-To: References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com> From: Eric Rescorla Date: Tue, 26 Jun 2018 14:25:06 -0700 Message-ID: To: Andrei Popov Cc: John Bradley , Ben Campbell , Dirk Balfanz , "draft-ietf-tokbind-https@ietf.org" , Tokbind WG , IESG , "tokbind-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003b2f85056f922497" Archived-At: Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:25:55 -0000 --0000000000003b2f85056f922497 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Should be, I need to do a double check to make sure other comments were dealt with, but assuming so, then yes. Should be able to do this tomorrow -Ekr On Tue, Jun 26, 2018 at 2:19 PM, Andrei Popov wrote: > Done: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/. > > > > *From:* John Bradley > *Sent:* Tuesday, June 26, 2018 2:14 PM > *To:* Ben Campbell > *Cc:* Andrei Popov ; Eric Rescorla < > ekr@rtfm.com>; Dirk Balfanz ; > draft-ietf-tokbind-https@ietf.org; Tokbind WG ; IESG > ; tokbind-chairs@ietf.org > > *Subject:* Re: [Unbearable] Ben Campbell's Discuss on > draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) > > > > PS I suppose we need DIRK OR Andre to push a version with the changes. > > > > John B. > > On Tue, Jun 26, 2018, 5:12 PM John Bradley wrote: > > Thanks Ben. > > > > EKR once this Discuss is cleared are we good to move on to the final > embrace of the RFC editor? > > > > Regards > > John B. > > > > On Tue, Jun 26, 2018, 2:58 PM Ben Campbell wrote: > > > > > On Jun 26, 2018, at 1:54 PM, Andrei Popov > wrote: > > > > Hi Ben, > > > > Thanks for the review. > > > >> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as th= ose from > paragraph 2? > > > > Yes, the same throughout paragraphs 1, 2 and 3. > > > >> It seems like paragraph 2 is talking more about local APIs (at least, = I > see that was mentioned in the text in version 17 but not in 18), but > paragraph 3 uses an example of a signal from a server. (I can accept that > the difference in control may be weak enough for web applications that th= e > distinction does not matter.) > > > > The APIs provided by the TB implementation and called by the applicatio= n > are local APIs. > > The application needs to make a decision whether to request that the TB > implementation include a Referred binding in the TB message or not. > > In the example, the server provides a signal to the application using > the Include-Referred-Token-Binding-ID HTTP response header. > > The signal could be different, or an application may have out-of-band > ways to determine this (e.g. a local database of RP->IDP associations). > > I just re-read the 3rd paragraph, and I think I missed the =E2=80=9Cthen= =E2=80=9D in > =E2=80=9Cwhich then signals=E2=80=9D on the first reading. It=E2=80=99s f= ine as is. > > Thanks! > > Ben. > > > > > Cheers, > > > > Andrei > > > > -----Original Message----- > > From: Ben Campbell > > Sent: Tuesday, June 26, 2018 11:41 AM > > To: Eric Rescorla > > Cc: Dirk Balfanz ; > draft-ietf-tokbind-https@ietf.org; Tokbind WG ; The > IESG ; John Bradley ; > tokbind-chairs@ietf.org > > Subject: Re: [Unbearable] Ben Campbell's Discuss on > draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) > > > > Hi, thanks for the pointer. > > > > The text in version 18 is sufficient to clear my discuss. I have one > remaining (or maybe new) non-blocking question for section 6: > > > > Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as tho= se from paragraph > 2? It seems like paragraph 2 is talking more about local APIs (at least, = I > see that was mentioned in the text in version 17 but not in 18), but > paragraph 3 uses an example of a signal from a server. (I can accept that > the difference in control may be weak enough for web applications that th= e > distinction does not matter.) > > > > I did not check my editorial comments. > > > > Thanks! > > > > Ben. > > > >> On Jun 25, 2018, at 6:30 PM, Eric Rescorla wrote: > >> > >> Ben, > >> > >> Does the following new text address your concern: > >> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=3Dhtml= /a > > >> scii&url=3Dhttps://raw.githubusercontent.com/TokenBinding/Internet-Dra= ft > > >> s/master/draft-ietf-tokbind-https-18.xml > >> > >> > >> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz 40google..com@dmarc.ietf.org> wrote: > >> Hi Ben, > >> > >> thanks for the feedback. Most of it is addressed in the new draft ( > https://tools.ietf.org/html/draft-ietf-tokbind-https-16 > ). > See below (inline) for details. > >> > >> On Wed, May 9, 2018 at 1:38 PM Ben Campbell wrote: > >> Ben Campbell has entered the following ballot position for > >> draft-ietf-tokbind-https-14: 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: > >> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ > > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> I plan to ballot "YES", but I want to clear up once concern first: > >> > >> After reading section 6 several times, I don't know what it means. I > >> think it's [...] > >> > >> Addressed in new draft. > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Substantive Comments: > >> > >> =C2=A71.1: Please consider using the boilerplate from 8174 across the > >> cluster. Both this and the protocol draft have lower case keyword > instances. > >> > >> Addressed in new draft. > >> > >> > >> =C2=A78.2: > >> - Does it really make sense to wait for a user to request the keys be > expired? > >> I suspect the average user does this about never. Did the working > >> group discuss possibly making the keys default to expiring after some > period of time? > >> > >> Yes, we did discuss it. This was chosen consciously to be in sync with > cookies and their expirations / manual user-initiated purges. > >> > >> - Why > >> is the SHOULD in paragraph 2 not a MUST? > >> > >> Addressed in new draft. > >> > >> > >> Editorial Comments: > >> > >> =C2=A72: > >> - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in > >> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The open > parenthesis before "in" > >> seems misplaced. Also, as written the comma after "style" creates a > >> comma splice. (Note that this pattern occurs elsewhere in the > >> document.) > >> > >> - Paragraph 3: The paragraph is a single hard-to-parse sentence. > >> Please consider breaking into simpler sentences. > >> > >> Addressed in new draft. > >> > >> > >> - example: Am I correct to assume the backslashes are just for print > >> purposes and are not in the actual message? If so, please mention that= . > >> > >> Addressed in new draft. > >> > >> > >> =C2=A7 2.1: > >> - first paragraph, "Within the latter context...": There was no former > context. > >> I suggest "Within that context..." > >> > >> Addressed in new draft. > >> > >> - 2nd paragraph: The first sentence is hard to parse. I suggest > >> breaking it into separate paragraphs, or restructure without the > >> center-imbedding. > >> > >> Addressed in new draft. > >> > >> - 2nd to last paragraph: Does "SHOULD generally" > >> mean the same as just "SHOULD"? > >> > >> Addressed in new draft. > >> > >> > >> =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to another > server..." > >> > >> Addressed in new draft. > >> > >> > >> =C2=A75.2, > >> - last bullet: " (between client and Token Consumer)" seems more than > >> parenthetical. Please consider removing the parentheses. > >> > >> Addressed in new draft. > >> > >> - paragraph after last > >> bullet: The parenthetical phrase starting with "(proving > >> possession...) is quite long and makes the sentence hard to parse. > >> Given that the concept is covered in the immediately preceding > paragraph, can it be removed? > >> > >> Addressed in new draft. > >> > >> > >> =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or res= tate > >> requirements > >> in) the protocol and negotiation drafts. Can they be included by > >> reference instead, or at least attributed? > >> > >> Addressed in new draft. > >> > >> > >> =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77.1. > >> > >> Addressed in new draft. > >> > >> > >> =C2=A78.3: Unneeded comma in first sentence. > >> > >> Addressed in new draft. > >> > >> Thanks again for the thoughtful comments! > >> > >> Dirk. > >> > >> _______________________________________________ > >> Unbearable mailing list > >> Unbearable@ietf.org > >> https://www.ietf.org/mailman/listinfo/unbearable > > >> > >> > > > > --0000000000003b2f85056f922497 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Should be, I need to do a double check to make sure o= ther comments were dealt with, but assuming so, then yes. Should be able to= do this tomorrow

-Ekr


On Tue, Jun 26= , 2018 at 2:19 PM, Andrei Popov <Andrei.Popov@microsoft.com&g= t; wrote:

Done: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/.=

=C2=A0

From: John Bradley <ve7jtb@ve7jtb.com>
Sent: Tuesday, June 26, 2018 2:14 PM
To: Ben Campbell <ben@nostrum.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Eric Rescorla <ekr@rtfm.com>; Dirk Ba= lfanz <balfanz=3D40google.com@dmarc.ietf.org>; draft-ietf-tokbind-https@= ietf.org; Tokbind WG <unbearable@ietf.org>; IESG <iesg@ietf.org>; tokbind-chairs@ietf.org

=

Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-t= okbind-https-14: (with DISCUSS and COMMENT)

=C2=A0

PS I suppose we need DIRK OR Andre to push a version= with the changes.

=C2=A0

John B.=C2=A0<= u>

On Tue, Jun 26, 2018, 5:12 PM John Bradley <ve7jtb@ve7jtb.com>= wrote:

Thanks Ben.

=C2=A0

EKR once this Discuss is cleared are we good to move= on to the final embrace of the RFC editor?

=C2=A0

Regards=C2=A0

John B.=C2=A0=C2=A0

=C2=A0

On Tue, Jun 26, 2018, 2:58 PM Ben Campbell <ben@nostrum.com> wro= te:



> On Jun 26, 2018, at 1:54 PM, Andrei Popov <Andrei.Popov@microsoft.com> = wrote:
>
> Hi Ben,
>
> Thanks for the review.
>
>> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same a= s those from paragraph 2?
>
> Yes, the same throughout paragraphs 1, 2 and 3.
>
>> It seems like paragraph 2 is talking more about local APIs (at lea= st, I see that was mentioned in the text in version 17 but not in 18), but = paragraph 3 uses an example of a signal from a server. (I can accept that t= he difference in control may be weak enough for web applications that the distinction does not matter.)
>
> The APIs provided by the TB implementation and called by the applicati= on are local APIs.
> The application needs to make a decision whether to request that the T= B implementation include a Referred binding in the TB message or not.
> In the example, the server provides a signal to the application using = the Include-Referred-Token-Binding-ID HTTP response header.
> The signal could be different, or an application may have out-of-band = ways to determine this (e.g. a local database of RP->IDP associations).<= br>
I just re-read the 3rd paragraph, and I think I missed the =E2=80=9Cthen=E2= =80=9D in =E2=80=9Cwhich then signals=E2=80=9D on the first reading. It=E2= =80=99s fine as is.

Thanks!

Ben.

>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: Ben Campbell <ben@nostrum.com>
> Sent: Tuesday, June 26, 2018 11:41 AM
> To: Eric Rescorla <ekr@rtfm.com>
> Cc: Dirk Balfanz <balfanz=3D40google.com@dmarc.ietf.org>; draf= t-ietf-tokbind-https@ietf.org; Tokbind WG <unbearable@ietf.org>; The IESG = <iesg@ietf.org>= ;; John Bradley <ve= 7jtb@ve7jtb.com>; tokbind-chairs= @ietf.org
> Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tok= bind-https-14: (with DISCUSS and COMMENT)
>
> Hi, thanks for the pointer.
>
> The text in version 18 is sufficient to clear my discuss. I have one r= emaining (or maybe new) non-blocking question for section 6:
>
> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as th= ose from paragraph 2? It seems like paragraph 2 is talking more about local= APIs (at least, I see that was mentioned in the text in version 17 but not= in 18), but paragraph 3 uses an example of a signal from a server. (I can accept that the difference in control may be weak en= ough for web applications that the distinction does not matter.)
>
> I did not check my editorial comments.
>
> Thanks!
>
> Ben.
>
>> On Jun 25, 2018, at 6:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Ben,
>>
>> Does the following new text address your concern:
>> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat= =3Dhtml/a
>> scii&url=3Dhttps://raw.githubusercontent.com/To= kenBinding/Internet-Draft
>> s/master/draft-ietf-tokbind-https-18.xml
>>
>>
>> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=3D40google..com@dm= arc.ietf.org> wrote:
>> Hi Ben,
>>
>> thanks for the feedback. Most of it is addressed in the new draft = (https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below (inline) for details.
>>
>> On Wed, May 9, 2018 at 1:38 PM Ben Campbell <ben@nostrum.com> wrote:
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-tokbind-https-14: 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= :
>> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/
>>
>>
>>
>> ------------------------------------------------------------<= wbr>----------
>> DISCUSS:
>> ------------------------------------------------------------<= wbr>----------
>>
>> I plan to ballot "YES", but I want to clear up once conc= ern first:
>>
>> After reading section 6 several times, I don't know what it me= ans. I
>> think it's [...]
>>
>> Addressed in new draft.
>>
>>
>> ------------------------------------------------------------<= wbr>----------
>> COMMENT:
>> ------------------------------------------------------------<= wbr>----------
>>
>> Substantive Comments:
>>
>> =C2=A71.1: Please consider using the boilerplate from 8174 across = the
>> cluster. Both this and the protocol draft have lower case keyword = instances.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A78.2:
>> - Does it really make sense to wait for a user to request the keys= be expired?
>> I suspect the average user does this about never. Did the working<= br> >> group discuss possibly making the keys default to expiring after s= ome period of time?
>>
>> Yes, we did discuss it. This was chosen consciously to be in sync = with cookies and their expirations / manual user-initiated purges.
>>
>> - Why
>> is the SHOULD in paragraph 2 not a MUST?
>>
>> Addressed in new draft.
>>
>>
>> Editorial Comments:
>>
>> =C2=A72:
>> - Paragraph 1: "The ABNF of the Sec-Token-Binding header fiel= d is (in
>> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The ope= n parenthesis before "in"
>> seems misplaced. Also, as written the comma after "style"= ; creates a
>> comma splice. (Note that this pattern occurs elsewhere in the
>> document.)
>>
>> - Paragraph 3: The paragraph is a single hard-to-parse sentence. >> Please consider breaking into simpler sentences.
>>
>> Addressed in new draft.
>>
>>
>> - example: Am I correct to assume the backslashes are just for pri= nt
>> purposes and are not in the actual message? If so, please mention = that.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A7 2.1:
>> - first paragraph, "Within the latter context...": There= was no former context.
>> I suggest "Within that context..."
>>
>> Addressed in new draft.
>>
>> - 2nd paragraph: The first sentence is hard to parse. I suggest >> breaking it into separate paragraphs, or restructure without the >> center-imbedding.
>>
>> Addressed in new draft.
>>
>> - 2nd to last paragraph: Does "SHOULD generally"
>> mean the same as just "SHOULD"?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to a= nother server..."
>>
>> Addressed in new draft.
>>
>>
>> =C2=A75.2,
>> - last bullet: " (between client and Token Consumer)" se= ems more than
>> parenthetical. Please consider removing the parentheses.
>>
>> Addressed in new draft.
>>
>> - paragraph after last
>> bullet: The parenthetical phrase starting with "(proving
>> possession...) is quite long and makes the sentence hard to parse.=
>> Given that the concept is covered in the immediately preceding par= agraph, can it be removed?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or= restate
>> requirements
>> in) the protocol and negotiation drafts. Can they be included by >> reference instead, or at least attributed?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77= .1.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A78.3: Unneeded comma in first sentence.
>>
>> Addressed in new draft.
>>
>> Thanks again for the thoughtful comments!
>>
>> Dirk.
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearabl= e@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>>
>>
>


--0000000000003b2f85056f922497--