From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Nick Harper <nharper@google.com>, Benjamin Kaduk <kaduk@mit.edu>
CC: IETF Tokbind WG <unbearable@ietf.org>
Thread-Topic: [Unbearable] Switching exporters for 0-RTT Token Binding
Thread-Index: AQHSuJKlo0yoEMvGZUCTm+Pgzz+4KKHNhPAAgAxI7ICAAAxqsA==
Date: Thu, 27 Apr 2017 22:46:18 +0000
Message-ID: <SN1PR21MB0096D78DF3E9C07B23DC76078C100@SN1PR21MB0096.namprd21.prod.outlook.com>
References: <CACdeXiLF3G8tBO5z5L2mfe5N-kYMv_4TNFS2_0YdecquMM_kuw@mail.gmail.com>
 <20170420020846.GY30306@kduck.kaduk.org>
 <CACdeXiLPb-QwLhG89ahV_q8q3n16jA+WEnsTzKTAyMtYcVF4Pw@mail.gmail.com>
In-Reply-To: <CACdeXiLPb-QwLhG89ahV_q8q3n16jA+WEnsTzKTAyMtYcVF4Pw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 22:46:19.0338 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR21MB0095
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/nmsGGC2raLUZa2RAHMEnv--AhiU>
Subject: Re: [Unbearable] Switching exporters for 0-RTT Token Binding
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than
 bearer tokens \(e.g. HTTP cookies,
 OAuth tokens etc.\) for web applications. The specific goal is chartering a WG
 focused on preventing security token export and replay attacks.\""
 <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>,
 <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>,
 <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2017 22:48:51 -0000

If one is willing to do TB without POP, then one will probably appreciate a=
 simpler way to do this, with fewer moving parts and less room for interop =
issues. (IMHO, the value of TB without POP approaches zero, but that's a se=
parate discussion.)

The extra complexity of upgrading to secure TB after a bound token and asso=
ciated application message(s) have been accepted and processed does not inc=
rease security in the common use-cases that I can think of.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Nick Har=
per
Sent: Thursday, April 27, 2017 2:45 PM
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] Switching exporters for 0-RTT Token Binding

On Wed, Apr 19, 2017 at 7:08 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> On Tue, Apr 18, 2017 at 03:24:40PM -0700, Nick Harper wrote:
>> One of the issues raised in Chicago around 0-RTT Token Binding is=20
>> whether or not to switch from the 0-RTT exporter to the normal=20
>> exporter, and I'd like to get some feedback from the Working Group on=20
>> this.
>>
>> The two options I'm considering are as follows:
>> 1) Always use the 0-RTT exporter on connections where 0-RTT data is acce=
pted.
>> 2) Use the 0-RTT exporter for Token Binding messages sent in 0-RTT.
>> The client switches to using the normal exporter soon after the=20
>> handshake finishes, but it may send some Token Binding messages=20
>> post-handshake using the 0-RTT exporter.
>> In both cases, if the server rejects 0-RTT data, the client uses the=20
>> normal exporter (i.e. the client behaves the same as in TBPROTO).
>
> To make the obligatory statement of hopefully obvious facts, 0-RTT=20
> data MUST NOT be used absent a profile that defines its use.
> Presumably the situation of most interest here is HTTP right now, and=20
> many people would presume that the HTTP profile for early data will=20
> say "just concatenate the two streams", but those are just=20
> presumptions.  Perhaps some other profile would be appropriate for=20
> non-HTTP cases, though with no concrete proposal it hardly seems worth=20
> time to think about other than to note that whatever decision may be=20
> reached here might be limited to HTTP in its applicability.
>
> If one presupposes that the profile for the use of 0-RTT is=20
> "concatenate the streams", then the arguments against (1) are weakened=20
> (though not entirely removed).  But I'm not sure what level of=20
> consensus there is for such a (pre)supposition.

I have definitely been assuming an application profile of HTTP that concate=
nates the streams, and the use-case in mind for 0-RTT Token Binding is with=
 HTTP.
>
> Having not fully thought through the matter, I still lean towards (2),=20
> with the justification that token binding can be thought of as an=20
> attempt to prove live possession of a key [associated to a token] on a=20
> connection where that token is used.  The 0-RTT exporter does not have=20
> a server contribution, so it's hard to really prove liveness of=20
> possession using just it.  I acknowledge that there is engineering=20
> work remainng to be done in making (2) practical/usable, and am not=20
> really in a position to contribute much to that work, but that's my=20
> current thinking on the matter.
>
> -Ben

I have similar reservations for (1) in that it doesn't really prove livenes=
s of possession, but (2) only has this liveness of possession at some point=
s in the protocol (i.e. after it has switched exporters).
If a server is doing 0-RTT Token Binding, then it doesn't need the stronger=
 exporter for all requests - the weaker exporter is fine for some. I don't =
see a reason to upgrade partway through to the stronger exporter just becau=
se it is stronger. However, if there are use cases for accepting the weaker=
 exporter at the beginning of a connection but then requiring the stronger =
exporter later in the connection, then (2) sounds like a good idea. (Prefer=
ring the stronger exporter isn't enough for this use case - it would need t=
o require it, and absent option (2) the implementer of this use case would =
put the requests needing the stronger exporter on a separate, non-0-RTT, co=
nnection.)

For those considering implementing 0-RTT Token Binding, do you have any suc=
h use cases in mind or is option (1) good?

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf=
.org%2Fmailman%2Flistinfo%2Funbearable&data=3D02%7C01%7CAndrei.Popov%40micr=
osoft.com%7Cc470223592b2491dd71c08d48db72ee5%7C72f988bf86f141af91ab2d7cd011=
db47%7C1%7C0%7C636289265288924355&sdata=3DH98Owo1uWbXf11VGgzmau3XH3aGzYuNA2=
7pOOaJtxBc%3D&reserved=3D0