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

Nick Harper <> Tue, 11 July 2017 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC3361317DF for <>; Tue, 11 Jul 2017 14:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bxzlr0TqiY2v for <>; Tue, 11 Jul 2017 14:53:48 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1824E1270B4 for <>; Tue, 11 Jul 2017 14:53:48 -0700 (PDT)
Received: by with SMTP id z78so3135490lff.0 for <>; Tue, 11 Jul 2017 14:53:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/mk4PDqEIxlG5yfl2UIM2EdHSzrfdqJ5EIdHuXH0CXQ=; b=QpR2SmaRZnzwq2QvTQ9Zp48Z/BlEJPv+vQoL226UmbofT1AjpNguyBb2cA0PLtCwY3 9LzBcbURGpU2UMFk8g8NuPBiGSvfja7kdAocJ06xIDnPa8KmXLfNJaWL0t4yHXWsn3ku DByNC9K6vjrDpddKy+8KSYCG/YJqoVHXCcpC23FJpu7qHfWnPRDAeDB88KlVuPoKi6oc V80mSqK2k6ukg61A0UWKVunPJvIXFSz3cO3qFyH5J7esMSAZ98knZ3JnmTkKPp5L2eT6 jFEmBVWnxtvkzd4L60eI1We4zWl7bcCPFNGWtbbsvEmwUjEmjcuSB5T/UrQ545U7YtSB riiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/mk4PDqEIxlG5yfl2UIM2EdHSzrfdqJ5EIdHuXH0CXQ=; b=g30X0hVkLpMC2hWaQ4tWmnrUiUbW/8fyT9O0qYKpCyVjt0YkTrTgEs/4qfj39fYrSt pZ09DteHpp5Vub8/wnl1s6zxZR0wP6/0VbOkXRUv/rGJv6vcqFN+ljhO6SJyya5fkB5m TaHfxSs4SU8l0YtiXXDjCwRPkYcPySHhzoFVoGyM+JPYOwHWnAjl6/4fpGwsXUAm9JDc 4LkBRNOVrXolv7x4jjGjZ1mWCzMO+OSrFDkdfFUuZH6cuJvYCXoPD59V1iQlkUBIcES9 tkYIGD1IwQU0J4YOXqsYJN8bKvfA0bTKFvmNFwiNg7r2Zt7/GPLmjU2dmpEhGS6FswpR JKuA==
X-Gm-Message-State: AIVw111mDs6H+enCcVZ4G27rw0rvPEEuBONOCXkBnFak9bGm+VSfcCWO h6JnTKZH46CCApjgZ1l1bN+nBb8bMOTkPmMIwQ==
X-Received: by with SMTP id k74mr538957lfe.97.1499810026126; Tue, 11 Jul 2017 14:53:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 11 Jul 2017 14:53:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Nick Harper <>
Date: Tue, 11 Jul 2017 14:53:25 -0700
Message-ID: <>
To: Benjamin Kaduk <>
Cc: John Bradley <>, IETF Tokbind WG <>, Leif Johansson <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 11 Jul 2017 21:53:51 -0000

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.
> 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 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.