From nobody Fri Aug  7 08:59:58 2015
Return-Path: <schokhani@cygnacom.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469E71ACEA1 for <unbearable@ietfa.amsl.com>; Fri,  7 Aug 2015 08:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 GHSIUuWs8RKb for <unbearable@ietfa.amsl.com>; Fri,  7 Aug 2015 08:59:56 -0700 (PDT)
Received: from ipesa2.cygnacom.com (ipesa2.cygnacom.com [65.242.48.201]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFF71AD05D for <unbearable@ietf.org>; Fri,  7 Aug 2015 08:59:50 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2CfCwBV1cRV/9kyPApbgk6BIUMstwmGFwGKBA8BAQEBAQEBfwuEKi0hPQEMCWoBJgEEGxMCBIgSzlOVCwWVCJVRhhuKZYQjgjeBBAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,630,1432612800"; d="scan'208,217";a="179191"
Received: from unknown (HELO svaexch2.cygnacom.com) ([10.60.50.217]) by ipesa2.cygnacom.com with ESMTP; 07 Aug 2015 11:59:49 -0400
Received: from svaexch2.cygnacom.com (10.60.50.217) by svaexch2.cygnacom.com (10.60.50.217) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 7 Aug 2015 11:59:48 -0400
Received: from svaexch2.cygnacom.com ([fe80::8101:6c23:ea7d:8a2b]) by svaexch2.cygnacom.com ([fe80::8101:6c23:ea7d:8a2b%12]) with mapi id 15.00.1076.000; Fri, 7 Aug 2015 11:59:48 -0400
From: Santosh Chokhani <schokhani@cygnacom.com>
To: "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: Unsubscribe
Thread-Index: AdDRKHLru67IBV7yQ7qWC9JK7J3TqA==
Date: Fri, 7 Aug 2015 15:59:47 +0000
Message-ID: <2540c29b1caa460dab882fac5d15b0ec@svaexch2.cygnacom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.60.117.7]
Content-Type: multipart/alternative; boundary="_000_2540c29b1caa460dab882fac5d15b0ecsvaexch2cygnacomcom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/7EDxUJtl5VqT2yaL4gxjK1-KVAw>
Subject: [Unbearable] Unsubscribe
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2015 15:59:57 -0000

--_000_2540c29b1caa460dab882fac5d15b0ecsvaexch2cygnacomcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



Santosh Chokhani
CygnaCom Solutions, Inc.


--_000_2540c29b1caa460dab882fac5d15b0ecsvaexch2cygnacomcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Santosh Chokhani<o:p></o:p></p>
<p class=3D"MsoNormal">CygnaCom Solutions, Inc.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_2540c29b1caa460dab882fac5d15b0ecsvaexch2cygnacomcom_--


From nobody Tue Aug 25 06:54:12 2015
Return-Path: <waywardgeek@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6D41B2D74 for <unbearable@ietfa.amsl.com>; Tue, 25 Aug 2015 06:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.511
X-Spam-Level: 
X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 CT1r0QvLGR_K for <unbearable@ietfa.amsl.com>; Tue, 25 Aug 2015 06:54:10 -0700 (PDT)
Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 092F11A6F3A for <unbearable@ietf.org>; Tue, 25 Aug 2015 06:54:09 -0700 (PDT)
Received: by qgeb6 with SMTP id b6so106467732qge.3 for <unbearable@ietf.org>; Tue, 25 Aug 2015 06:54:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4CsnVQBdFQcf+xlnMD/KlCNUV//IOlpbdKyJZYDutS8=; b=R8J/Q4Dv38yap3gEbiKvP3dfRgov4rx11EfWKkLG+3iuYlmKWcXLxesImRwmUHIBLz 1GyV9BlqzR6hgfNL/+f5Q3Xws9H1zfLCfj70FJRQCQlZzTVStm32VtGt3lXZi3T/7YgB W1JGdCyAQmvJ1AVeytBFphjmc8uxPyd4sF1fJBrTMiveO3jIa1zGOS/4qeK9T/EGugFs dGIzhcnRy5iQ5uyEcL9Bllr0rdn1gDx2hfZW6yrFR9BVoC3B2Kfu7zQ0KjS5szu4Ypc5 XusG8OIscxOv7w8dPqzBjvu3e/F4CS+s3tFgpZGNj23oWQOaT7nuZA0VvEhIp3P2dbPs fc7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=4CsnVQBdFQcf+xlnMD/KlCNUV//IOlpbdKyJZYDutS8=; b=MhDs6JIZVXFGrQ7tuI00yLvXr5kAf9sgCjQQH3EmCY0+xmzw5KPvhQIChg+dayB4EQ us78fjxGTG/XVtM5iAA0S3UrKLcHOE2I1HrZ8Prk9vU9xiZAMVQqNV/k7F+bmIgnoIO/ VDNnAB/KmNavfGrwK+aZVlWWq9gp7o01dtxGrmsUJQMet3FCyEuVWW0UWnJCGFb4VDET YmRq7Ifo7Ki88Lbdf6X4d+nQQiBXq/czL1qkDVhcUfrvML4t57421v1iNy8T8tLWzWiP A83CTXtqZvq2bZY1B5Q7Tz0/YbmX8nEln7iU+j2+pqYM7ZAxguSIbUbZvmmnE3IIXcfH ztVQ==
X-Gm-Message-State: ALoCoQlgQ9scHy9SFAhGrQMruz7o6+FLhizzy/0iOEmES8Rk48M+m19ihdoWFWFyFNqkj1Z6WG/S
MIME-Version: 1.0
X-Received: by 10.140.237.72 with SMTP id i69mr69670025qhc.59.1440510849006; Tue, 25 Aug 2015 06:54:09 -0700 (PDT)
Received: by 10.55.84.65 with HTTP; Tue, 25 Aug 2015 06:54:08 -0700 (PDT)
Date: Tue, 25 Aug 2015 06:54:08 -0700
Message-ID: <CAH9QtQHTF6vppyZeGsqr4duAcDuENwcdfzYudNc0nM9u68JJhw@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: unbearable@ietf.org
Content-Type: multipart/alternative; boundary=001a1135d69273720b051e231117
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/aExV1K11TwA3DHIi4k0BpnYFMk0>
Subject: [Unbearable] Should we only send Token Binding Message when sending cookies?
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2015 13:54:11 -0000

--001a1135d69273720b051e231117
Content-Type: text/plain; charset=UTF-8

Sorry for having missed the discussions so far.  This has probably already
been discussed to death...

I am worried there will be bugs, such as sending a Token Binding Message
header when cookies have been disabled by the user.  I've just started
reading about cookie policy, and so far, it seems insanely complex.  Some
browsers might block third party cookies, or cookies to particular third
party domains that are advertisers known to track users.  Should we send
our Token Binding ID in this case?

A simple way to insure we are not leaking user information might be to
check that the Token Binding Message is only sent if the cookie header is
present.  If the browser is blocking cookies for some reason, I suspect we
should also block Token Binding Messages.  Are there good use-cases for the
Token Binding Message when there is no cookie present?

As for HTTP2 compression, this would only result in increased traffic when
the cookie policy changes.  In general, if we do 50 requests to a web site,
we send the same cookies 50 times.  In that case, we'd also send the Token
Binding Message header 50 times.  Is it rare to change to sending cookies,
and then not, to the same domain.

I read that Yahoo and Google recommend having separate static content
domains so that when loading static content, the browser does not bother
sending any cookies.  This makes page loading faster.  In this case, we
could also slightly speed things up over HTTP by not sending any Token
Binding Message header.

What do you think?

Bill

--001a1135d69273720b051e231117
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Sorry for having missed the discussions so far.=C2=A0=
 This has probably already been discussed to death...</div><div><br></div>I=
 am worried there will be bugs, such as sending a Token Binding Message hea=
der when cookies have been disabled by the user.=C2=A0 I&#39;ve just starte=
d reading about cookie policy, and so far, it seems insanely complex.=C2=A0=
 Some browsers might block third party cookies, or cookies to particular th=
ird party domains that are advertisers known to track users.=C2=A0 Should w=
e send our Token Binding ID in this case?<div><br></div><div>A simple way t=
o insure we are not leaking user information might be to check that the Tok=
en Binding Message is only sent if the cookie header is present.=C2=A0 If t=
he browser is blocking cookies for some reason, I suspect we should also bl=
ock Token Binding Messages.=C2=A0 Are there good use-cases for the Token Bi=
nding Message when there is no cookie present?</div><div><br></div><div>As =
for HTTP2 compression, this would only result in increased traffic when the=
 cookie policy changes.=C2=A0 In general, if we do 50 requests to a web sit=
e, we send the same cookies 50 times.=C2=A0 In that case, we&#39;d also sen=
d the Token Binding Message header 50 times.=C2=A0 Is it rare to change to =
sending cookies, and then not, to the same domain.</div><div><br></div><div=
>I read that Yahoo and Google recommend having separate static content doma=
ins so that when loading static content, the browser does not bother sendin=
g any cookies.=C2=A0 This makes page loading faster.=C2=A0 In this case, we=
 could also slightly speed things up over HTTP by not sending any Token Bin=
ding Message header.</div><div><br></div><div>What do you think?</div><div>=
<br></div><div>Bill</div></div>

--001a1135d69273720b051e231117--


From nobody Tue Aug 25 08:20:51 2015
Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0321B2FF7 for <unbearable@ietfa.amsl.com>; Tue, 25 Aug 2015 08:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 ANIOM-Opm19Z for <unbearable@ietfa.amsl.com>; Tue, 25 Aug 2015 08:20:48 -0700 (PDT)
Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) (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 B93291B2FDF for <unbearable@ietf.org>; Tue, 25 Aug 2015 08:20:48 -0700 (PDT)
Received: by qkbm65 with SMTP id m65so101904150qkb.2 for <unbearable@ietf.org>; Tue, 25 Aug 2015 08:20:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=sSBHmLl+VECuryj2EUomhzB3YO9sUdBuLCNDUVVX5EI=; b=OjO/8Yo2Awkfww6jBBaOGlQoGtDhTDRxOyvhGuRdHfy0K/pu4PlM/BC4yphDGrT8k0 gA9iE13ML4TszvSxRpQ68C8gKGNHlHKfXRQsgGbLhmVb/NDIzbU0+uuzWcXFBafCFxDR ALnEXkDwbQolSFYa2EZSVgJtJ1wmT2XHD9dZsHXR2+u/3pMF/Hq4JJYhdLD2QM4ErCFF 7iIF+aDBb9YakoY42l+rtssoIwBHvcziVGs3WvUMIB2ESuB1jz0LYXsE2y+A47jx2Tsi UdkUnTjZ4Jtzub3pEZsonyVXsgiTR08q6GJ6xj9MbzZezOaZvhzknicAkJcPzRqG2HgH fjWg==
X-Gm-Message-State: ALoCoQlm02IbKBu9Ytf4lw20ULTD7olCKdQAcAPBs4tDISqcZ1JqUU6tGqzxcHXWYzFbaks9vkON
X-Received: by 10.55.198.9 with SMTP id b9mr33583666qkj.97.1440516047815; Tue, 25 Aug 2015 08:20:47 -0700 (PDT)
Received: from [192.168.1.216] (186-106-169-204.baf.movistar.cl. [186.106.169.204]) by smtp.gmail.com with ESMTPSA id k32sm11899190qkh.39.2015.08.25.08.20.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Aug 2015 08:20:47 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_DC46826E-297F-438A-9A3C-ED16D88F4AED"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CAH9QtQHTF6vppyZeGsqr4duAcDuENwcdfzYudNc0nM9u68JJhw@mail.gmail.com>
Date: Tue, 25 Aug 2015 12:20:37 -0300
Message-Id: <6F09B2F6-C6C3-4F78-944D-D4F341B9B746@ve7jtb.com>
References: <CAH9QtQHTF6vppyZeGsqr4duAcDuENwcdfzYudNc0nM9u68JJhw@mail.gmail.com>
To: Bill Cox <waywardgeek@google.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/tRxIXnvtqh5rhUlWqPrx_XKnfaY>
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] Should we only send Token Binding Message when sending cookies?
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2015 15:20:50 -0000

--Apple-Mail=_DC46826E-297F-438A-9A3C-ED16D88F4AED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Token Binding may also be used to protect redirect based messages like =
OpenID Connect and SAML.  So while I would expect both a IdP and SP to =
be setting cookies under normal circumstances, not every token protected =
by token binding is a cookie.

Interesting observations though.

John B.


> On Aug 25, 2015, at 10:54 AM, Bill Cox <waywardgeek@google.com> wrote:
>=20
> Sorry for having missed the discussions so far.  This has probably =
already been discussed to death...
>=20
> I am worried there will be bugs, such as sending a Token Binding =
Message header when cookies have been disabled by the user.  I've just =
started reading about cookie policy, and so far, it seems insanely =
complex.  Some browsers might block third party cookies, or cookies to =
particular third party domains that are advertisers known to track =
users.  Should we send our Token Binding ID in this case?
>=20
> A simple way to insure we are not leaking user information might be to =
check that the Token Binding Message is only sent if the cookie header =
is present.  If the browser is blocking cookies for some reason, I =
suspect we should also block Token Binding Messages.  Are there good =
use-cases for the Token Binding Message when there is no cookie present?
>=20
> As for HTTP2 compression, this would only result in increased traffic =
when the cookie policy changes.  In general, if we do 50 requests to a =
web site, we send the same cookies 50 times.  In that case, we'd also =
send the Token Binding Message header 50 times.  Is it rare to change to =
sending cookies, and then not, to the same domain.
>=20
> I read that Yahoo and Google recommend having separate static content =
domains so that when loading static content, the browser does not bother =
sending any cookies.  This makes page loading faster.  In this case, we =
could also slightly speed things up over HTTP by not sending any Token =
Binding Message header.
>=20
> What do you think?
>=20
> Bill
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable


--Apple-Mail=_DC46826E-297F-438A-9A3C-ED16D88F4AED
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTA4MjUxNTIwMzdaMCMGCSqGSIb3DQEJBDEWBBT+hmRsNOV8Af5kyQvTrqnK
RjQ9CzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBFI2YGw8PY8qLyb2X1cGPAyQom9DW8Z+KSqGWJg4s2tCRi3jTwnr2+
G/Hd9yedAWYFAlRM5Id3M9rinR57oJSVlBhL0zN6Jz0iyuMYRXqTBc7vCnCkmMSL0rIasJxdQp6w
ZnlzBysouirzQgyV3tHShkEzMxnUVf189OfOn7WeXC2gm6zv+zCJEy74sl1yggnbp8n1TZ/y/+Ob
20GwnAzkiCAlKjzBhqp5Y4kKiJi8xyMVAvhHHltI+mN9t5xxnJWUSP2hypJCkdW0KYKOSPpWQIGN
WksooGurrQWo0diz3psJRRDpe+u2BOiD4MKkpjuBHgSH+MT3lphY4PeMvhlOAAAAAAAA
--Apple-Mail=_DC46826E-297F-438A-9A3C-ED16D88F4AED--


