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

Leif Johansson <leifj@sunet.se> Thu, 29 June 2017 09:05 UTC

Return-Path: <leifj@sunet.se>
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 E17BF12ECCB for <unbearable@ietfa.amsl.com>; Thu, 29 Jun 2017 02:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.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 1rGmrh-d7W8f for <unbearable@ietfa.amsl.com>; Thu, 29 Jun 2017 02:05:41 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 7956412ECEF for <unbearable@ietf.org>; Thu, 29 Jun 2017 02:05:34 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id l13so48951120lfl.1 for <unbearable@ietf.org>; Thu, 29 Jun 2017 02:05:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XJwQiYKnatnzzxkBQV+9HxeK/obAFQp76i9wJOcisO8=; b=wOsz2VPdrdhlONpC9mFnuJkezQ+F57yGNFhdpsa1hmb1zsJgjU/bL1deqAC0HrF+5k RmDqI5/t1QIEJkvnlfiwDsxQ5jRqq8clMzTxE4fD1HMCqNqqgZ6Buf++9v2BpRjVzPq8 AlRwU38JA/ZxIaczboowHpbIpC73n95vWOTtFreyWr1TBYSFQrihhmS52jFQCTgmLWo6 WveRhQQdO81U2UbkFgfo2p3N4JalWKFV7BPNji427qWl9BX4aNbkHv950d6j9mepKzx/ pCl+09ap8q33nmWLiCNnSoviIKGcsQALyx9CgGQBNQiMa6KCds2B6fIjhtmRbUJbIZzh E4Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XJwQiYKnatnzzxkBQV+9HxeK/obAFQp76i9wJOcisO8=; b=KLUjcrTMf44HKbL4daG/z3QPovw5gRA9M7OkxykgM2r059UmhO0KXlcj1YPgy4TLTZ O2UDbWfdsPCNZWvFZ/H1c/0gzjBtv3QLsoPCjXBW6prNGEg8QFtYFkBcOHHI35haYTPC SInNKXpeLKTrQt46puQWYTpq+wXecKyNAHVKDqN+Sf1rm+uay3JrxjMCYoBfN4nQwYsQ HGIPramULSnA+LOQFdi6YqhsoWtnC+rv6FNuYJf91e1E+Qu68WGKYLiOL2aZwXRbQiHN XLqypA/1h3GiVl7ZrZcduGNsR8W1dHW0o1U16BxPRDaL+jZrqY6vCaTLZGziVbO9pGdw 0TYQ==
X-Gm-Message-State: AKS2vOxc2tzXDtjffTjDFXq1360UpEmeG/0xoX4JQJvupA/fc0EAFgUe 3y+6g9rJP7oi/IEh
X-Received: by 10.25.16.224 with SMTP id 93mr5336349lfq.118.1498727132975; Thu, 29 Jun 2017 02:05:32 -0700 (PDT)
Received: from [10.0.0.129] (h-155-4-129-189.NA.cust.bahnhof.se. [155.4.129.189]) by smtp.gmail.com with ESMTPSA id r203sm1135626lff.67.2017.06.29.02.05.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 02:05:32 -0700 (PDT)
To: Benjamin Kaduk <kaduk@mit.edu>, Nick Harper <nharper@google.com>
Cc: IETF Tokbind WG <unbearable@ietf.org>, tokbind-chairs@ietf.org
References: <149868793805.5443.4284920405751222901@ietfa.amsl.com> <CACdeXiLqmdVpQryrPOBnUrbrk24Vap7QrASK-_vnwH91vwkZ3A@mail.gmail.com> <20170629024818.GI68391@kduck.kaduk.org>
From: Leif Johansson <leifj@sunet.se>
Message-ID: <9057a735-a907-d06c-327b-a959e4f554f0@sunet.se>
Date: Thu, 29 Jun 2017 11:05:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <20170629024818.GI68391@kduck.kaduk.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/wzhPONpcnVjDyoffaS1T0v9oTjg>
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 09:05:43 -0000

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.

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