Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14FD12956B for ; Tue, 7 Feb 2017 16:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3oXaPzT4JrD for ; Tue, 7 Feb 2017 16:36:18 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA75A1293F5 for ; Tue, 7 Feb 2017 16:36:17 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id w75so77289679ywg.1 for ; Tue, 07 Feb 2017 16:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ROnTCNZxRSsu8QcZAzohnH7mgPohG6oU3P0TdgD40C4=; b=eLAmPyUMufaFB8Fd5GaAiT/zaFPckLN9lSG0zY7gqNtVaTIUU2QNL2GYuquMQ5F6hp 6074vFnLeFz8M6E4DiVtX0MbNXwvvCNWJq5Bj+lDuC8Ryu0kPWqOGEqk/ez0JJH1KKTc kIsmcRq1LEdtEcoEFb+ZOvLNSWasY+AhgTHaJ7pYgm2B8m2qdHEeZKhFozihm79+9FHl ckEbY6sW34o3zEVXAFxEhBTF8gusT0C64XAvL3b93AgL7cAk/ll7ndZyyLY1914808Z0 Q9GpXOx7pRU0GQ4FG5E+xcd2bsUA3EdrrZ3EAi+UcldJc8oQILCk2pzM45NiPpINFuch YQJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ROnTCNZxRSsu8QcZAzohnH7mgPohG6oU3P0TdgD40C4=; b=PZHVKlpgCdtYm4CKngbYWn7y3AbwMPge8WDw/Qe3VB5QsjU6k6tQH/RCDJcMfs63LF 4iGklYvf9aL/Mu+e7Cvy/JklkeoNgArRMOu79OfTfk+ImDpnshmTu913VcrKaxSaH9kX r7ZbqQ27AHT2o9pBqqgZL+ApY55q5awo6GKZ3XwNT1z8mIh7Y0Wngt8QkNSw0O0nwwQT 9BVt7rBubNinqoi5aTfV1C/g5pezo/sIx+4KBK4KZIaTp9k7dfYiF6FzpPQ1ZpObHEs3 mFmgT82mYtJvNyfEAbUW4AtoaCXlsrun3jli2HlCmGvPCE8HhEz/O09hjkCGSsW/t3/O QxYw== X-Gm-Message-State: AMke39maBjzi/QeN5mOzllzAKpFSm01e/csW2Gej9qFYb90+tN39NO1/gwmVNau1TRk3WNBHbAA4U3ifGzltq6XE X-Received: by 10.129.130.3 with SMTP id s3mr12970048ywf.179.1486514177067; Tue, 07 Feb 2017 16:36:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.161.87 with HTTP; Tue, 7 Feb 2017 16:35:56 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Tue, 7 Feb 2017 16:35:56 -0800 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c07a5ba7aad0e0547fa0d82 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 00:36:21 -0000 --94eb2c07a5ba7aad0e0547fa0d82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've been thinking about this approach for a while (and what it would take to implement it), and I've come to the conclusion that requiring switching exporters to match the switch of encryption keys is infeasible enough that it won't get implemented. Instead, I propose that if a server accepts the client's 0-RTT data, then the client uses the 0-RTT exporter for the entirety of the connection, and otherwise the client uses the exporter as already specified in TBPROTO. This still has decent security properties. First, consider a server that is uncomfortable enough with the early exporter that it does not want to accept any token bindings that use that exporter. This server rejects all early data on connections where the client tries to negotiate token binding, and falls back on using the existing exporter in TBPROTO with no early data. Next, consider a server that does accept some requests sent in early data with a token binding that used the early exporter (the only choice in a request in early data). For this request, since the server accepted it, it has decided that the early exporter provides enough security to verify the binding (otherwise this server would be in the above category). If the early exporter was good enough for this server on a request sent in early data, then surely that server would accept the same request (with the same token binding) when sent under the forward-secure encryption keys. A server accepting early data should accept any request sent in early data. The server can't sniff the early data to reject it if it contains a request it doesn't like (e.g. a POST request), because the early data could contain multiple requests (e.g. in the case of HTTP/2), and the server MUST process the ClientHello and immediately send the ServerHello - it cannot wait to process all of the client's early data. It follows that if a server will accept a token-bound request in early data, then it will accept any token-bound request in early data, meaning that the server finds the early exporter used for the token binding acceptable no matter the request. If the server is fine with the early exporter for every request, then it should accept the early exporter when it is used for requests not sent in early data as well. In other words, if the server does not want to allow the early exporter to be used for token bindings on some requests, then the only logical thing for that server to do is always reject early data if token binding is negotiated. On Fri, Jan 13, 2017 at 2:18 PM, Andrei Popov wrote: > =C3=98 Another way to move the change in exporters out of the client's > control would be to do it at a time that is implicit in the protocol. An > obvious choice would be switch exporters when the client switches from > sending early data to sending data post-handshake. > > I think this type of approach is better. > > > > Cheers, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Ni= ck > Harper > *Sent:* Friday, January 13, 2017 12:30 PM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] 0-RTT Token Binding: When to switch exporters? > > > > The current tokbind 0-RTT draft has the TLS 1.3 early exporter value used > in the TokenBinding.signature for the entirety of the connection. One poi= nt > of discussion that came up in Seoul was that we shouldn't use the 0-RTT > exporter for too long. I agree that we shouldn't use it for too long, but= I > can't remember (or figure out from the meeting notes) if the reason is ju= st > because we prefer the crypto properties of the normal exporter, or are we > also trying to prevent an attacker from being able to use the 0-RTT > exporter indefinitely? > > > > For the first case, the switch from the 0-RTT exporter to the normal > exporter can be client-initiated. One possible design would be to have th= e > client send an extension in the TokenBinding indicating that all future > TokenBindings will use the normal exporter. This would function similar t= o > the ratcheting idea (from section 4.1 of the I-D), but the ratchet doesn'= t > take effect until this indicator extension is sent (before it's sent the > server would accept both exporters). This would likely be done in > combination with the idea of defining new key types to indicate that the > 0-RTT exporter is in use so the server doesn't do trial verification. > > > > If we want to move the switch from 0-RTT exporter to normal exporter out > of the client's control (so that an attacker can't keep using the 0-RTT > exporter indefinitely), a different solution is needed. One possible idea > is to have the server send a message that conceptually means "all future > TokenBindings must not use the 0-RTT exporter". Right now, Token Binding > doesn't have any server-to-client messages, so this would require definin= g > application-specific messages. Another way to move the change in exporter= s > out of the client's control would be to do it at a time that is implicit = in > the protocol. An obvious choice would be switch exporters when the client > switches from sending early data to sending data post-handshake. > --94eb2c07a5ba7aad0e0547fa0d82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've been thinking about this approach for a while (an= d what it would take to implement it), and I've come to the conclusion = that requiring switching exporters to match the switch of encryption keys i= s infeasible enough that it won't get implemented.