From nobody Tue Aug 25 09:30:28 2015
Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463191A079D for <unbearable@ietfa.amsl.com>; Tue, 25 Aug 2015 09:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 9UoNqEJXIxUf for <unbearable@ietfa.amsl.com>; Tue, 25 Aug 2015 09:30:22 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534CF1A0385 for <unbearable@ietf.org>; Tue, 25 Aug 2015 09:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jAzdemHp2awCVE4AQScAnneGkhnf2timBvPEoEbL9bA=; b=b/S2HaiWCokT5tD4px3FGVOs2SD6WNBr21uiiqrJW36U3nR5kakmmDBt8wujYQmShllzxiiGdx6i+X3aaAwLt51GskEUyYayWjL63M+Rdvyq7PJUhhJlcR6cPuKK4pD9CCDRr5MfajNrceeHpJGCZ1PL2Q4W6rXOYt+VloLoMuU=
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.231.21; Tue, 25 Aug 2015 16:30:04 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0231.024; Tue, 25 Aug 2015 16:30:04 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: John Bradley <ve7jtb@ve7jtb.com>, Bill Cox <waywardgeek@google.com>
Thread-Topic: [Unbearable] Should we only send Token Binding Message when sending cookies?
Thread-Index: AQHQ30milh09kL7jF029bU5i8WKfq54c5ldw
Date: Tue, 25 Aug 2015 16:30:04 +0000
Message-ID: <BLUPR03MB139627BEAC5982AB42E971248C610@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CAH9QtQHTF6vppyZeGsqr4duAcDuENwcdfzYudNc0nM9u68JJhw@mail.gmail.com> <6F09B2F6-C6C3-4F78-944D-D4F341B9B746@ve7jtb.com>
In-Reply-To: <6F09B2F6-C6C3-4F78-944D-D4F341B9B746@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8:4::1d2]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:gwfukMvSmLsI40YMEEn1rAychkp0ejoMi3jNJ18Dz8Ym5CaENaH/xh4xe1n98g8/E4amk2NwhdqWOYngqmAlDv3HOffs87OpJQSu9FiKpZ6jDIAMXW0Qxt9Ejzw6/2mnaIPYhPt26fWdM9CneF7AIw==; 24:u0DK11XQFZwOEBbDrWuhyq3YEjKkIZ44SWQvddw+WjTShDDmfZsZjtjNal/TopK7GKsAIbiUbXHTQJDkz95DOUQ+5RMVsKCiZowQNe35l/o=; 20:O6deHd4ScNe3xfPVEJ6fKXkLk0yJyCeTi1AZltiZEb0ct4ixcgrOgTTscrnxlqOOj66DLj3VXSSlPJPLKdYcmw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393;
x-microsoft-antispam-prvs: <BLUPR03MB1393170BA6D603E533A8F00E8C610@BLUPR03MB1393.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; 
x-forefront-prvs: 06793E740F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(76104003)(377454003)(189002)(199003)(102836002)(19580395003)(122556002)(5001770100001)(40100003)(50986999)(106356001)(99286002)(76176999)(189998001)(5001830100001)(5004730100002)(4001540100001)(68736005)(97736004)(54356999)(106116001)(5001860100001)(62966003)(77096005)(81156007)(86612001)(2900100001)(76576001)(87936001)(77156002)(5002640100001)(5003600100002)(5001920100001)(15975445007)(2656002)(19580405001)(105586002)(33656002)(64706001)(86362001)(101416001)(5005710100001)(46102003)(2950100001)(92566002)(5007970100001)(5001960100002)(10290500002)(10090500001)(8990500004)(10400500002)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2015 16:30:04.1963 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/Gea3z6tRyZowJkIIHTjlQvTgxEw>
Cc: "unbearable@ietf.org" <unbearable@ietf.org>
Subject: Re: [Unbearable] Should we only send Token Binding Message when sending cookies?
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2015 16:30:24 -0000

Token Binding messages are encapsulated in the application protocol and han=
dled at the application protocol layer, therefore it seems feasible to only=
 send them when needed.

There has been a separate discussion about removing the requirement that th=
e Provided binding is sent in the very first application_data payload after=
 TB has been negotiated.

Perhaps we can combine both ideas and say that the application MUST send To=
ken Binding messages whenever it is requesting or supplying tokens?

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of John Bra=
dley
Sent: Tuesday, August 25, 2015 8:21 AM
To: Bill Cox <waywardgeek@google.com>
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] Should we only send Token Binding Message when se=
nding cookies?

Token Binding may also be used to protect redirect based messages like Open=
ID Connect and SAML.  So while I would expect both a IdP and SP to be setti=
ng cookies under normal circumstances, not every token protected by token b=
inding is a cookie.

Interesting observations though.

John B.


> On Aug 25, 2015, at 10:54 AM, Bill Cox <waywardgeek@google.com> wrote:
>=20
> Sorry for having missed the discussions so far.  This has probably alread=
y been discussed to death...
>=20
> I am worried there will be bugs, such as sending a Token Binding Message =
header when cookies have been disabled by the user.  I've just started read=
ing about cookie policy, and so far, it seems insanely complex.  Some brows=
ers might block third party cookies, or cookies to particular third party d=
omains that are advertisers known to track users.  Should we send our Token=
 Binding ID in this case?
>=20
> A simple way to insure we are not leaking user information might be to ch=
eck that the Token Binding Message is only sent if the cookie header is pre=
sent.  If the browser is blocking cookies for some reason, I suspect we sho=
uld also block Token Binding Messages.  Are there good use-cases for the To=
ken Binding Message when there is no cookie present?
>=20
> As for HTTP2 compression, this would only result in increased traffic whe=
n the cookie policy changes.  In general, if we do 50 requests to a web sit=
e, we send the same cookies 50 times.  In that case, we'd also send the Tok=
en Binding Message header 50 times.  Is it rare to change to sending cookie=
s, and then not, to the same domain.
>=20
> I read that Yahoo and Google recommend having separate static content dom=
ains so that when loading static content, the browser does not bother sendi=
ng any cookies.  This makes page loading faster.  In this case, we could al=
so slightly speed things up over HTTP by not sending any Token Binding Mess=
age header.
>=20
> What do you think?
>=20
> Bill
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable


From nobody Tue Aug 25 10:03:32 2015
Return-Path: <waywardgeek@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA141A21AA for <unbearable@ietfa.amsl.com>; Tue, 25 Aug 2015 10:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 GVEjRhLPsYuM for <unbearable@ietfa.amsl.com>; Tue, 25 Aug 2015 10:03:29 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 A29401A0181 for <unbearable@ietf.org>; Tue, 25 Aug 2015 10:03:29 -0700 (PDT)
Received: by qkfh127 with SMTP id h127so104189111qkf.1 for <unbearable@ietf.org>; Tue, 25 Aug 2015 10:03:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HoPEraDI6zbticW4YKLDNYXi9y4Gli0NrioETAz8OCE=; b=WDy94vdayS8zZyhcaSgOeOYIafWEWvXMZkOwHBptlHSV87FWiO+AvNZjWEiAeF+weZ T9i2nzepHXvSwRAqZybpWVpWEgODNIjZ+qbYRg4jfW1Ku8NpSpfVSQK85P06RpUIM3Iy WPOF8lVL3PQKa75vvurlnT3gQXR5ye1i9F0tQJ2ZHjMP6Gf/2qkb5UVMSPA4CbyiiGWH DYar+p84xLnOKc+AUGyTRio3nMHPKMvlWyLDLZJkFxUcFoxZDEgwFnrWNk+mE/tSYWFz dXieA61psjbmwL6utnz0p+FjoPysvQHMVj31EvnkNbCNd3NSb52XDha2hrSRja7zX9cI xi3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HoPEraDI6zbticW4YKLDNYXi9y4Gli0NrioETAz8OCE=; b=Xpr6vDdfMVoMgfdraAaT+1LFFX+xPgOCH+sEka9HU/f8RWN2XKz2flerqB2pm4akqO EsV5c7+C3b98Rulfw0dQMEBVlEpo0ZeGF9YJOTTmfU2tqh7dPLcicWqWn69342+1YItx GpmH757dcRDoqWBSwtHfnL5FwXsWhAlPYFSldnj0twTmZc+AzzUvAcANXLbyDxqcmLA4 wbgkOeOI6WcZq0m8CHq8kZJ7tZigZ3CkTNSL7Pw+G95wT+M36hb727EzoDcgpQ0Dw4rH TZtYLANO0BYGrvbx49DH9k65UYzFnLk1tKgECQphVXS6x9yE8kC2YTDsYMueCRVpS/vA 0yhw==
X-Gm-Message-State: ALoCoQnxN8UDJpZ97a+fbETG0kDdhx271j6OvPwTjRAMy8Tcz0kqyBtZb5UTAgi7u+P/oQM2VjQx
MIME-Version: 1.0
X-Received: by 10.55.42.163 with SMTP id q35mr43100666qkq.107.1440522208756; Tue, 25 Aug 2015 10:03:28 -0700 (PDT)
Received: by 10.55.84.65 with HTTP; Tue, 25 Aug 2015 10:03:28 -0700 (PDT)
In-Reply-To: <BLUPR03MB139627BEAC5982AB42E971248C610@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CAH9QtQHTF6vppyZeGsqr4duAcDuENwcdfzYudNc0nM9u68JJhw@mail.gmail.com> <6F09B2F6-C6C3-4F78-944D-D4F341B9B746@ve7jtb.com> <BLUPR03MB139627BEAC5982AB42E971248C610@BLUPR03MB1396.namprd03.prod.outlook.com>
Date: Tue, 25 Aug 2015 10:03:28 -0700
Message-ID: <CAH9QtQGO3fNYimZHye=LHZt2zbA+_un6FaYGjoBg3Jui51Purw@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary=001a11493ef48bf400051e25b640
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/eBmC4LAYrzcurJprWhdXVNCUNPo>
Cc: John Bradley <ve7jtb@ve7jtb.com>, "unbearable@ietf.org" <unbearable@ietf.org>
Subject: Re: [Unbearable] Should we only send Token Binding Message when sending cookies?
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2015 17:03:30 -0000

--001a11493ef48bf400051e25b640
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 25, 2015 at 9:30 AM, Andrei Popov <Andrei.Popov@microsoft.com>
wrote:

> Token Binding messages are encapsulated in the application protocol and
> handled at the application protocol layer, therefore it seems feasible to
> only send them when needed.
>
> There has been a separate discussion about removing the requirement that
> the Provided binding is sent in the very first application_data payload
> after TB has been negotiated.
>
> Perhaps we can combine both ideas and say that the application MUST send
> Token Binding messages whenever it is requesting or supplying tokens?
>
> Cheers,
>
> Andrei
>
> That sounds good to me.

BIll

--001a11493ef48bf400051e25b640
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 25, 2015 at 9:30 AM, Andrei Popov <span dir=3D"ltr">&lt;<a href=3D"=
mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov@microsoft=
.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Token Binding =
messages are encapsulated in the application protocol and handled at the ap=
plication protocol layer, therefore it seems feasible to only send them whe=
n needed.<br>
<br>
There has been a separate discussion about removing the requirement that th=
e Provided binding is sent in the very first application_data payload after=
 TB has been negotiated.<br>
<br>
Perhaps we can combine both ideas and say that the application MUST send To=
ken Binding messages whenever it is requesting or supplying tokens?<br>
<br>
Cheers,<br>
<br>
Andrei<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>T=
hat sounds good to me.</div><div><br></div><div>BIll=C2=A0</div></div></div=
></div>

--001a11493ef48bf400051e25b640--


From nobody Tue Aug 25 13:08:37 2015
Return-Path: <D.Rogers@gmx.net>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816B91A888E for <unbearable@ietfa.amsl.com>; Tue, 25 Aug 2015 13:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.013
X-Spam-Level: 
X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 n5umdZgZgili for <unbearable@ietfa.amsl.com>; Tue, 25 Aug 2015 13:08:34 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C941A87CD for <unbearable@ietf.org>; Tue, 25 Aug 2015 13:08:33 -0700 (PDT)
Received: from [93.214.242.237] by 3capp-gmx-bs10.server.lan (via HTTP); Tue, 25 Aug 2015 22:08:31 +0200
MIME-Version: 1.0
Message-ID: <trinity-78a59400-a3df-4254-8948-b6aef02cfcaf-1440533311603@3capp-gmx-bs10>
From: D.Rogers@gmx.net
To: "Bill Cox" <waywardgeek@google.com>
Content-Type: text/html; charset=UTF-8
Date: Tue, 25 Aug 2015 22:08:31 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <CAH9QtQHTF6vppyZeGsqr4duAcDuENwcdfzYudNc0nM9u68JJhw@mail.gmail.com>
References: <CAH9QtQHTF6vppyZeGsqr4duAcDuENwcdfzYudNc0nM9u68JJhw@mail.gmail.com>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K0:b1FI4NXB8BFCFereWWkusLFShM2inr9OaNm7Fu16sqn sOAY4TKwPPfbzhQH3rUTbUbVdSMqMsS4CYPiOYN12sYAhstyfJ fb8Zkx6NOvEPOnBKXWQos2rWKynoy/cYFdKyll+NvYZizFrKrb 5y94Fsw3njpt2HQNqlW+zpJ1P+gzZUt4kD/XBXn8YVZso4ZHo2 c8u+QzJRcPjTiGTmwk90zDyUcnZsWFJbWAQO9+iFpIBoTbLXs/ 1EmXiSVM452QgRI4TjkPiam9RShjTEQGO50yN1tiVgvFVuBAp9 ljJb4A=
X-UI-Out-Filterresults: notjunk:1;V01:K0:h18IMw+IRWc=:UceTYPuDhjf0sG3D6h3XIk 01PKQVXPZfI9S1NwtKnTW1G7ZmkhmhPE8BYaiPqcCrsY/79xQYUaZSYFsljNYaupAkOZlE7yl JRwJiDtD6Od/D0dHzQy5N0ttwkIEn4zZVveiD2k5RWtnX5IortfkBaFyKNYYc9+QZ6uDYxIP2 aPaepZLiD9agya3JneAwVaa0UDzIlUzVoP1cawwLDlkeIid75tJDPKIUEuzpw/A/jwsUAQ+XD qKMaYbC/hLGTuvv+EW7WXlALAPLweBBt4Qf+MiP24B2MKTm2vZ6eW/xtVTieJAsy1hZpR3OlZ hSsaBKG19lp+XOlndgYuw4jpeeoCtmaZdL36CThWfp/A2plF+e63uVrSNZq8JqFqlS7B6PpAn rvCLnqLo6oHzo1OuMBAjMuRfHaE/QhpzWrrO26XoAD3XUG9DMiuOLvhJIUtVTgEVpmXsEDlPj 0ozbEW6vyA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/HS5NpZLdYr1LNW9kLTvQbuus6_Q>
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] Should we only send Token Binding Message when sending cookies?
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2015 20:08:35 -0000

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi Bill,</div>

