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 D8139129456 for ; Mon, 27 Feb 2017 14:43:06 -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 QwRIoQweY7U6 for ; Mon, 27 Feb 2017 14:43:04 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C99129441 for ; Mon, 27 Feb 2017 14:43:04 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id p77so47192579ywg.1 for ; Mon, 27 Feb 2017 14:43:04 -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=+piIBApWgRafh2wTcbYm05HGeTYjtCVbSqy+z3YbRzY=; b=iBGXxzHMi3L9CE4RyqbHbJhZbLZh8vLu5otGHOPdFMdh0NBr9vTKnbpzWdr7vBncGS SSl0/9jTIQJ6sK+QxBfVNr1e1JaVI38CPTY88J/MSbbb8SHGj1NvYGXfgDz26+ZWEPSE 29napFeZ30FNcjfwvJkaOrgxa/G1Mph4VJT4xY/qMHNj5pwtS9YGDNpM8Fgx/ItoppXH PpPagAygBKxrr5mRlaT+qcpSfakd3L+Lkc/2Ke4xRdw9pQ9y1Ts21ICe2/7ItSrV3TIx DekJFS4plDlOTeDjHvq6QJThdX0kqD2oG8XyoRS7Rvz1+G6SHKtUaJ7CO2l55F7PWee3 jw7A== 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=+piIBApWgRafh2wTcbYm05HGeTYjtCVbSqy+z3YbRzY=; b=GDSw3nRYydafHBXdFrUHoWcDTzkv9eeSnvMGCBGiFwsspJwXiCIBfQ1dEWcwB3qJaS hKrg+1lIW3voYgm5oyKWWxdUPIy9ha1D3u5TCxI0zj6HG2j9Nd9MzANIu1fxwCczugQX r6ifAXBW3qrvVmf7z6G0Rvl1PJe5eHeSvIgE6vDq50qxA+Pa+FweNCSmH+SVAJaUBDHm 11EN47/sgpW9sy+DT4RWLz5athBfhIMSVCbGPCx/wDAc//z3VN/f2ibNUypwZpmkfE9T dfMfx0FkgmMunpaHDi7GYvw8aCqG3D9XMEPJ5eVj6VgbCTtDo+/sMNeqzz1T3QqDVxzl Tang== X-Gm-Message-State: AMke39k3JYPS1PptUdThsiJ1USJyTvQsAVoZfXnrWLiQ23rr998LDDIxl4cFcB/sZpf6HZKwVGNCucakQzNE56QG X-Received: by 10.129.173.68 with SMTP id l4mr9119438ywk.351.1488235383655; Mon, 27 Feb 2017 14:43:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.65.5 with HTTP; Mon, 27 Feb 2017 14:42:43 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Mon, 27 Feb 2017 14:42:43 -0800 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=f403045e8a56630f9705498acd8e 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: Mon, 27 Feb 2017 22:43:07 -0000 --f403045e8a56630f9705498acd8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hearing no objections to this approach, I'll update the I-D for Chicago. On Tue, Feb 7, 2017 at 4:35 PM, Nick Harper wrote: > I've been thinking about this approach for a while (and what it would tak= e > to implement it), and I've come to the conclusion that requiring switchin= g > exporters to match the switch of encryption keys is infeasible enough tha= t > 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, an= d > 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, i= t > has decided that the early exporter provides enough security to verify th= e > 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 sam= e > 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 cou= ld > contain multiple requests (e.g. in the case of HTTP/2), and the server MU= ST > 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 serv= er > 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 earl= y > 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 t= he > 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 *N= ick >> 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 use= d >> in the TokenBinding.signature for the entirety of the connection. One po= int >> 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, bu= t I >> can't remember (or figure out from the meeting notes) if the reason is j= ust >> because we prefer the crypto properties of the normal exporter, or are w= e >> 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 t= he >> client send an extension in the TokenBinding indicating that all future >> TokenBindings will use the normal exporter. This would function similar = to >> 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 ide= a >> 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 defini= ng >> application-specific messages. Another way to move the change in exporte= rs >> 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 clien= t >> switches from sending early data to sending data post-handshake. >> > > --f403045e8a56630f9705498acd8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hearing no objections to this approach, I'll update th= e I-D for Chicago.

On Tue, Feb 7, 2017 at 4:35 PM, Nick Harper <nharper@google.com> wrote:
I= 9;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 switch= ing exporters to match the switch of encryption keys is infeasible enough t= hat it won't get implemented.

Instead, I propose tha= t 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 clien= t 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 a= ccept any token bindings that use that exporter. This server rejects all ea= rly 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 re= quests 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 requ= est sent in early data, then surely that server would accept the same reque= st (with the same token binding) when sent under the forward-secure encrypt= ion keys.

A server accepting early data should acc= ept any request sent in early data. The server can't sniff the early da= ta to reject it if it contains a request it doesn't like (e.g. a POST r= equest), because the early data could contain multiple requests (e.g. in th= e case of HTTP/2), and the server MUST process the ClientHello and immediat= ely 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 exp= orter for every request, then it should accept the early exporter when it i= s 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 bindi= ngs 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 <A= ndrei.Popov@microsoft.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@ie= tf.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.



--f403045e8a56630f9705498acd8e--