Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt

Benjamin Kaduk <> Wed, 12 July 2017 00:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9724513181D; Tue, 11 Jul 2017 17:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3oAQ6F1K8UZo; Tue, 11 Jul 2017 17:23:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AABB813180F; Tue, 11 Jul 2017 17:23:58 -0700 (PDT)
X-AuditID: 1209190f-2e3ff70000003f98-7d-59656c1c5f2e
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 55.78.16280.C1C65695; Tue, 11 Jul 2017 20:23:57 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id v6C0NtCH032505; Tue, 11 Jul 2017 20:23:56 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v6C0Np19022195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jul 2017 20:23:53 -0400
Date: Tue, 11 Jul 2017 19:23:51 -0500
From: Benjamin Kaduk <>
To: Nick Harper <>
Cc: John Bradley <>, IETF Tokbind WG <>, Leif Johansson <>, "" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1pXNSY002Pie1WJB71Zmi/4d+xgt ls+fz2Zx7vFCJovVd/+yObB6LNhU6rFkyU8mj72b+tg9bt/eyBLAEsVlk5Kak1mWWqRvl8CV 0dPlU3BSvmLq6l7mBsYuyS5GTg4JAROJeyd3snQxcnEICSxmkvg0Zy0rhLORUeLqgmYo5yqT xKJ77ewgLSwCqhIvd8xiBrHZBFQkGrovg9kiQPb8q9fBGpgFNjNKnJr3ghUkISzgJTFj0RMW EJsXaN++V/1Q+5axSDyYsYoNIiEocXImRBGzgJbEjX8vmboYOYBsaYnl/zhATE6BQIk53+tA KkQFlCX+Hr7HMoFRYBaS5llImmchNC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mi l5pSuokRHNaS/DsY5zR4H2IU4GBU4uFtuJASKcSaWFZcmXuIUZKDSUmUNygWKMSXlJ9SmZFY nBFfVJqTWnyIUYKDWUmEN/YBUI43JbGyKrUoHyYlzcGiJM4rrtEYISSQnliSmp2aWpBaBJOV 4eBQkuA9n5UaKSRYlJqeWpGWmVOCkGbi4AQZzgM03DsaqIa3uCAxtzgzHSJ/ilFRSpz3ViZQ QgAkkVGaB9cLSjsS2ftrXjGKA70izMsNsoIHmLLgul8BDWYCGrwmG+Tq4pJEhJRUAyMPV+TF C0s0w97OZLx+7NmqjVyTSnwvK66u3hno4/ZcSJ97+6fS9+tXGVy7eHRH2sN3+Q4Tj/ExvqgT TbBcvMHcZJ6baWDUVwW9lysZeGUuLkn8mbnFIf/7rQSPVtbLBVW8pb+nd7ypK1vx99EjxhPN mkXq4ezCJ9I6hf5FvXJ11WDZ23VrboMSS3FGoqEWc1FxIgDv4PrLFgMAAA==
Archived-At: <>
Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Jul 2017 00:24:01 -0000

On Tue, Jul 11, 2017 at 02:53:25PM -0700, Nick Harper wrote:
> On Sat, Jul 1, 2017 at 9:53 AM, Benjamin Kaduk <> wrote:
> > Hi Nick,
> >
> > On Thu, Jun 29, 2017 at 08:16:33PM +0000, Andrei Popov wrote:
> >> There is often a tradeoff between security and performance; some servers may choose 0-RTT based on their business requirements, and others may choose TB. I do not think that it is necessary to reconcile TB and 0-RTT (although it would have been awesome if we could). From my perspective, it is more important to keep TB secure than to make it work with 0-RTT: replayable TB would be a waste of CPU cycles.
> >
> > I agree with Andrei that there is a tradeoff and keeping TB secure is important.
> I agree that there are trade-offs to be made between security and
> performance, and I agree that some clients and servers when choosing
> to do Token Binding will want it to be as secure as possible. I'm a
> little confused by what you mean when you say "keeping TB secure is
> important". 0-RTT TB does not change the security properties of the
> existing TB in TBNEGO/TBPROTO.

My interpretation was (to very very roughly paraphrase) that this is a
question of branding -- that is, when we say that something is secured
with Token Binding, we want that to mean the high level of security.

> > For a long time I have been generally opposed to 0-RTT TB at a gut level,
> > but I may have recently gained an intuition for how to articulate my
> > concerns in a more concrete fashion.  That is, as a server, I am interested
> > in TB providing binding to the channel between the client and myself.
> > But, since 0-RTT does not include any server contributions, in some sense
> > 0-RTT TB is only binding to "half of the channel" (the client's contribution),
> > and even though it is/ends up being bound to my (as the server) connection
> > to the client, the same octets on the wire could also end up being bound
> > to a different connection emanating from the client.  So I as a server
> > have a weaker security guarantee, and I would prefer to retain the stronger
> > security property.
> >
> > -Ben
> There is a server contribution to the exporter value signed in 0-RTT
> TB - the server contribution is the PSK from the NewSessionTicket
> issued on the original connection. 0-RTT TB is just like using client
> certificates with TLS resumption: with client certificates there is
> only a signature on the original connection, and the client auth state
> is carried over from the previous connection on resumption. With 0-RTT
> TB, there is a signature on both the original and resumed connection,
> but this signature just proves that the private key was used at the
> beginning of the original connection (since the resumed connection's
> signature could hypothetically be computed then as well). In both
> cases - client certs and 0-RTT TB - we have proof of possession of the
> private key at the beginning of the original connection, but not at
> the beginning of the resumed connection. I think having comparable
> security to client certificates is a decent bar that 0-RTT TB meets.

I agree about the transitive contribution.  My intent was to indicate
a desire for a current/fresh server contribution that is specific to the
current connection.

I'm also not sure that using client certificates as a comparison is the
right place to set the bar.

> I know that 1-RTT TB meets a higher security bar, and I don't expect
> to convince those wanting to trade performance for this additional
> security that they should implement 0-RTT TB. I'm trying to make the
> case that 0-RTT TB is not a waste of resources and that it provides a
> decent level of security for those wishing to use it.

I mean, you should probably continue to make your case.  At some point
the WG will have to decide whether it is "good enough" to merit the
stamp of approval as an okay thing for consumers of TB to be able to
choose to use (or not use).