<div>&nbsp;</div>

<div>I dont know how to say this, so theres only one way - I have a basic gut aversion to the use of cookies in general&nbsp;in any security enhancing function. All of your concerns only express and&nbsp;enhance that.</div>

<div>&nbsp;</div>

<div>On HTTP compression possibly speeding page loading, thats one of those theoretical novelties, affecting the real world like a drop in the ocean. Most of the pages I visist, particularly this last say 18 months or so, load slowly because of the adverts included, meaning the page cannot be scrolled until a flash finishes loading, a 2% speed up wont be noticed by most users.</div>

<div>&nbsp;</div>

<div>
<div>Dean</div>
</div>

<div>&nbsp;
<div name="quote" style="margin: 10px 5px 5px 10px; padding: 10px 0px 10px 10px; border-left-color: rgb(195, 217, 229); border-left-width: 2px; border-left-style: solid; -ms-word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin: 0px 0px 10px;"><b>Gesendet:</b>&nbsp;Dienstag, 25. August 2015 um 15:54 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Bill Cox&quot; &lt;waywardgeek@google.com&gt;<br/>
<b>An:</b>&nbsp;unbearable@ietf.org<br/>
<b>Betreff:</b>&nbsp;[Unbearable] Should we only send Token Binding Message when sending cookies?</div>

<div name="quoted-content">
<div>
<div>Sorry for having missed the discussions so far.&nbsp; This has probably already been discussed to death...</div>

<div>&nbsp;</div>
I am worried there will be bugs, such as sending a Token Binding Message header when cookies have been disabled by the user.&nbsp; I&#39;ve just started reading about cookie policy, and so far, it seems insanely complex.&nbsp; Some browsers might block third party cookies, or cookies to particular third party domains that are advertisers known to track users.&nbsp; Should we send our Token Binding ID in this case?

<div>&nbsp;</div>

<div>A simple way to insure we are not leaking user information might be to check that the Token Binding Message is only sent if the cookie header is present.&nbsp; If the browser is blocking cookies for some reason, I suspect we should also block Token Binding Messages.&nbsp; Are there good use-cases for the Token Binding Message when there is no cookie present?</div>

<div>&nbsp;</div>

<div>As for HTTP2 compression, this would only result in increased traffic when the cookie policy changes.&nbsp; In general, if we do 50 requests to a web site, we send the same cookies 50 times.&nbsp; In that case, we&#39;d also send the Token Binding Message header 50 times.&nbsp; Is it rare to change to sending cookies, and then not, to the same domain.</div>

<div>&nbsp;</div>

<div>I read that Yahoo and Google recommend having separate static content domains so that when loading static content, the browser does not bother sending any cookies.&nbsp; This makes page loading faster.&nbsp; In this case, we could also slightly speed things up over HTTP by not sending any Token Binding Message header.</div>

<div>&nbsp;</div>

<div>What do you think?</div>

<div>&nbsp;</div>

<div>Bill</div>
</div>
_______________________________________________ Unbearable mailing list Unbearable@ietf.org <a href="https://www.ietf.org/mailman/listinfo/unbearable" target="_blank">https://www.ietf.org/mailman/listinfo/unbearable</a></div>
</div>
</div>
</div></div></body></html>


From nobody Sat Aug 29 12:46:28 2015
Return-Path: <waywardgeek@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD5F1B3EC5 for <unbearable@ietfa.amsl.com>; Sat, 29 Aug 2015 12:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 tG8JaY7klfxo for <unbearable@ietfa.amsl.com>; Sat, 29 Aug 2015 12:46:26 -0700 (PDT)
Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 872101B3E57 for <unbearable@ietf.org>; Sat, 29 Aug 2015 12:46:26 -0700 (PDT)
Received: by qgj62 with SMTP id 62so46659949qgj.2 for <unbearable@ietf.org>; Sat, 29 Aug 2015 12:46:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Viw4JZAAGQVCMrH0ZvZlhqniR6uwFA/bg80aMxIvwgY=; b=KCzHKMJ4SaRWjHPyE+N7Gc6aHxFH5jwIRTB3uupg3pOJnXLtysfxoiHrQPtp0PZTZl MIrwZm/scHksmnS/VZSETrMMJLJxyXa2/8r6QkpL5ui7p9g+XTOaVuR08zTuX5dKo/cI m+DWVdPEQDIFgOy4UtRzte6fA98x9ffMbqhIrvYgCMTc/dVo79Mqz4skjaH/iOdApLpy IuGW06s34MkIqOYhl1XYk7CNFMQ2s7W16eoZL3l3VDxVWfmbXqCtZ9Qoya0eAZm70X/u da+Q6+GjH74+nY+xSlR6nPBmNoQZDH0rVn8NiW85LHcvntP3/dmAjThr0Uw+duW0xWzU WTtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=Viw4JZAAGQVCMrH0ZvZlhqniR6uwFA/bg80aMxIvwgY=; b=ArWPm/oemMzoih6qck3pSAAEZqDioVkAsaaJSlVstkZIaLckAHSAJYHpfMTDhsu9Gw 8z4UDvcNXmuAgcVRiF9WEte8vHTTDwYtuRSzdP8WdA5SutaKr7X66WHVOsDqDmhhp7jA UEf9+5eN03041z5gl9MVuvqHdjp0CWxaYwhk5IyUnfDXJRHjrHneE+GazWL/KhVqpc1g BH7b4nxeQer/zLHkTjG+Ehmk/DyR6bX5zrlBncjbOoO4nDRde2CLMwcfHivznDqrfYbp t94IzZOKlttgRYsr3PGFsiRbN7h3zfPLn7UgAvLrg9KYlinOpzQ2xbo307fBj3IA3IRU dGCw==
X-Gm-Message-State: ALoCoQk3469ltrlVO0CKs48LRw0XnknX5tg45bX8ps9d7O37MlMYH2DOFgl3l09UWkkApIBqTKmR
MIME-Version: 1.0
X-Received: by 10.140.232.20 with SMTP id d20mr27310579qhc.72.1440877585768; Sat, 29 Aug 2015 12:46:25 -0700 (PDT)
Received: by 10.55.84.65 with HTTP; Sat, 29 Aug 2015 12:46:25 -0700 (PDT)
Date: Sat, 29 Aug 2015 12:46:25 -0700
Message-ID: <CAH9QtQH3WMwePdwcpV-XYBVDnWBx=BzY7FxTqCGSoPp0q3vDmQ@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: unbearable@ietf.org
Content-Type: multipart/alternative; boundary=001a1135482caa62f3051e78743b
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/76k8Hf2CfNL4ay4IYvloCuaN44k>
Cc: Nick Harper <nharper@google.com>
Subject: [Unbearable] Token Binding extension has incorrect size for key array
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Aug 2015 19:46:28 -0000

--001a1135482caa62f3051e78743b
Content-Type: text/plain; charset=UTF-8

The spec <https://tools.ietf.org/id/draft-popov-tokbind-negotiation-00.txt>
and used a uint16 for the length of the key type array, but the keys are
8-bit values and are not allowed to repeat.  This is clearly an error in
the spec.  I used a 1-byte length instead.  No point wasting a byte :)

Two other issues in this spec:

1) The server has to ignore this extension if the client broadcasts support
for a newer version than the server knows about.  This will result in Token
Binding being disabled whenever the client supports a newer version than
the server, or alternatively, clients will have to be careful to only
broadcast older well supported versions.  This should probably be a range
of versions rather than just one.  My preference is to simplify the version
number to 1 byte ,and send a 2-byte range.  0 would be the prototype
version, and 1, would be the first official version.  The server would pick
a version from the range sent by the client and send the same version
repeated (so that server and client headers are the same size).  I do not
think we need a 2-byte version for this simple extension.  Every byte
counts :)

2) The server currently has no way to inform the client what it's
preferences are.  Instead, the server has to pick just one.  In the case
where the server prefers ECDSA, but the client already has an RSA key pair,
the server is likely to pick ECDSA, invalidating the client's key pair.
Instead, I send a list of acceptable parameters both ways, in order of
preference, where the server sends a subset of the list received from the
client.  This allows the client to know that the server prefers ECDSA but
is willing to continue support for RSA, and the client can choose to
continue using the new key or not.

Thanks,
Bill

--001a1135482caa62f3051e78743b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><a href=3D"https://tools.ietf.org/id/draft-popov-tokbind-n=
egotiation-00.txt">The spec</a> and used a uint16 for the length of the key=
 type array, but the keys are 8-bit values and are not allowed to repeat.=
=C2=A0 This is clearly an error in the spec.=C2=A0 I used a 1-byte length i=
nstead.=C2=A0 No point wasting a byte :)<div><br></div><div>Two other issue=
s in this spec:</div><div><br></div><div>1) The server has to ignore this e=
xtension if the client broadcasts support for a newer version than the serv=
er knows about.=C2=A0 This will result in Token Binding being disabled when=
ever the client supports a newer version than the server, or alternatively,=
 clients will have to be careful to only broadcast older well supported ver=
sions.=C2=A0 This should probably be a range of versions rather than just o=
ne.=C2=A0 My preference is to simplify the version number to 1 byte ,and se=
nd a 2-byte range. =C2=A00 would be the prototype version, and 1, would be =
the first official version.=C2=A0 The server would pick a version from the =
range sent by the client and send the same version repeated (so that server=
 and client headers are the same size).=C2=A0 I do not think we need a 2-by=
te version for this simple extension.=C2=A0 Every byte counts :)</div><div>=
<br></div><div>2) The server currently has no way to inform the client what=
 it&#39;s preferences are.=C2=A0 Instead, the server has to pick just one.=
=C2=A0 In the case where the server prefers ECDSA, but the client already h=
as an RSA key pair, the server is likely to pick ECDSA, invalidating the cl=
ient&#39;s key pair.=C2=A0 Instead, I send a list of acceptable parameters =
both ways, in order of preference, where the server sends a subset of the l=
ist received from the client.=C2=A0 This allows the client to know that the=
 server prefers ECDSA but is willing to continue support for RSA, and the c=
lient can choose to continue using the new key or not.</div><div><br></div>=
<div>Thanks,</div><div>Bill</div></div>

--001a1135482caa62f3051e78743b--


