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

Nick Harper <nharper@google.com> Thu, 29 June 2017 18:33 UTC

Return-Path: <nharper@google.com>
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 2AD77129B05 for <unbearable@ietfa.amsl.com>; Thu, 29 Jun 2017 11:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, 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 CuAk5GL2tRK6 for <unbearable@ietfa.amsl.com>; Thu, 29 Jun 2017 11:33:24 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 0A2AF126BFD for <unbearable@ietf.org>; Thu, 29 Jun 2017 11:33:24 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id b207so57779273lfg.2 for <unbearable@ietf.org>; Thu, 29 Jun 2017 11:33:23 -0700 (PDT)
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=Ua1ZkDOf29VG73xxJUxfdXSwV4etdm+e7/jy/yy1XNs=; b=joa8uG0WV1qb+wNHCvnyEe6B0aYwaXvhx/r8Mx/2V28JOEeg70tbz2ia6dosQ4zA+R ryts5MB6DgSz28iTZGdqqecGomMY7/6YC84dRkfJ70aBe2cUBlxl49Qj1TzLk3zcRlO6 ZOG0/iZ6ANJwSGnfOUl1tBDVDR8TnRwU7G0/pF86CQWCl8Ei9whDbmOlbAy9BhtRCQ/o k3Ay5nwFYWNWZjiVNuhR/HWHXw3e5yWk/fE9ZPdzelLQpEURX0i4D56MoS3+JtpRXwiE yYcI56fKZ1PJ67O/DbDasgz6Ls2YoMIG5se0iiHZ+Vbyvu7TlNkAOmTZ1wN9Ym/IDRjd xxMw==
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=Ua1ZkDOf29VG73xxJUxfdXSwV4etdm+e7/jy/yy1XNs=; b=JhlJur4nNzZb+SyyjUGhVFKFARzALAl5QAW03SuZmr5Le4z2vqMr9Wop18EmnPJ99C 0B+zbxNdTVQLJnTacWf4XHlII8g9HXYCq1j0P8UTkiFrijOvPDpYYY1m7KloYI/HalRc xADLmXWNG0PBsG3yVuxtetgHbyuXLYgr5hbDMcUv+cEcanl7jewvN/YrDcFmO7TeXMCr IU9pDi2o7I04CYyAAjYaiVg5Uys0yc+Sg1OvxY/J2g9rY2XPAuaTti0nd5AEd5L2aIQM r6aoc3+M3K8MHbrypwMgCKvXpdW+VAe4kcUSxoL960iJI0sme2ISxdV17dqHp7Ism845 ubEg==
X-Gm-Message-State: AKS2vOwAUUxod/r2JzIUrraej/kDyBmjMI+k/Y0WjGzaI/0HhOSzgR2C Vp+qnXfnX5dVJlqilfISU33GeJCdh70wjFqwUw==
X-Received: by 10.46.71.21 with SMTP id u21mr2888245lja.115.1498761202063; Thu, 29 Jun 2017 11:33:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.44.73 with HTTP; Thu, 29 Jun 2017 11:33:01 -0700 (PDT)
In-Reply-To: <9057a735-a907-d06c-327b-a959e4f554f0@sunet.se>
References: <149868793805.5443.4284920405751222901@ietfa.amsl.com> <CACdeXiLqmdVpQryrPOBnUrbrk24Vap7QrASK-_vnwH91vwkZ3A@mail.gmail.com> <20170629024818.GI68391@kduck.kaduk.org> <9057a735-a907-d06c-327b-a959e4f554f0@sunet.se>
From: Nick Harper <nharper@google.com>
Date: Thu, 29 Jun 2017 11:33:01 -0700
Message-ID: <CACdeXiKOGptZ2WSZ_nVo-LmS5W0kqUszx_BpOcOWnfV05KO7mQ@mail.gmail.com>
To: Leif Johansson <leifj@sunet.se>
Cc: Benjamin Kaduk <kaduk@mit.edu>, IETF Tokbind WG <unbearable@ietf.org>, tokbind-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/4s80fYwG2hSnwe6PxnYcWDlLNGo>
Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt
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, 29 Jun 2017 18:33:26 -0000

On Thu, Jun 29, 2017 at 2:05 AM, Leif Johansson <leifj@sunet.se> wrote:
> On 2017-06-29 04:48, Benjamin Kaduk wrote:
>> On Wed, Jun 28, 2017 at 03:25:13PM -0700, Nick Harper wrote:
>>> Here's a summary of the changes since the last draft:
>>>
>>> - If TB is accepted in 0-RTT data, keep using the early exporter for
>>> the whole connection. There was some discussion on this in Chicago,
>>> with more on the mailing list. Chairs, can you confirm whether we
>>> reached consensus on the mailing list or whether we should take a hum
>>> in Prague?
>>
>> I am a WG chair, but not a tokbind chair, but that question does not
>> seem to make sense.  Consensus must be reached (or confirmed) on the
>> mailing list, so deciding there wasn't enough feedback on the list and
>> going to an in-room hum seems backwards, procedurally.
>
> Judging consensus is sometimes tricky. I think what Nick meant was that
> we may want to do a hum in Prague /in addition to/ seeking confirmation
> on the list.

It is unclear to me whether consensus was reached (hence deferring to
the chairs on that judgement). If we don't have consensus, I'm fine
continuing the discussion on list and in Prague. Let me check that I
understand the process properly: first, discuss (on list and possibly
in person), then if the discussion sounds like it's reached a
consensus, optionally hum in person, and then confirm consensus on the
list. Does that sound about right?
>
>>
>>> - 0-RTT TB cannot be used with externally provisioned PSKs or with a
>>> PSK-only key exchange mode
>>>
>>> - A new TLS extension is used for negotiating and indicating use of 0-RTT TB
>>>
>>> - The replay indication TLS extension has been removed
>>
>> Some discussion on the httpbis list brought up that this document should
>> mandate that 0-RTT token binding is only used in conjunction with
>> a TLS stack that provides strong anti-replay protections (i.e., zero
>> additional replays possible and one retransmission via DKG attack).  In other
>> words, the time-based scheme of (draft-02) section 6.4 should be removed,
>> and perhaps 6.3.1 reworded somewhat.

I read over the "New Version Notification for
draft-thomson-http-replay-00.txt" thread on the httpbis list. My
understanding of the issue raised on that list is simply that there
are attacks on 0-RTT Token Binding if there isn't a strict global
anti-replay mechanism. There are still attacks possible on 0-RTT Token
Binding even if there is a strict global anti-replay mechanism. I need
to consider what additional attacks are possible without such a
mechanism, and if any of those attacks require less privileges than
the attacks possible with the mechanism.
>>
>> (It also brought up multiple peoples' sentiments that 0-RTT token binding
>> is a bad idea in general, but this may not be procedurally the right time
>> to have that discussion.)
>>
>> -Ben
>>
>
I'm aware that multiple people think that 0-RTT token binding is a bad
idea in general. So far, the impression I've gotten of this sentiment
is "0-RTT Token Binding is not something I have any interest in
implementing". If the sentiment is closer to "0-RTT Token Binding is
such a horrible thing that no one should be implementing it", then
maybe we should discuss that sooner.