I= nstead, I propose that if a server accepts the client's 0-RTT data, the= n the client uses the 0-RTT exporter for the entirety of the connection, an= d otherwise the client uses the exporter as already specified in TBPROTO. T= his still has decent security properties.

First, c= onsider a server that is uncomfortable enough with the early exporter that = it does not want to accept any token bindings that use that exporter. This = server rejects all early data on connections where the client tries to nego= tiate token binding, and falls back on using the existing exporter in TBPRO= TO with no early data.

Next, consider a server tha= t does accept some requests sent in early data with a token binding that us= ed the early exporter (the only choice in a request in early data). For thi= s request, since the server accepted it, it has decided that the early expo= rter provides enough security to verify the binding (otherwise this server = would be in the above category). If the early exporter was good enough for = this server on a request sent in early data, then surely that server would = accept the same request (with the same token binding) when sent under the f= orward-secure encryption keys.

A server accepting = early data should accept any request sent in early data. The server can'= ;t sniff the early data to reject it if it contains a request it doesn'= t like (e.g. a POST request), because the early data could contain multiple= requests (e.g. in the case of HTTP/2), and the server MUST process the Cli= entHello and immediately send the ServerHello - it cannot wait to process a= ll of the client's early data. It follows that if a server will accept = a token-bound request in early data, then it will accept any token-bound re= quest in early data, meaning that the server finds the early exporter used = for the token binding acceptable no matter the request. If the server is fi= ne with the early exporter for every request, then it should accept the ear= ly exporter when it is used for requests not sent in early data as well. In= other words, if the server does not want to allow the early exporter to be= used for token bindings on some requests, then the only logical thing for = that server to do is always reject early data if token binding is negotiate= d.

On = Fri, Jan 13, 2017 at 2:18 PM, Andrei Popov <Andrei.Popov@microsof= t.com> wrote:

=C3=98=C2=A0 Another way to move the change in exporters out= of the client's control would be to do it at a time that is implicit i= n the protocol. An obvious choice would be switch exporters when the client= switches from sending early data to sending data post-handshake.

I think this type of approach is better.<= /u>

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Nick Harper
Sent: Friday, January 13, 2017 12:30 PM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] 0-RTT Token Binding: When to switch exporters?=

=C2=A0

The current tokbind 0-RTT draft has the TLS 1.3 earl= y exporter value used in the TokenBinding.signature for the entirety of the= connection. One point of discussion that came up in Seoul was that we shou= ldn't use the 0-RTT exporter for too long. I agree that we shouldn't use it for too long, but I can't r= emember (or figure out from the meeting notes) if the reason is just becaus= e we prefer the crypto properties of the normal exporter, or are we also tr= ying to prevent an attacker from being able to use the 0-RTT exporter indefinitely?

=C2=A0

For the first case, the switch from the 0-RTT export= er to the normal exporter can be client-initiated. One possible design woul= d be to have the client send an extension in the TokenBinding indicating th= at all future TokenBindings will use the normal exporter. This would function similar to the ratcheting idea (f= rom section 4.1 of the I-D), but the ratchet doesn't take effect until = this indicator extension is sent (before it's sent the server would acc= ept both exporters). This would likely be done in combination with the idea of defining new key types to indicate th= at the 0-RTT exporter is in use so the server doesn't do trial verifica= tion.

=C2=A0

If we want to move the switch from 0-RTT exporter to= normal exporter out of the client's control (so that an attacker can&#= 39;t keep using the 0-RTT exporter indefinitely), a different solution is n= eeded. One possible idea is to have the server send a message that conceptually means "all future TokenBindings must= not use the 0-RTT exporter". Right now, Token Binding doesn't hav= e any server-to-client messages, so this would require defining application= -specific messages. Another way to move the change in exporters out of the client's control would be to do it at a time t= hat is implicit in the protocol. An obvious choice would be switch exporter= s when the client switches from sending early data to sending data post-han= dshake.


--94eb2c07a5ba7aad0e0547fa0d82--