From nobody Mon Aug 31 12:32:32 2015
Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED9A1B29BB for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 12:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 R5omXZI26arm for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 12:32:28 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0141A9251 for <unbearable@ietf.org>; Mon, 31 Aug 2015 12:32:28 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.256.15; Mon, 31 Aug 2015 19:32:25 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0256.013; Mon, 31 Aug 2015 19:32:25 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Bill Cox <waywardgeek@google.com>, "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: [Unbearable] Token Binding extension has incorrect size for key array
Thread-Index: AQHQ4pNoYyV6p4vPnkefMel8qjcth54mfgoQ
Date: Mon, 31 Aug 2015 19:32:25 +0000
Message-ID: <BLUPR03MB139668D227DFFF3D644055A78C6B0@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CAH9QtQH3WMwePdwcpV-XYBVDnWBx=BzY7FxTqCGSoPp0q3vDmQ@mail.gmail.com>
In-Reply-To: <CAH9QtQH3WMwePdwcpV-XYBVDnWBx=BzY7FxTqCGSoPp0q3vDmQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8:4::1d2]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:KtqTSdzOayVE9FthnTgqoUiB8JaW1L5wl87MYCwDjSS9Wf9CGdOc+0VlXJ/a8pKFQCFvO2usTDskP8ifWWpZXX2rQ/FTVhEE3ekWuncEykpY7cLKWTur54AyPfK5MeS/3R6eOM5sqH5Z2NArtTIGZA==; 24:76qP5a9dThdhEVD1YVYmgGPnnzA3fFKI8M61VpV2Whf0ik1p/Sma8ukpJyYZ9oJBsk3O9fsXXniPE/PvARNd3lKav22nTaMXO3YHm5nR5GA=; 20:Ob6j7Lfx+Z2INBUFjRL1B3KaUmhZGbam8L2Mjo3qTST3VGix7hYQwcXkgnKW2y1h6UKWMDn1kL/1hbfsTdiDSg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
x-microsoft-antispam-prvs: <BLUPR03MB1396970FA77A191D63EA12128C6B0@BLUPR03MB1396.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; 
x-forefront-prvs: 0685122203
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(164054003)(377454003)(199003)(5002640100001)(64706001)(2656002)(46102003)(10290500002)(5007970100001)(8990500004)(106356001)(19617315012)(10400500002)(77096005)(105586002)(5004730100002)(76576001)(16236675004)(19609705001)(122556002)(15975445007)(40100003)(2900100001)(86362001)(102836002)(19625215002)(99286002)(33656002)(76176999)(10090500001)(5001830100001)(19580395003)(189998001)(2501003)(5001960100002)(50986999)(97736004)(86612001)(5005710100001)(106116001)(87936001)(77156002)(68736005)(74316001)(5003600100002)(5001770100001)(62966003)(19580405001)(2950100001)(5001860100001)(54356999)(81156007)(101416001)(4001540100001)(92566002)(19300405004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139668D227DFFF3D644055A78C6B0BLUPR03MB1396namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2015 19:32:25.3347 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/B99RRe08k1featYQA0rh3iUHnyk>
Cc: Nick Harper <nharper@google.com>
Subject: Re: [Unbearable] Token Binding extension has incorrect size for key array
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 19:32:31 -0000

--_000_BLUPR03MB139668D227DFFF3D644055A78C6B0BLUPR03MB1396namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQmlsbCwNCg0KMSkgSSBicm91Z2h0IHRoaXMgdXAgZm9yIGRpc2N1c3Npb24gaW4gUHJhZ3Vl
IGFuZCB0aGUgZ3JvdXAgc2VlbWVkIHRvIGhhdmUgbm8gaW50ZXJlc3QgaW4gYSBtb3JlIGVsYWJv
cmF0ZSB2ZXJzaW9uIG5lZ290aWF0aW9uIG1lY2hhbmlzbS4gSWYgZW5vdWdoIHBlb3BsZSBhcmUg
aW50ZXJlc3RlZCBpbiByZW9wZW5pbmcgdGhpcyBjb252ZXJzYXRpb24sIHN1cmUgd2UgY2FuIGNv
bWUgdXAgd2l0aCBhIHJhbmdlIG9mIHZlcnNpb25zLCBhIGxpc3Qgb2YgdmVyc2lvbnMsIG9yIGEg
VExTLXN0eWxlIOKAnGhpZ2hlc3Qgc3VwcG9ydGVkIHZlcnNpb27igJ0gbWVjaGFuaXNtLg0KMikg
VGhpcyB3YXMgdGhlIDJuZCBwb2ludCBJIGJyb3VnaHQgdXAgaW4gUHJhZ3VlLiBBZ2FpbiwgY29u
c2Vuc3VzIGluIHRoZSByb29tIHdhcyB0byBrZWVwIG5lZ290aWF0aW5nIG9ubHkgb25lIGFsZ29y
aXRobSAoYnV0IHRvIGFsbG93IHRoZSBjbGllbnQgc2VuZCBvdGhlciB0eXBlcyBvZiBrZXlzIGlu
IHRoZSBmZWRlcmF0aW9uIGNhc2UpLg0KDQpQZXJoYXBzIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBt
YWtlIGNvbnNlbnN1cyBjYWxscyBvbiB0aGUgbWFpbGluZyBsaXN0LCB0byBjb25maXJtIChvciBv
dmVydHVybikgdGhlIGRlY2lzaW9ucyBtYWRlIGluIFByYWd1ZT8NCg0KQ2hlZXJzLA0KDQpBbmRy
ZWkNCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIEJpbGwgQ294DQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDI5LCAyMDE1
IDEyOjQ2IFBNDQpUbzogdW5iZWFyYWJsZUBpZXRmLm9yZw0KQ2M6IE5pY2sgSGFycGVyIDxuaGFy
cGVyQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBbVW5iZWFyYWJsZV0gVG9rZW4gQmluZGluZyBleHRl
bnNpb24gaGFzIGluY29ycmVjdCBzaXplIGZvciBrZXkgYXJyYXkNCg0KVGhlIHNwZWM8aHR0cHM6
Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1wb3Bvdi10b2tiaW5kLW5lZ290aWF0aW9uLTAwLnR4
dD4gYW5kIHVzZWQgYSB1aW50MTYgZm9yIHRoZSBsZW5ndGggb2YgdGhlIGtleSB0eXBlIGFycmF5
LCBidXQgdGhlIGtleXMgYXJlIDgtYml0IHZhbHVlcyBhbmQgYXJlIG5vdCBhbGxvd2VkIHRvIHJl
cGVhdC4gIFRoaXMgaXMgY2xlYXJseSBhbiBlcnJvciBpbiB0aGUgc3BlYy4gIEkgdXNlZCBhIDEt
Ynl0ZSBsZW5ndGggaW5zdGVhZC4gIE5vIHBvaW50IHdhc3RpbmcgYSBieXRlIDopDQoNClR3byBv
dGhlciBpc3N1ZXMgaW4gdGhpcyBzcGVjOg0KDQoxKSBUaGUgc2VydmVyIGhhcyB0byBpZ25vcmUg
dGhpcyBleHRlbnNpb24gaWYgdGhlIGNsaWVudCBicm9hZGNhc3RzIHN1cHBvcnQgZm9yIGEgbmV3
ZXIgdmVyc2lvbiB0aGFuIHRoZSBzZXJ2ZXIga25vd3MgYWJvdXQuICBUaGlzIHdpbGwgcmVzdWx0
IGluIFRva2VuIEJpbmRpbmcgYmVpbmcgZGlzYWJsZWQgd2hlbmV2ZXIgdGhlIGNsaWVudCBzdXBw
b3J0cyBhIG5ld2VyIHZlcnNpb24gdGhhbiB0aGUgc2VydmVyLCBvciBhbHRlcm5hdGl2ZWx5LCBj
bGllbnRzIHdpbGwgaGF2ZSB0byBiZSBjYXJlZnVsIHRvIG9ubHkgYnJvYWRjYXN0IG9sZGVyIHdl
bGwgc3VwcG9ydGVkIHZlcnNpb25zLiAgVGhpcyBzaG91bGQgcHJvYmFibHkgYmUgYSByYW5nZSBv
ZiB2ZXJzaW9ucyByYXRoZXIgdGhhbiBqdXN0IG9uZS4gIE15IHByZWZlcmVuY2UgaXMgdG8gc2lt
cGxpZnkgdGhlIHZlcnNpb24gbnVtYmVyIHRvIDEgYnl0ZSAsYW5kIHNlbmQgYSAyLWJ5dGUgcmFu
Z2UuICAwIHdvdWxkIGJlIHRoZSBwcm90b3R5cGUgdmVyc2lvbiwgYW5kIDEsIHdvdWxkIGJlIHRo
ZSBmaXJzdCBvZmZpY2lhbCB2ZXJzaW9uLiAgVGhlIHNlcnZlciB3b3VsZCBwaWNrIGEgdmVyc2lv
biBmcm9tIHRoZSByYW5nZSBzZW50IGJ5IHRoZSBjbGllbnQgYW5kIHNlbmQgdGhlIHNhbWUgdmVy
c2lvbiByZXBlYXRlZCAoc28gdGhhdCBzZXJ2ZXIgYW5kIGNsaWVudCBoZWFkZXJzIGFyZSB0aGUg
c2FtZSBzaXplKS4gIEkgZG8gbm90IHRoaW5rIHdlIG5lZWQgYSAyLWJ5dGUgdmVyc2lvbiBmb3Ig
dGhpcyBzaW1wbGUgZXh0ZW5zaW9uLiAgRXZlcnkgYnl0ZSBjb3VudHMgOikNCg0KMikgVGhlIHNl
cnZlciBjdXJyZW50bHkgaGFzIG5vIHdheSB0byBpbmZvcm0gdGhlIGNsaWVudCB3aGF0IGl0J3Mg
cHJlZmVyZW5jZXMgYXJlLiAgSW5zdGVhZCwgdGhlIHNlcnZlciBoYXMgdG8gcGljayBqdXN0IG9u
ZS4gIEluIHRoZSBjYXNlIHdoZXJlIHRoZSBzZXJ2ZXIgcHJlZmVycyBFQ0RTQSwgYnV0IHRoZSBj
bGllbnQgYWxyZWFkeSBoYXMgYW4gUlNBIGtleSBwYWlyLCB0aGUgc2VydmVyIGlzIGxpa2VseSB0
byBwaWNrIEVDRFNBLCBpbnZhbGlkYXRpbmcgdGhlIGNsaWVudCdzIGtleSBwYWlyLiAgSW5zdGVh
ZCwgSSBzZW5kIGEgbGlzdCBvZiBhY2NlcHRhYmxlIHBhcmFtZXRlcnMgYm90aCB3YXlzLCBpbiBv
cmRlciBvZiBwcmVmZXJlbmNlLCB3aGVyZSB0aGUgc2VydmVyIHNlbmRzIGEgc3Vic2V0IG9mIHRo
ZSBsaXN0IHJlY2VpdmVkIGZyb20gdGhlIGNsaWVudC4gIFRoaXMgYWxsb3dzIHRoZSBjbGllbnQg
dG8ga25vdyB0aGF0IHRoZSBzZXJ2ZXIgcHJlZmVycyBFQ0RTQSBidXQgaXMgd2lsbGluZyB0byBj
b250aW51ZSBzdXBwb3J0IGZvciBSU0EsIGFuZCB0aGUgY2xpZW50IGNhbiBjaG9vc2UgdG8gY29u
dGludWUgdXNpbmcgdGhlIG5ldyBrZXkgb3Igbm90Lg0KDQpUaGFua3MsDQpCaWxsDQo=

--_000_BLUPR03MB139668D227DFFF3D644055A78C6B0BLUPR03MB1396namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs
IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w
cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp
bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0
Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy
aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t
c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u
RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN
Cgl7bXNvLWxpc3QtaWQ6MTk4MTI1OTIzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s
aXN0LXRlbXBsYXRlLWlkczo3Mjc3MzQyNTAgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2
OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxp
c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo
YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05
LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz
dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg
bDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu
LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206
MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+SGkgQmlsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjEp
IEkgYnJvdWdodCB0aGlzIHVwIGZvciBkaXNjdXNzaW9uIGluIFByYWd1ZSBhbmQgdGhlIGdyb3Vw
IHNlZW1lZCB0byBoYXZlIG5vIGludGVyZXN0IGluIGEgbW9yZSBlbGFib3JhdGUgdmVyc2lvbiBu
ZWdvdGlhdGlvbiBtZWNoYW5pc20uIElmIGVub3VnaCBwZW9wbGUgYXJlDQogaW50ZXJlc3RlZCBp
biByZW9wZW5pbmcgdGhpcyBjb252ZXJzYXRpb24sIHN1cmUgd2UgY2FuIGNvbWUgdXAgd2l0aCBh
IHJhbmdlIG9mIHZlcnNpb25zLCBhIGxpc3Qgb2YgdmVyc2lvbnMsIG9yIGEgVExTLXN0eWxlIOKA
nGhpZ2hlc3Qgc3VwcG9ydGVkIHZlcnNpb27igJ0gbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij4yKSBUaGlzIHdhcyB0aGUgMjxzdXA+bmQ8L3N1cD4gcG9pbnQgSSBicm91Z2h0IHVwIGluIFBy
YWd1ZS4gQWdhaW4sIGNvbnNlbnN1cyBpbiB0aGUgcm9vbSB3YXMgdG8ga2VlcCBuZWdvdGlhdGlu
ZyBvbmx5IG9uZSBhbGdvcml0aG0gKGJ1dCB0byBhbGxvdyB0aGUgY2xpZW50DQogc2VuZCBvdGhl
ciB0eXBlcyBvZiBrZXlzIGluIHRoZSBmZWRlcmF0aW9uIGNhc2UpLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGVyaGFwcyBpdCB3b3VsZCBiZSB1c2VmdWwgdG8g
bWFrZSBjb25zZW5zdXMgY2FsbHMgb24gdGhlIG1haWxpbmcgbGlzdCwgdG8gY29uZmlybSAob3Ig
b3ZlcnR1cm4pIHRoZSBkZWNpc2lvbnMgbWFkZSBpbiBQcmFndWU/PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFyYWJsZSBbbWFpbHRvOnVu
YmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmlsbCBDb3g8
YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEF1Z3VzdCAyOSwgMjAxNSAxMjo0NiBQTTxicj4N
CjxiPlRvOjwvYj4gdW5iZWFyYWJsZUBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gTmljayBIYXJw
ZXIgJmx0O25oYXJwZXJAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1VuYmVh
cmFibGVdIFRva2VuIEJpbmRpbmcgZXh0ZW5zaW9uIGhhcyBpbmNvcnJlY3Qgc2l6ZSBmb3Iga2V5
IGFycmF5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0
cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1wb3Bvdi10b2tiaW5kLW5lZ290aWF0aW9uLTAw
LnR4dCI+VGhlIHNwZWM8L2E+IGFuZCB1c2VkIGEgdWludDE2IGZvciB0aGUgbGVuZ3RoIG9mIHRo
ZSBrZXkgdHlwZSBhcnJheSwgYnV0IHRoZSBrZXlzIGFyZSA4LWJpdCB2YWx1ZXMgYW5kIGFyZSBu
b3QgYWxsb3dlZCB0byByZXBlYXQuJm5ic3A7IFRoaXMgaXMgY2xlYXJseSBhbiBlcnJvciBpbiB0
aGUNCiBzcGVjLiZuYnNwOyBJIHVzZWQgYSAxLWJ5dGUgbGVuZ3RoIGluc3RlYWQuJm5ic3A7IE5v
IHBvaW50IHdhc3RpbmcgYSBieXRlIDopPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5Ud28gb3RoZXIgaXNzdWVzIGluIHRoaXMgc3BlYzo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgVGhlIHNlcnZlciBo
YXMgdG8gaWdub3JlIHRoaXMgZXh0ZW5zaW9uIGlmIHRoZSBjbGllbnQgYnJvYWRjYXN0cyBzdXBw
b3J0IGZvciBhIG5ld2VyIHZlcnNpb24gdGhhbiB0aGUgc2VydmVyIGtub3dzIGFib3V0LiZuYnNw
OyBUaGlzIHdpbGwgcmVzdWx0IGluIFRva2VuIEJpbmRpbmcgYmVpbmcgZGlzYWJsZWQgd2hlbmV2
ZXIgdGhlIGNsaWVudCBzdXBwb3J0cyBhIG5ld2VyIHZlcnNpb24gdGhhbiB0aGUgc2VydmVyLA0K
IG9yIGFsdGVybmF0aXZlbHksIGNsaWVudHMgd2lsbCBoYXZlIHRvIGJlIGNhcmVmdWwgdG8gb25s
eSBicm9hZGNhc3Qgb2xkZXIgd2VsbCBzdXBwb3J0ZWQgdmVyc2lvbnMuJm5ic3A7IFRoaXMgc2hv
dWxkIHByb2JhYmx5IGJlIGEgcmFuZ2Ugb2YgdmVyc2lvbnMgcmF0aGVyIHRoYW4ganVzdCBvbmUu
Jm5ic3A7IE15IHByZWZlcmVuY2UgaXMgdG8gc2ltcGxpZnkgdGhlIHZlcnNpb24gbnVtYmVyIHRv
IDEgYnl0ZSAsYW5kIHNlbmQgYSAyLWJ5dGUgcmFuZ2UuICZuYnNwOzAgd291bGQNCiBiZSB0aGUg
cHJvdG90eXBlIHZlcnNpb24sIGFuZCAxLCB3b3VsZCBiZSB0aGUgZmlyc3Qgb2ZmaWNpYWwgdmVy
c2lvbi4mbmJzcDsgVGhlIHNlcnZlciB3b3VsZCBwaWNrIGEgdmVyc2lvbiBmcm9tIHRoZSByYW5n
ZSBzZW50IGJ5IHRoZSBjbGllbnQgYW5kIHNlbmQgdGhlIHNhbWUgdmVyc2lvbiByZXBlYXRlZCAo
c28gdGhhdCBzZXJ2ZXIgYW5kIGNsaWVudCBoZWFkZXJzIGFyZSB0aGUgc2FtZSBzaXplKS4mbmJz
cDsgSSBkbyBub3QgdGhpbmsgd2UgbmVlZCBhIDItYnl0ZQ0KIHZlcnNpb24gZm9yIHRoaXMgc2lt
cGxlIGV4dGVuc2lvbi4mbmJzcDsgRXZlcnkgYnl0ZSBjb3VudHMgOik8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgVGhlIHNlcnZlciBjdXJy
ZW50bHkgaGFzIG5vIHdheSB0byBpbmZvcm0gdGhlIGNsaWVudCB3aGF0IGl0J3MgcHJlZmVyZW5j
ZXMgYXJlLiZuYnNwOyBJbnN0ZWFkLCB0aGUgc2VydmVyIGhhcyB0byBwaWNrIGp1c3Qgb25lLiZu
YnNwOyBJbiB0aGUgY2FzZSB3aGVyZSB0aGUgc2VydmVyIHByZWZlcnMgRUNEU0EsIGJ1dCB0aGUg
Y2xpZW50IGFscmVhZHkgaGFzIGFuIFJTQSBrZXkgcGFpciwgdGhlIHNlcnZlciBpcyBsaWtlbHkN
CiB0byBwaWNrIEVDRFNBLCBpbnZhbGlkYXRpbmcgdGhlIGNsaWVudCdzIGtleSBwYWlyLiZuYnNw
OyBJbnN0ZWFkLCBJIHNlbmQgYSBsaXN0IG9mIGFjY2VwdGFibGUgcGFyYW1ldGVycyBib3RoIHdh
eXMsIGluIG9yZGVyIG9mIHByZWZlcmVuY2UsIHdoZXJlIHRoZSBzZXJ2ZXIgc2VuZHMgYSBzdWJz
ZXQgb2YgdGhlIGxpc3QgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LiZuYnNwOyBUaGlzIGFsbG93
cyB0aGUgY2xpZW50IHRvIGtub3cgdGhhdCB0aGUgc2VydmVyIHByZWZlcnMNCiBFQ0RTQSBidXQg
aXMgd2lsbGluZyB0byBjb250aW51ZSBzdXBwb3J0IGZvciBSU0EsIGFuZCB0aGUgY2xpZW50IGNh
biBjaG9vc2UgdG8gY29udGludWUgdXNpbmcgdGhlIG5ldyBrZXkgb3Igbm90LjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CaWxsPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BLUPR03MB139668D227DFFF3D644055A78C6B0BLUPR03MB1396namp_--


From nobody Mon Aug 31 12:44:40 2015
Return-Path: <waywardgeek@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C837C1B5781 for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 12:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 St16qSWf0OBL for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 12:44:37 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 AC4171B5A90 for <unbearable@ietf.org>; Mon, 31 Aug 2015 12:44:37 -0700 (PDT)
Received: by qgz60 with SMTP id 60so14766991qgz.2 for <unbearable@ietf.org>; Mon, 31 Aug 2015 12:44:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wITpPZIjyv/r4MjAY5WJl+bE8yjRD3N5c5otGhghSHI=; b=oG7utZbcf8WKwT2r77TUp2FBebq71PqA6OU6zu1nuc3su5E2alG/idCWkhNgPUCitT vQsVu8irnYvd02/bcsDEyJ/vdVcO5O2YsumHp8fEaHWCQbGOlJMlGkTNGb8lOtT9fWl7 2CcXpB/o+1waKs3/EnI3sJ5JLV8XN/Yh/i8G7biVkq6SAZF2x5fmyaanU3B3WaTvumD5 YxqbgUFmETDkstgStFHG4Ouc7OlWYHy4/CDwFKDYOSfgwJkbG60hiV+mRuhcH3GjuLHa tCcsbHgErYc27Vi0g9gl6FhrBBWxNvxdv6m1g1hgUDqyQmhI+PvGacUcm09fIzE8bqlq lJGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wITpPZIjyv/r4MjAY5WJl+bE8yjRD3N5c5otGhghSHI=; b=KKRN7x78FLymVrt0JzzhzXpaz1oE00ukstXX4TomS/V06NYLKnQOXR9snv5OVSfgbc 2bDvGOAde8xLf1n6TGJWxrxmJeeObevMHepozP/+sw/Vd4u2huCCol7Nmmzt9XODrubS gXweJXmnSsyjzz4eoDhiFcptZcAIiHaRN3q1+ybY7YXyKvISzV4F2tCxxMjz5axuJ81i 0SJVuHxBqjXoqBNmyNrsBSdY2DLIY6oJ/sRKOjiDK5yZz9Y7xWGPJ5DnXdx9R+QKNn07 EJyDP75gJBVE5ww1JToiJO7BTBCImiexJqi6ml/UuxP0MwecRED5tX9I3JizClK8mfT9 JOAQ==
X-Gm-Message-State: ALoCoQnvuf2CY4bsghkmy5MyQLZwed6Wy04E4OMW+37HFf56q0enEnVpVaBpJ6jurjGw2qgFDYu9
MIME-Version: 1.0
X-Received: by 10.140.133.135 with SMTP id 129mr42222313qhf.95.1441050276131;  Mon, 31 Aug 2015 12:44:36 -0700 (PDT)
Received: by 10.55.84.65 with HTTP; Mon, 31 Aug 2015 12:44:36 -0700 (PDT)
In-Reply-To: <BLUPR03MB139668D227DFFF3D644055A78C6B0@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CAH9QtQH3WMwePdwcpV-XYBVDnWBx=BzY7FxTqCGSoPp0q3vDmQ@mail.gmail.com> <BLUPR03MB139668D227DFFF3D644055A78C6B0@BLUPR03MB1396.namprd03.prod.outlook.com>
Date: Mon, 31 Aug 2015 12:44:36 -0700
Message-ID: <CAH9QtQE+PT_DWkvnSKESuWXnAeLyTTDOtuGphe3tLjn3anFY6A@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary=001a1136fd7cd066e2051ea0a979
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/KtT4YI2JS2ySW2gV-DxnWXCoOzc>
Cc: "unbearable@ietf.org" <unbearable@ietf.org>, Nick Harper <nharper@google.com>
Subject: Re: [Unbearable] Token Binding extension has incorrect size for key array
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 19:44:38 -0000

--001a1136fd7cd066e2051ea0a979
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 31, 2015 at 12:32 PM, Andrei Popov <Andrei.Popov@microsoft.com>
wrote:

> Hi Bill,
>
>
>
> 1) I brought this up for discussion in Prague and the group seemed to hav=
e
> no interest in a more elaborate version negotiation mechanism. If enough
> people are interested in reopening this conversation, sure we can come up
> with a range of versions, a list of versions, or a TLS-style =E2=80=9Chig=
hest
> supported version=E2=80=9D mechanism.
>
> 2) This was the 2nd point I brought up in Prague. Again, consensus in the
> room was to keep negotiating only one algorithm (but to allow the client
> send other types of keys in the federation case).
>
>
>
> Perhaps it would be useful to make consensus calls on the mailing list, t=
o
> confirm (or overturn) the decisions made in Prague?
>
>
>
> Cheers,
>
>
>
> Andrei
>

As an implementer, I would appreciate tentative decisions on the list,
since I'm currently writing the code.

Thanks,
Bill

--001a1136fd7cd066e2051ea0a979
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 31, 2015 at 12:32 PM, Andrei Popov <span dir=3D"ltr">&lt;<a href=3D=
"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov@microsof=
t.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Hi Bill,<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">1) I brought this up for discussion i=
n Prague and the group seemed to have no interest in a more elaborate versi=
on negotiation mechanism. If enough people are
 interested in reopening this conversation, sure we can come up with a rang=
e of versions, a list of versions, or a TLS-style =E2=80=9Chighest supporte=
d version=E2=80=9D mechanism.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">2) This was the 2<sup>nd</sup> point =
I brought up in Prague. Again, consensus in the room was to keep negotiatin=
g only one algorithm (but to allow the client
 send other types of keys in the federation case).<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Perhaps it would be useful to make co=
nsensus calls on the mailing list, to confirm (or overturn) the decisions m=
ade in Prague?<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Cheers,<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Andrei</span></p></div></div></blockq=
uote><div><br></div><div>As an implementer, I would appreciate tentative de=
cisions on the list, since I&#39;m currently writing the code.</div><div><b=
r></div><div>Thanks,</div><div>Bill</div></div></div></div>

--001a1136fd7cd066e2051ea0a979--


From nobody Mon Aug 31 12:53:00 2015
Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8B31B5BD9 for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 12:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 W0ab7HWmJlOo for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 12:52:56 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450D61B5BD7 for <unbearable@ietf.org>; Mon, 31 Aug 2015 12:52:56 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.256.15; Mon, 31 Aug 2015 19:52:53 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0256.013; Mon, 31 Aug 2015 19:52:53 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Bill Cox <waywardgeek@google.com>, Leif Johansson <leifj@sunet.se>, "John Bradley" <ve7jtb@ve7jtb.com>
Thread-Topic: [Unbearable] Token Binding extension has incorrect size for key array
Thread-Index: AQHQ5CV4ucl9EyIOxk6EC6af19hkJZ4mgvBQ
Date: Mon, 31 Aug 2015 19:52:53 +0000
Message-ID: <BLUPR03MB13965B5E315AB53C1C1F9C098C6B0@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CAH9QtQH3WMwePdwcpV-XYBVDnWBx=BzY7FxTqCGSoPp0q3vDmQ@mail.gmail.com> <BLUPR03MB139668D227DFFF3D644055A78C6B0@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQE+PT_DWkvnSKESuWXnAeLyTTDOtuGphe3tLjn3anFY6A@mail.gmail.com>
In-Reply-To: <CAH9QtQE+PT_DWkvnSKESuWXnAeLyTTDOtuGphe3tLjn3anFY6A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8:4::1d2]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:AmjPZk2CPbiovIrZuCKGhjlKG+fw8bY5GXcN9QHrjAC4mHJ39fdoEShh8FFTI4TLGwRSGswOtSqIJqX2cmcZV8EuP/gu83v1zRZ5n9aMi6+wRkTzfO5AEZ9guvwocCfYzpHur1CZ9628lz8B4bU/SA==; 24:Mzb1pQ56AatHNC/o0XyoXpd4t80y1Ob37EXrmlK67khSBGDk93LKuIa0FEj/hhPFxjRQY0i15boAR9qwtrJv+e5IsYOjdBR6J6YWflwYw4g=; 20:9Gxc2MKoWqQJnnER5u9H+oXxI0mU0QaCcTjxwL2eTLqiZ4HosVhWDdChj7u69WZOENPxOiiCPcQ64bcS2OEHsw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395;
x-microsoft-antispam-prvs: <BLUPR03MB13951B3DD26974DD1A2DFACC8C6B0@BLUPR03MB1395.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; 
x-forefront-prvs: 0685122203
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(164054003)(377454003)(189002)(24454002)(2656002)(19580405001)(15975445007)(86362001)(54356999)(19580395003)(92566002)(5001770100001)(106356001)(10090500001)(105586002)(5001960100002)(76176999)(5001830100001)(64706001)(74316001)(2950100001)(46102003)(8990500004)(5001860100001)(68736005)(87936001)(97736004)(101416001)(50986999)(4001540100001)(81156007)(189998001)(86612001)(19625215002)(5003600100002)(10400500002)(10290500002)(5002640100001)(77156002)(19300405004)(40100003)(2900100001)(62966003)(77096005)(33656002)(102836002)(99286002)(122556002)(19609705001)(5004730100002)(106116001)(16236675004)(5005710100001)(5007970100001)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13965B5E315AB53C1C1F9C098C6B0BLUPR03MB1396namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2015 19:52:53.0492 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/Gar1UjUfhi3wG9FdjwmcO0Pt21I>
Cc: "unbearable@ietf.org" <unbearable@ietf.org>, Nick Harper <nharper@google.com>
Subject: Re: [Unbearable] Token Binding extension has incorrect size for key array
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 19:52:58 -0000

--_000_BLUPR03MB13965B5E315AB53C1C1F9C098C6B0BLUPR03MB1396namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PCsgQ2hhaXJzPg0KDQpZZXMsIHVubGVzcyBJIG1pc3NlZCBpdCwgdGhlIHRlbnRhdGl2ZSBkZWNp
c2lvbnMvbWludXRlcyBmcm9tIFByYWd1ZSB3ZXJlIG5vdCBwdWJsaXNoZWQgb24gdGhlIHVuYmVh
cmFibGUgbWFpbGluZyBsaXN0Lg0KDQpGcm9tOiBCaWxsIENveCBbbWFpbHRvOndheXdhcmRnZWVr
QGdvb2dsZS5jb21dDQpTZW50OiBNb25kYXksIEF1Z3VzdCAzMSwgMjAxNSAxMjo0NSBQTQ0KVG86
IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogdW5iZWFyYWJs
ZUBpZXRmLm9yZzsgTmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJl
OiBbVW5iZWFyYWJsZV0gVG9rZW4gQmluZGluZyBleHRlbnNpb24gaGFzIGluY29ycmVjdCBzaXpl
IGZvciBrZXkgYXJyYXkNCg0KT24gTW9uLCBBdWcgMzEsIDIwMTUgYXQgMTI6MzIgUE0sIEFuZHJl
aSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBt
aWNyb3NvZnQuY29tPj4gd3JvdGU6DQpIaSBCaWxsLA0KDQoxKSBJIGJyb3VnaHQgdGhpcyB1cCBm
b3IgZGlzY3Vzc2lvbiBpbiBQcmFndWUgYW5kIHRoZSBncm91cCBzZWVtZWQgdG8gaGF2ZSBubyBp
bnRlcmVzdCBpbiBhIG1vcmUgZWxhYm9yYXRlIHZlcnNpb24gbmVnb3RpYXRpb24gbWVjaGFuaXNt
LiBJZiBlbm91Z2ggcGVvcGxlIGFyZSBpbnRlcmVzdGVkIGluIHJlb3BlbmluZyB0aGlzIGNvbnZl
cnNhdGlvbiwgc3VyZSB3ZSBjYW4gY29tZSB1cCB3aXRoIGEgcmFuZ2Ugb2YgdmVyc2lvbnMsIGEg
bGlzdCBvZiB2ZXJzaW9ucywgb3IgYSBUTFMtc3R5bGUg4oCcaGlnaGVzdCBzdXBwb3J0ZWQgdmVy
c2lvbuKAnSBtZWNoYW5pc20uDQoyKSBUaGlzIHdhcyB0aGUgMm5kIHBvaW50IEkgYnJvdWdodCB1
cCBpbiBQcmFndWUuIEFnYWluLCBjb25zZW5zdXMgaW4gdGhlIHJvb20gd2FzIHRvIGtlZXAgbmVn
b3RpYXRpbmcgb25seSBvbmUgYWxnb3JpdGhtIChidXQgdG8gYWxsb3cgdGhlIGNsaWVudCBzZW5k
IG90aGVyIHR5cGVzIG9mIGtleXMgaW4gdGhlIGZlZGVyYXRpb24gY2FzZSkuDQoNClBlcmhhcHMg
aXQgd291bGQgYmUgdXNlZnVsIHRvIG1ha2UgY29uc2Vuc3VzIGNhbGxzIG9uIHRoZSBtYWlsaW5n
IGxpc3QsIHRvIGNvbmZpcm0gKG9yIG92ZXJ0dXJuKSB0aGUgZGVjaXNpb25zIG1hZGUgaW4gUHJh
Z3VlPw0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpBcyBhbiBpbXBsZW1lbnRlciwgSSB3b3VsZCBh
cHByZWNpYXRlIHRlbnRhdGl2ZSBkZWNpc2lvbnMgb24gdGhlIGxpc3QsIHNpbmNlIEknbSBjdXJy
ZW50bHkgd3JpdGluZyB0aGUgY29kZS4NCg0KVGhhbmtzLA0KQmlsbA0K

--_000_BLUPR03MB13965B5E315AB53C1C1F9C098C6B0BLUPR03MB1396namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl
OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g
MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot
LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl
eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+
DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZsdDsmIzQzOyBDaGFpcnMmZ3Q7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZZXMsIHVubGVzcyBJIG1pc3NlZCBpdCwg
dGhlIHRlbnRhdGl2ZSBkZWNpc2lvbnMvbWludXRlcyBmcm9tIFByYWd1ZSB3ZXJlIG5vdCBwdWJs
aXNoZWQgb24gdGhlIHVuYmVhcmFibGUgbWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCaWxsIENveCBb
bWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5
LCBBdWd1c3QgMzEsIDIwMTUgMTI6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlaSBQb3BvdiAm
bHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB1bmJlYXJh
YmxlQGlldGYub3JnOyBOaWNrIEhhcnBlciAmbHQ7bmhhcnBlckBnb29nbGUuY29tJmd0Ozxicj4N
CjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIFRva2VuIEJpbmRpbmcgZXh0ZW5zaW9u
IGhhcyBpbmNvcnJlY3Qgc2l6ZSBmb3Iga2V5IGFycmF5PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEF1ZyAzMSwgMjAxNSBhdCAxMjoz
MiBQTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jv
c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw
dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQmls
bCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4xKSBJIGJy
b3VnaHQgdGhpcyB1cCBmb3IgZGlzY3Vzc2lvbiBpbiBQcmFndWUgYW5kIHRoZSBncm91cCBzZWVt
ZWQgdG8gaGF2ZSBubyBpbnRlcmVzdCBpbiBhIG1vcmUgZWxhYm9yYXRlDQogdmVyc2lvbiBuZWdv
dGlhdGlvbiBtZWNoYW5pc20uIElmIGVub3VnaCBwZW9wbGUgYXJlIGludGVyZXN0ZWQgaW4gcmVv
cGVuaW5nIHRoaXMgY29udmVyc2F0aW9uLCBzdXJlIHdlIGNhbiBjb21lIHVwIHdpdGggYSByYW5n
ZSBvZiB2ZXJzaW9ucywgYSBsaXN0IG9mIHZlcnNpb25zLCBvciBhIFRMUy1zdHlsZSDigJxoaWdo
ZXN0IHN1cHBvcnRlZCB2ZXJzaW9u4oCdIG1lY2hhbmlzbS48L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4y
KSBUaGlzIHdhcyB0aGUgMjxzdXA+bmQ8L3N1cD4gcG9pbnQgSSBicm91Z2h0IHVwIGluIFByYWd1
ZS4gQWdhaW4sIGNvbnNlbnN1cyBpbiB0aGUgcm9vbSB3YXMgdG8ga2VlcA0KIG5lZ290aWF0aW5n
IG9ubHkgb25lIGFsZ29yaXRobSAoYnV0IHRvIGFsbG93IHRoZSBjbGllbnQgc2VuZCBvdGhlciB0
eXBlcyBvZiBrZXlzIGluIHRoZSBmZWRlcmF0aW9uIGNhc2UpLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBlcmhhcHMgaXQgd291bGQgYmUgdXNlZnVsIHRv
IG1ha2UgY29uc2Vuc3VzIGNhbGxzIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHRvIGNvbmZpcm0gKG9y
IG92ZXJ0dXJuKSB0aGUNCiBkZWNpc2lvbnMgbWFkZSBpbiBQcmFndWU/PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5BcyBhbiBpbXBsZW1lbnRlciwgSSB3b3VsZCBhcHByZWNpYXRlIHRlbnRhdGl2ZSBk
ZWNpc2lvbnMgb24gdGhlIGxpc3QsIHNpbmNlIEknbSBjdXJyZW50bHkgd3JpdGluZyB0aGUgY29k
ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+QmlsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BLUPR03MB13965B5E315AB53C1C1F9C098C6B0BLUPR03MB1396namp_--


From nobody Mon Aug 31 12:54:42 2015
Return-Path: <balfanz@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CA61B5C0D for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 12:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 yuTrhV7zARnJ for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 12:54:40 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 808971B5C0C for <unbearable@ietf.org>; Mon, 31 Aug 2015 12:54:40 -0700 (PDT)
Received: by qkbp67 with SMTP id p67so14180147qkb.3 for <unbearable@ietf.org>; Mon, 31 Aug 2015 12:54:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=YksK9x36Ls78MZyu3AKrfsKwBzIaN87bL1KCKuZMKAo=; b=K51LwimRXtzbfKNg0ng4wkpL7kBZCZFgBcYiHkSTHFNnHVFEwFUHr2kRIs8h8ykAYs l/FZeT0f0LgJz6AXROIBEJdcsdrMJ/u/Rndri2EKQCxAgsvR8c2uGdyq78mC73PYgDo6 HhJPWylSriUnhGkvNdQR5q7V2eJfkhJ8UKzBTSS0Ip08smgp9INW++azBYgQsWoSDSb4 uMDR6NIAS2ilc0kdCccn5lo4QvkRzGXVaNx06iTLX9f3lfWFHu3HsmOyuB13uhe42X5p uuHnMpvd1HMVSxD3GRgMrOZ/g19iSb7aJdYTrNIf+J9kZuzmyE4YpSfuRLhKFvx/Pz/V 5CuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=YksK9x36Ls78MZyu3AKrfsKwBzIaN87bL1KCKuZMKAo=; b=azensd1PWUoWn0lo7hHfNX3t4gzHXfJZSzDp8yPN/78FJNte/o5CHkHhEu/qJbVtoe Z3V6SE1zM887ohkIFChXNJSTQai55p8A0zJlhOrVTPkoGcM5GxBNwiDFKsWqCbnB6fwI dPdw4gfZzSlY8BoJQwlqnRoh5Nscs1MtuHF6NOGUeDcdxDdBQkfEmX4/MpkDbDHng/kw 2Ba9gQiAGuETUJDcHkJi7u24Juh4nF01INIY4ahdIg0btdc+Y/WOOkc9r29M75pnIVSZ mkuQFbqYn7gSN8tDl/rJQXnc2eEdyGAuRYqrDrSge2U750LOjXoh3Vl+iMLUBuDdzmN0 XviA==
X-Gm-Message-State: ALoCoQmWjEfwKUc+Zq5xH5Ed35vYkZP/larcoABVCo44263FUKvZ9ah+6TvpT3VAEFimLyKUuxyo
X-Received: by 10.129.90.138 with SMTP id o132mr4792503ywb.32.1441050879553; Mon, 31 Aug 2015 12:54:39 -0700 (PDT)
MIME-Version: 1.0
From: Dirk Balfanz <balfanz@google.com>
Date: Mon, 31 Aug 2015 19:54:30 +0000
Message-ID: <CADHfa2BBTS6C8Q17m+eCFojaUDreBVfB=oE-zYBbHBfJaAPvxw@mail.gmail.com>
To: Tokbind WG <unbearable@ietf.org>
Content-Type: multipart/alternative; boundary=001a1149126ac80091051ea0cd2c
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/-1yTrjSsD64lkPTvY2rvpJnc55Y>
Subject: [Unbearable] Interim meeting
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 19:54:41 -0000

--001a1149126ac80091051ea0cd2c
Content-Type: text/plain; charset=UTF-8

Hi token binders,

where are we at with scheduling an interim meeting before Yokohama?

Dirk.

--001a1149126ac80091051ea0cd2c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi token binders, =C2=A0<div><br></div><div>where are we a=
t with scheduling an interim meeting before Yokohama?</div><div><br></div><=
div>Dirk.</div><div><br></div></div>

--001a1149126ac80091051ea0cd2c--


From nobody Mon Aug 31 13:05:49 2015
Return-Path: <leifj@mnt.se>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC74F1B5DA1 for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 13:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 l0vC--MWhtGf for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 13:05:45 -0700 (PDT)
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (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 DE7C61B5DA7 for <unbearable@ietf.org>; Mon, 31 Aug 2015 13:05:44 -0700 (PDT)
Received: by labnh1 with SMTP id nh1so53687406lab.3 for <unbearable@ietf.org>; Mon, 31 Aug 2015 13:05:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+yY4luKxLXUX5QVwpio2loS3+ucxZpOoL+Y80s8A89k=; b=Wq9oMKNIUmdXgmd0Ts0IK39oh8D6ZCq2hkUQomS4sD4Lr0zigDo3qZg2+ffISlzSrs 6d+sUFChdcm1eFTPWJB1TPqfMuvza1ECfFe0DJepMYWqdsS3vMDihUvbzz9H3qLtlZDP /zFmZy7Nq9VFbeDTKsjQmJ/vaBuf5Jb+Go2sP9z8rDbJHBCve0zpZuhA4knFFBqdUO0O ofk0mjr0Z7nL29iMPUo+Kw5tSXvMvndQivQ9KagNzGdIpLnTCGJx7/kk6C1547kGHT7z fKe/y/TaO+pPSUu3pyfb2IK5x0kNU2Ebpr9ywNpf/B2yEQ4OC4KqaXaHMNH13WXv9ya1 zjeQ==
X-Gm-Message-State: ALoCoQk7h4N+LKGBMZJ5uqKbLbhfO/kAHT0i7gLykTJAOBzjOWNWkLb5rLoZxfmowsYiVm62p9Ww
X-Received: by 10.112.181.197 with SMTP id dy5mr10929283lbc.109.1441051542819;  Mon, 31 Aug 2015 13:05:42 -0700 (PDT)
Received: from [192.168.1.109] ([94.140.51.73]) by smtp.gmail.com with ESMTPSA id tv6sm4201379lbb.31.2015.08.31.13.05.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Aug 2015 13:05:41 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Leif Johansson <leifj@mnt.se>
X-Mailer: iPhone Mail (12H321)
In-Reply-To: <CADHfa2BBTS6C8Q17m+eCFojaUDreBVfB=oE-zYBbHBfJaAPvxw@mail.gmail.com>
Date: Mon, 31 Aug 2015 22:05:37 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <6B0DDBE0-0DC0-47B9-B46B-3259AF246CE9@mnt.se>
References: <CADHfa2BBTS6C8Q17m+eCFojaUDreBVfB=oE-zYBbHBfJaAPvxw@mail.gmail.com>
To: Dirk Balfanz <balfanz@google.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/uzytnVwYpOZr_dR0X0oVudBipeA>
Cc: Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] Interim meeting
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 20:05:47 -0000

> 31 aug 2015 kl. 21:54 skrev Dirk Balfanz <balfanz@google.com>:
> 
> Hi token binders,  
> 
> where are we at with scheduling an interim meeting before Yokohama?
> 

I haven't seen anything close to consensus unfortunately.

> Dirk.
> 
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable


From nharper@google.com  Mon Aug 31 13:24:26 2015
Return-Path: <nharper@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2677F1B5F70 for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 13:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 1rvDVcZNJmhe for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 13:24:24 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 2BB041B4A2E for <unbearable@ietf.org>; Mon, 31 Aug 2015 13:24:24 -0700 (PDT)
Received: by oigk185 with SMTP id k185so65827846oig.2 for <unbearable@ietf.org>; Mon, 31 Aug 2015 13:24:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JtCF4jFquCWGptDWt+MSrLCkcfsGggzT3+zDWP05SC0=; b=foL8fi5FrwoeB+vuaV9R1K7uNZAk3g9qQTQzleGa8cMRgoFV4jW2jTWpoK0PD28uJF pPxIPT1attzzFY1v1KarAFcKdS8bVqZg79oYuqzgF4ZyWEogONlwpOv7zSOIZu7iQjlW gMCo0EIVCwqNn20lacByPlq/DMeyECw+AAIyxePPboE0tk458BEp0MUp47qmPQ4jH5DR kVbXYqLCD0ak3VJ3W8LWa5dIj/Fc0DQ9zjfCEewAYumKSZp7l0a/yidl44gJpmao9KS3 mpm04mPhvD3Rv1iLBbHu+yu4BYWrkNTnR/OzRDpsA+aIo3+HV8P3cY8B0RQyQhqU1tb5 w81g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JtCF4jFquCWGptDWt+MSrLCkcfsGggzT3+zDWP05SC0=; b=j8ft4vkaY5MINqdGHG/Fpi+d2HomZbTwUO7m6zqJBjyg9b6qb/p5fkXIUn4kBSaPqA q+YMZSOvbonF5E+QJbnTY+axsC4txZaNPGoorfUpG12XUXe3qTBLod540dC3pwfj7ywZ hOop95JDMftt1/yHA+SnHrSgqZL2QdaCPaexXDo+uAJhwCS7U1nfcz3SNGuDVZJpZfuy aqynnK6J0BthAOtRZRXkvwJGxTPosoMc7AxT/irJHhjXGkH3SPQU9W+JQjocuOmQM5Z3 ks5oHihUhPTq0KdcXZE0SpqNjlbSVEPaxb+aUsgU9wakFDaFPZ89lpOjmLAZ40QaXT5l C/nA==
X-Gm-Message-State: ALoCoQm/M/orpLI7njQjsEoiSxspU53Y+VNNuS2yv2jBvbRha2y4IAVCDWGsdzUhkhBbvYlefEIr
X-Received: by 10.202.225.136 with SMTP id y130mr14453754oig.16.1441052663503;  Mon, 31 Aug 2015 13:24:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.63.132 with HTTP; Mon, 31 Aug 2015 13:24:04 -0700 (PDT)
In-Reply-To: <BLUPR03MB139668D227DFFF3D644055A78C6B0@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CAH9QtQH3WMwePdwcpV-XYBVDnWBx=BzY7FxTqCGSoPp0q3vDmQ@mail.gmail.com> <BLUPR03MB139668D227DFFF3D644055A78C6B0@BLUPR03MB1396.namprd03.prod.outlook.com>
From: Nick Harper <nharper@google.com>
Date: Mon, 31 Aug 2015 13:24:04 -0700
Message-ID: <CACdeXiKiHqGj2zdXEzOETPdy87+wT=pdDsqoACeXJLaKgY+rQQ@mail.gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary=001a113d63241c9618051ea138b3
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/RCQpBN0_b-jotGlSJisFUh_K54g>
Cc: "unbearable@ietf.org" <unbearable@ietf.org>, Bill Cox <waywardgeek@google.com>
Subject: Re: [Unbearable] Token Binding extension has incorrect size for key array
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 20:39:10 -0000

--001a113d63241c9618051ea138b3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 31, 2015 at 12:32 PM, Andrei Popov <Andrei.Popov@microsoft.com>
wrote:

> Hi Bill,
>
>
>
> 1) I brought this up for discussion in Prague and the group seemed to hav=
e
> no interest in a more elaborate version negotiation mechanism. If enough
> people are interested in reopening this conversation, sure we can come up
> with a range of versions, a list of versions, or a TLS-style =E2=80=9Chig=
hest
> supported version=E2=80=9D mechanism.
>

>From the client side implementation perspective, I would be in favor of
version negotiation including a list or range of supported versions. With
the current approach, the client can only support one version, and if it
updates to support a newer version, it would break compatibility with
servers still running the older version if the client switches too soon.


> 2) This was the 2nd point I brought up in Prague. Again, consensus in the
> room was to keep negotiating only one algorithm (but to allow the client
> send other types of keys in the federation case).
>
>
>
> Perhaps it would be useful to make consensus calls on the mailing list, t=
o
> confirm (or overturn) the decisions made in Prague?
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Bi=
ll
> Cox
> *Sent:* Saturday, August 29, 2015 12:46 PM
> *To:* unbearable@ietf.org
> *Cc:* Nick Harper <nharper@google.com>
> *Subject:* [Unbearable] Token Binding extension has incorrect size for
> key array
>
>
>
> The spec
> <https://tools.ietf.org/id/draft-popov-tokbind-negotiation-00.txt> and
> used a uint16 for the length of the key type array, but the keys are 8-bi=
t
> values and are not allowed to repeat.  This is clearly an error in the
> spec.  I used a 1-byte length instead.  No point wasting a byte :)
>
>
>
> Two other issues in this spec:
>
>
>
> 1) The server has to ignore this extension if the client broadcasts
> support for a newer version than the server knows about.  This will resul=
t
> in Token Binding being disabled whenever the client supports a newer
> version than the server, or alternatively, clients will have to be carefu=
l
> to only broadcast older well supported versions.  This should probably be=
 a
> range of versions rather than just one.  My preference is to simplify the
> version number to 1 byte ,and send a 2-byte range.  0 would be the
> prototype version, and 1, would be the first official version.  The serve=
r
> would pick a version from the range sent by the client and send the same
> version repeated (so that server and client headers are the same size).  =
I
> do not think we need a 2-byte version for this simple extension.  Every
> byte counts :)
>
>
>
> 2) The server currently has no way to inform the client what it's
> preferences are.  Instead, the server has to pick just one.  In the case
> where the server prefers ECDSA, but the client already has an RSA key pai=
r,
> the server is likely to pick ECDSA, invalidating the client's key pair.
> Instead, I send a list of acceptable parameters both ways, in order of
> preference, where the server sends a subset of the list received from the
> client.  This allows the client to know that the server prefers ECDSA but
> is willing to continue support for RSA, and the client can choose to
> continue using the new key or not.
>
>
>
> Thanks,
>
> Bill
>

--001a113d63241c9618051ea138b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Aug 31, 2015 at 12:32 PM, Andrei Popov <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov@=
microsoft.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Hi Bill,<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">1) I brought this up for discussion i=
n Prague and the group seemed to have no interest in a more elaborate versi=
on negotiation mechanism. If enough people are
 interested in reopening this conversation, sure we can come up with a rang=
e of versions, a list of versions, or a TLS-style =E2=80=9Chighest supporte=
d version=E2=80=9D mechanism.</span></p></div></div></blockquote><div><br><=
/div><div>From the client side implementation perspective, I would be in fa=
vor of version negotiation including a list or range of supported versions.=
 With the current approach, the client can only support one version, and if=
 it updates to support a newer version, it would break compatibility with s=
ervers still running the older version if the client switches too soon.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=
=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1f497d"><u></=
u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">2) This was the 2<sup>nd</sup> point =
I brought up in Prague. Again, consensus in the room was to keep negotiatin=
g only one algorithm (but to allow the client
 send other types of keys in the federation case).<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Perhaps it would be useful to make co=
nsensus calls on the mailing list, to confirm (or overturn) the decisions m=
ade in Prague?<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Cheers,<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Andrei<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:&quot;Calibri&quot;,sans-serif"> Unbearable [mailto:<a href=3D"=
mailto:unbearable-bounces@ietf.org" target=3D"_blank">unbearable-bounces@ie=
tf.org</a>]
<b>On Behalf Of </b>Bill Cox<br>
<b>Sent:</b> Saturday, August 29, 2015 12:46 PM<br>
<b>To:</b> <a href=3D"mailto:unbearable@ietf.org" target=3D"_blank">unbeara=
ble@ietf.org</a><br>
<b>Cc:</b> Nick Harper &lt;<a href=3D"mailto:nharper@google.com" target=3D"=
_blank">nharper@google.com</a>&gt;<br>
<b>Subject:</b> [Unbearable] Token Binding extension has incorrect size for=
 key array<u></u><u></u></span></p><div><div class=3D"h5">
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<div>
<p class=3D"MsoNormal"><a href=3D"https://tools.ietf.org/id/draft-popov-tok=
bind-negotiation-00.txt" target=3D"_blank">The spec</a> and used a uint16 f=
or the length of the key type array, but the keys are 8-bit values and are =
not allowed to repeat.=C2=A0 This is clearly an error in the
 spec.=C2=A0 I used a 1-byte length instead.=C2=A0 No point wasting a byte =
:)<u></u><u></u></p>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Two other issues in this spec:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">1) The server has to ignore this extension if the cl=
ient broadcasts support for a newer version than the server knows about.=C2=
=A0 This will result in Token Binding being disabled whenever the client su=
pports a newer version than the server,
 or alternatively, clients will have to be careful to only broadcast older =
well supported versions.=C2=A0 This should probably be a range of versions =
rather than just one.=C2=A0 My preference is to simplify the version number=
 to 1 byte ,and send a 2-byte range. =C2=A00 would
 be the prototype version, and 1, would be the first official version.=C2=
=A0 The server would pick a version from the range sent by the client and s=
end the same version repeated (so that server and client headers are the sa=
me size).=C2=A0 I do not think we need a 2-byte
 version for this simple extension.=C2=A0 Every byte counts :)<u></u><u></u=
></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">2) The server currently has no way to inform the cli=
ent what it&#39;s preferences are.=C2=A0 Instead, the server has to pick ju=
st one.=C2=A0 In the case where the server prefers ECDSA, but the client al=
ready has an RSA key pair, the server is likely
 to pick ECDSA, invalidating the client&#39;s key pair.=C2=A0 Instead, I se=
nd a list of acceptable parameters both ways, in order of preference, where=
 the server sends a subset of the list received from the client.=C2=A0 This=
 allows the client to know that the server prefers
 ECDSA but is willing to continue support for RSA, and the client can choos=
e to continue using the new key or not.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Bill<u></u><u></u></p>
</div>
</div>
</div></div></div>
</div>

</blockquote></div><br></div></div>

--001a113d63241c9618051ea138b3--


From nobody Mon Aug 31 14:04:36 2015
Return-Path: <waywardgeek@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1870E1A1B6B for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 14:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.511
X-Spam-Level: 
X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 tH7anRc_hL8C for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 14:04:34 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 CEC561B6242 for <unbearable@ietf.org>; Mon, 31 Aug 2015 14:04:33 -0700 (PDT)
Received: by qgeb6 with SMTP id b6so73951735qge.3 for <unbearable@ietf.org>; Mon, 31 Aug 2015 14:04:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=skVD9bKjArTRwsD8o/VLizFUp2deIZJrkX9eROdBRAs=; b=i/P7Ytm2TuA3n/JzRPuH7sIX9N9t3wj3LPxzWLKTnM1WOlVTbgoDhEMKfOa+LxZG27 DJN4dhaLuolCteCh+5cGkY7FPvhGRFoA6Qiww84M8B4/g6qId4WF1zBT7H4KFuau/5xT +2p/toiFmKd9xBXovG3XmHh9ZMt1v18TXl50oUjBz+qoOZxhjrnfax07Pr+RC/4HPEGH 4+FGZKbZURF8guAsSR12W4z+TgTj8AETV6nknCguOuwc4OCXOLxFB78VeyzprIvHe9gq RGkPQyn+kt6FS2gWkwVGVzcKSYe+IpE7JmUT0z/1E6d685t0kX/otPWqMV5/K9ogGlbD 3zYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=skVD9bKjArTRwsD8o/VLizFUp2deIZJrkX9eROdBRAs=; b=awlrP19IJd/k02Y+CrE6bd0LhXNiAmzwwFICJu3LCi9aKNxthE80nD7KjqwrPegDLM 1evVCjZYdvu7XEyf2JD+htkikoTXmi0VKEynnYqkhJTIUUBMw33Zj4F9wnq33vu6ER3m djbMsp8eQpl5PdXpEQBNt1L5HS3RfKpRDdmXGrgMGxPoMp0UEuRS4zo9i3n4nzodWt1V 9zCrm1MQ7GRRHlSMgFtsmpx8XcRlxtV465GfynxxiHVs8h+VsQXZmZpMLSydHHD158bS PdAAoTlFLAnGmcUc32XPWHB+Bz7qeua0HHUCDh1LTEkpVjRYPUqoAIyCm7Ew77se/2/f R3xw==
X-Gm-Message-State: ALoCoQn54r1/9ueB33nsTVX7nZfnSpfBO1CI7DVg4u408MkrcsI8QK8kORJNvMKKUbTGbdD0oKwy
MIME-Version: 1.0
X-Received: by 10.140.232.20 with SMTP id d20mr42544441qhc.72.1441055072524; Mon, 31 Aug 2015 14:04:32 -0700 (PDT)
Received: by 10.55.84.65 with HTTP; Mon, 31 Aug 2015 14:04:32 -0700 (PDT)
Date: Mon, 31 Aug 2015 14:04:32 -0700
Message-ID: <CAH9QtQF6FcpY3+yQgnmWyLwDnyeBoBStsk2WWy7g4BQKjnJ1wQ@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: unbearable@ietf.org
Content-Type: multipart/alternative; boundary=001a1135482cb36dcd051ea1c7e9
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/rG0jz9qVvQ69BEE19THXAPy2kV0>
Subject: [Unbearable] TLSUnique is only 96 bits. Is OK?
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 21:04:35 -0000

--001a1135482cb36dcd051ea1c7e9
Content-Type: text/plain; charset=UTF-8

Sorry for bringing up another point that has already most likely been
discussed in depth.

The TLS unique value is 12 bytes of the hash of the first finish message.
This is good enough probably for second pre-image resistance, but too weak
for collision resistance.  For use in Token Binding, I have not been able
to come up with any realistic attack based on collisions.

The basic attack would be someone trying to use your auth cookie on a
machine/account that does not have access to the Token Binding private
key.  The attacker knows he needs to generate a signature of the TLS Unique
value which will be accepted by the server.  If he has your auth cookie, he
might also have been able to monitor previous traffic, and could have
collected a few thousand signed TLS Unique values.  He might also be able
to connect to the server a few thousand times trying to get a connection
with a TLS Unique that he has seen before.

Taking this attack to the extreme, suppose the attacker can cause the
original device to make SSL connections to the server, and can generate 1
billion TLS Unique signatures.  On the alternate device, he tries 1 billion
new connections, to see if he gets a collision.  The likelihood of such an
attack succeeding is about 1 in 100 billion.

I'm OK with these odds for this specific attack.  However, I would not want
people using the TLS Unique value for cryptographically binding other
things to the TLS channel parameters.  For example, I would not want credit
card transactions to use the unique TLS unique as unique transaction
identifier.  Have we made it clear that the TLS Unique value should be used
only in well understood cases, where collision resistance is not
particularly important?

Thanks,
Bill

--001a1135482cb36dcd051ea1c7e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry for bringing up another point that has already most =
likely been discussed in depth.<div><br></div><div>The TLS unique value is =
12 bytes of the hash of the first finish message.=C2=A0 This is good enough=
 probably for second pre-image resistance, but too weak for collision resis=
tance.=C2=A0 For use in Token Binding, I have not been able to come up with=
 any realistic attack based on collisions.</div><div><br></div><div>The bas=
ic attack would be someone trying to use your auth cookie on a machine/acco=
unt that does not have access to the Token Binding private key.=C2=A0 The a=
ttacker knows he needs to generate a signature of the TLS Unique value whic=
h will be accepted by the server.=C2=A0 If he has your auth cookie, he migh=
t also have been able to monitor previous traffic, and could have collected=
 a few thousand signed TLS Unique values.=C2=A0 He might also be able to co=
nnect to the server a few thousand times trying to get a connection with a =
TLS Unique that he has seen before.</div><div><br></div><div>Taking this at=
tack to the extreme, suppose the attacker can cause the original device to =
make SSL connections to the server, and can generate 1 billion TLS Unique s=
ignatures.=C2=A0 On the alternate device, he tries 1 billion new connection=
s, to see if he gets a collision.=C2=A0 The likelihood of such an attack su=
cceeding is about 1 in 100 billion.</div><div><br></div><div>I&#39;m OK wit=
h these odds for this specific attack.=C2=A0 However, I would not want peop=
le using the TLS Unique value for cryptographically binding other things to=
 the TLS channel parameters.=C2=A0 For example, I would not want credit car=
d transactions to use the unique TLS unique as unique transaction identifie=
r.=C2=A0 Have we made it clear that the TLS Unique value should be used onl=
y in well understood cases, where collision resistance is not particularly =
important?</div><div><br></div><div>Thanks,</div><div>Bill</div></div>

--001a1135482cb36dcd051ea1c7e9--


From nobody Mon Aug 31 15:14:36 2015
Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48C11B5253 for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 15:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 wqeq9pDAnEtJ for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 15:14:33 -0700 (PDT)
Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (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 093C81B66EC for <unbearable@ietf.org>; Mon, 31 Aug 2015 15:14:32 -0700 (PDT)
Received: by qgtt94 with SMTP id t94so24144083qgt.1 for <unbearable@ietf.org>; Mon, 31 Aug 2015 15:14:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=75hzqZfvx7AjXqqhpIJaQivI9qBaxwRszzuD9ZGzqF0=; b=SW3GlhyP6agPVTQtgp909wZRQ2Jabv9QO3d7UafbN00TZrOxlyFnzDJFx6t/dEt/MX uCtn2oODPUn68u9fJIbwJ5/00j0Fue+Jdq4S6DxmOEb4Crvx5gyL/JsGiqDStLbAPc2B fNyldvZVJOL49l8x+JB65tW013NR98MJo7Ojh5w8khgm2+1s19XLm4TnGDJLbbXLfaQb AR/JJXWbZdzH4Us0VLhonkwl32G9ToUJAgaYz0Db66XKIT02vZWJLk/7fENMBGjCMU5q VojckKUNs39tHCFMU0/OvPJkok7HKIXuF03O4br1qsg3J2EqBhxdfKLIcSsC+gTbF3N6 unFA==
X-Gm-Message-State: ALoCoQk/zlCIsBCbahmhLk3bF8iYY5HavBoV+acOAJCOQUHcA5ZCsg6mz/Orfg5PRJNmu9G8jYTm
X-Received: by 10.140.237.73 with SMTP id i70mr43885428qhc.37.1441059271797; Mon, 31 Aug 2015 15:14:31 -0700 (PDT)
Received: from [192.168.8.102] ([181.202.55.19]) by smtp.gmail.com with ESMTPSA id p18sm4613825qge.40.2015.08.31.15.14.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Aug 2015 15:14:31 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_63B7AFDF-7481-4B62-A96E-D9B2C4F1D85F"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <6B0DDBE0-0DC0-47B9-B46B-3259AF246CE9@mnt.se>
Date: Mon, 31 Aug 2015 19:14:28 -0300
Message-Id: <BD5AE854-1D1F-4A9E-A45C-A8F842FD79DC@ve7jtb.com>
References: <CADHfa2BBTS6C8Q17m+eCFojaUDreBVfB=oE-zYBbHBfJaAPvxw@mail.gmail.com> <6B0DDBE0-0DC0-47B9-B46B-3259AF246CE9@mnt.se>
To: Leif Johansson <leifj@mnt.se>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/6lXUGk2NiGqD5dTTgu1CHfKQ5JE>
Cc: Tokbind WG <unbearable@ietf.org>, Dirk Balfanz <balfanz@google.com>
Subject: Re: [Unbearable] Interim meeting
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 22:14:35 -0000

--Apple-Mail=_63B7AFDF-7481-4B62-A96E-D9B2C4F1D85F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

At this point I don=E2=80=99t expect to be in North America before the =
week immediately preceding Yokohama now.

John B.

> On Aug 31, 2015, at 5:05 PM, Leif Johansson <leifj@mnt.se> wrote:
>=20
>=20
>=20
>> 31 aug 2015 kl. 21:54 skrev Dirk Balfanz <balfanz@google.com>:
>>=20
>> Hi token binders, =20
>>=20
>> where are we at with scheduling an interim meeting before Yokohama?
>>=20
>=20
> I haven't seen anything close to consensus unfortunately.
>=20
>> Dirk.
>>=20
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>=20
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable


--Apple-Mail=_63B7AFDF-7481-4B62-A96E-D9B2C4F1D85F
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTA4MzEyMjE0MjlaMCMGCSqGSIb3DQEJBDEWBBTNDQohik5UiWOsh8s/555Z
zYHXOTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBQ+YJqZhbN2roZU+1y6NTFnxBGN57ob8H+fHi5cizkMJVloKtye821
Mwd/98RLqV/myCxvr1VAUtSlj7D6/mOkIt9AxMwCjYDMDNKy2S+mjECBMbOfw4K0vbaEmivnDOA/
8ODtjtRbjcvc6eNx9WN6eaMx+enQfesliPJmYnQ4iGP8lWKFTACdfsFywPkX6BUkIpZkfcuxDFzM
omoWEB8Dma/wFo3fxGCz6kdrKnJ7/eNbt40QeKYb74AqR6nSkbzAG4QOcAhGPW57xjRsZPGbYJRv
PT/HQxRMeO+PQHtputG/lPjw0I3uO4id9j/rwzNBMnIIHG7HCjhO6kNpYPJoAAAAAAAA
--Apple-Mail=_63B7AFDF-7481-4B62-A96E-D9B2C4F1D85F--


From nobody Mon Aug 31 15:48:57 2015
Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9FB1B364C for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 15:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 W0p4Y8_v1R3L for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 15:48:49 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340CF1B4A74 for <unbearable@ietf.org>; Mon, 31 Aug 2015 15:48:49 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.256.15; Mon, 31 Aug 2015 22:48:48 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0256.013; Mon, 31 Aug 2015 22:48:48 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: John Bradley <ve7jtb@ve7jtb.com>, Leif Johansson <leifj@mnt.se>
Thread-Topic: [Unbearable] Interim meeting
Thread-Index: AQHQ5CbjZ1Wqr+yK9ku/TlIEF0BDNZ4miICAgAAkAACAAAk7sA==
Date: Mon, 31 Aug 2015 22:48:48 +0000
Message-ID: <BLUPR03MB1396D38C29C49D4A0843F6508C6B0@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CADHfa2BBTS6C8Q17m+eCFojaUDreBVfB=oE-zYBbHBfJaAPvxw@mail.gmail.com> <6B0DDBE0-0DC0-47B9-B46B-3259AF246CE9@mnt.se> <BD5AE854-1D1F-4A9E-A45C-A8F842FD79DC@ve7jtb.com>
In-Reply-To: <BD5AE854-1D1F-4A9E-A45C-A8F842FD79DC@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8:4::1d2]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:/YH3aSsz5wV7AXP1lNnAc7BrDbnhozLArjTydKJG1J9Oywvzw6P48oOGEwX6j3cyWn7Ms4QHuhRggfn42fslbhgngu44fZEtJBbmREHLJg4FNQf0QdQo31QxioWYG9JuUcDz81LY6RE+JtDBGr3H3w==; 24:GeD9Sx+tkkdKFBM22+gTlzfNX4YBDqvSeDlwUmzuNaeBTNyG9tg27UnmVf1ZK3miU8IyyzGYILrtYMhjViLBGSPZtyrX8nD418E7kSvAqIs=; 20:ILixicx+pTkesCCs2FWkZZfbGSxEqqh9fQ/56hcQooOmzviWlct3z/2aN0ITOBxasvfQkvAQcE93cdqdhzlXXg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
x-microsoft-antispam-prvs: <BLUPR03MB1396107A9C4204929070C3518C6B0@BLUPR03MB1396.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; 
x-forefront-prvs: 0685122203
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(377454003)(24454002)(189002)(77156002)(87936001)(68736005)(5005710100001)(106116001)(74316001)(5001770100001)(5003600100002)(62966003)(5001960100002)(189998001)(19580395003)(97736004)(86612001)(50986999)(4001540100001)(101416001)(92566002)(2950100001)(54356999)(5001860100001)(19580405001)(81156007)(5001830100001)(106356001)(8990500004)(10400500002)(77096005)(105586002)(5004730100002)(5002640100001)(64706001)(10290500002)(5007970100001)(46102003)(2656002)(99286002)(10090500001)(33656002)(76176999)(122556002)(40100003)(15975445007)(76576001)(102836002)(2900100001)(86362001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
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-originalarrivaltime: 31 Aug 2015 22:48:48.0660 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/voU8m7L_Aee96CYk-HcVoiKPcQQ>
Cc: Tokbind WG <unbearable@ietf.org>, Dirk Balfanz <balfanz@google.com>
Subject: Re: [Unbearable] Interim meeting
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 22:48:51 -0000

VGhlbiBwZXJoYXBzIHdlIHNob3VsZCBqdXN0IHNraXAgdGhlIEludGVyaW0gYW5kIGdvIHN0cmFp
Z2h0IHRvIFlva29oYW1hPw0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0Bp
ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogTW9uZGF5LCBBdWd1c3Qg
MzEsIDIwMTUgMzoxNCBQTQ0KVG86IExlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+DQpDYzog
VG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47IERpcmsgQmFsZmFueiA8YmFsZmFuekBn
b29nbGUuY29tPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBJbnRlcmltIG1lZXRpbmcNCg0K
QXQgdGhpcyBwb2ludCBJIGRvbuKAmXQgZXhwZWN0IHRvIGJlIGluIE5vcnRoIEFtZXJpY2EgYmVm
b3JlIHRoZSB3ZWVrIGltbWVkaWF0ZWx5IHByZWNlZGluZyBZb2tvaGFtYSBub3cuDQoNCkpvaG4g
Qi4NCg0KPiBPbiBBdWcgMzEsIDIwMTUsIGF0IDU6MDUgUE0sIExlaWYgSm9oYW5zc29uIDxsZWlm
akBtbnQuc2U+IHdyb3RlOg0KPiANCj4gDQo+IA0KPj4gMzEgYXVnIDIwMTUga2wuIDIxOjU0IHNr
cmV2IERpcmsgQmFsZmFueiA8YmFsZmFuekBnb29nbGUuY29tPjoNCj4+IA0KPj4gSGkgdG9rZW4g
YmluZGVycywgIA0KPj4gDQo+PiB3aGVyZSBhcmUgd2UgYXQgd2l0aCBzY2hlZHVsaW5nIGFuIGlu
dGVyaW0gbWVldGluZyBiZWZvcmUgWW9rb2hhbWE/DQo+PiANCj4gDQo+IEkgaGF2ZW4ndCBzZWVu
IGFueXRoaW5nIGNsb3NlIHRvIGNvbnNlbnN1cyB1bmZvcnR1bmF0ZWx5Lg0KPiANCj4+IERpcmsu
DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+PiBVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KPj4gVW5iZWFyYWJsZUBpZXRmLm9yZw0KPj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQo+IA0KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBVbmJlYXJh
YmxlIG1haWxpbmcgbGlzdA0KPiBVbmJlYXJhYmxlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZQ0KDQo=


From nobody Mon Aug 31 19:39:03 2015
Return-Path: <nico@cryptonector.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2A61B5B56 for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 19:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.743
X-Spam-Level: 
X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 k_2ITT0ui6yi for <unbearable@ietfa.amsl.com>; Mon, 31 Aug 2015 19:39:00 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9021B5931 for <unbearable@ietf.org>; Mon, 31 Aug 2015 19:39:00 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 2DD4959407C for <unbearable@ietf.org>; Mon, 31 Aug 2015 19:39:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=EkysHQYuph61vlyoXzIv 9Jl7fuY=; b=I7eLY3W/defcliMwp1M39KmdRdmj74Gn6LW7z/V6AE8nRXrOLInf NhJ9mnpuIJpWJWwMX8JdkfSfpYvebulInWRrdA9Uq6pdIHrmorf1N486T4pIjzCo GP6atbkhQM01TWo7jjbIXta32AC2elACY5EopWWma9AF3RHz0kXEqxk=
Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 1BD0159405E for <unbearable@ietf.org>; Mon, 31 Aug 2015 19:39:00 -0700 (PDT)
Received: by qkcj187 with SMTP id j187so27614569qkc.2 for <unbearable@ietf.org>; Mon, 31 Aug 2015 19:38:59 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.129.59.9 with SMTP id i9mr24150516ywa.100.1441075139660; Mon, 31 Aug 2015 19:38:59 -0700 (PDT)
Received: by 10.129.109.88 with HTTP; Mon, 31 Aug 2015 19:38:59 -0700 (PDT)
In-Reply-To: <CAH9QtQF6FcpY3+yQgnmWyLwDnyeBoBStsk2WWy7g4BQKjnJ1wQ@mail.gmail.com>
References: <CAH9QtQF6FcpY3+yQgnmWyLwDnyeBoBStsk2WWy7g4BQKjnJ1wQ@mail.gmail.com>
Date: Mon, 31 Aug 2015 21:38:59 -0500
Message-ID: <CAK3OfOjxvLjc7x0kvWqKodru5hGuR0iwW2e90guVnK2GGSbk_Q@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Bill Cox <waywardgeek@google.com>
Content-Type: multipart/alternative; boundary=001a114325bccb5a5e051ea673ff
Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/IeGoFSTAVPjFt_XER4_-XUyB518>
Cc: "unbearable@ietf.org" <unbearable@ietf.org>
Subject: Re: [Unbearable] TLSUnique is only 96 bits. Is OK?
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2015 02:39:01 -0000

--001a114325bccb5a5e051ea673ff
Content-Type: text/plain; charset=UTF-8

On Monday, August 31, 2015, Bill Cox <waywardgeek@google.com> wrote:
> [...]

The use cases envisioned in RFC5056 are somewhat limited.  Uses of channel
bindings in new ways require additional analysis.  I'll have to refresh my
memory as to the token binding use...  But yes, if the threat model allows
the attacker to know the change binding and to attempt many connections
then yes, 96 bits behind to look short.

Nico
--

--001a114325bccb5a5e051ea673ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, August 31, 2015, Bill Cox &lt;<a href=3D"mailto:waywardgeek@goog=
le.com">waywardgeek@google.com</a>&gt; wrote:<div>&gt; [...]<br><div><br></=
div><div>The use cases envisioned in RFC5056 are somewhat limited.=C2=A0 Us=
es of channel bindings in new ways require=C2=A0additional analysis.=C2=A0 =
I&#39;ll have to refresh my memory as to the token binding use...=C2=A0 But=
 yes, if=C2=A0the threat model allows the attacker to know the change bindi=
ng and to attempt many connections then yes, 96 bits behind to look short.<=
span></span></div><div><br></div><div>Nico</div><div>--=C2=A0</div></div>

--001a114325bccb5a5e051ea673ff--