Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Bill Cox <waywardgeek@google.com> Mon, 14 March 2016 15:41 UTC

Return-Path: <waywardgeek@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60D12DC6C for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 08:41:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 yNSJvz6bJQkh for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 08:41:31 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 6BEAF12DC7E for <tls@ietf.org>; Mon, 14 Mar 2016 08:35:26 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id m184so227064279iof.1 for <tls@ietf.org>; Mon, 14 Mar 2016 08:35:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=6BGMRbJ7yimhgvZbmHDr/gixS+P/wszt83/9cF2eQmw=; b=TyH0r7JorbcZGmmdf9wnhP6ceSz33J73vWzWDLrm1yv80kThTrAotPte9W7Fmin2ZS WEgtz0G1NMkV9HqveszVg7pBCxLNG+Tv8l8vL03HIxKr2U5twE4jnNuflQYUSU51QvfL LPdH2BlEJRfikSNkdiIGkRY9M2RIYte2br+dt7N7GEThWAgX+szsW0Rlj7xjGNufk90S 0H2G3j/zuXmpNc1k7al5/P2f46xh8AmYhcTcckQrGBoK/rVnXr14fO/G3n9TcuR8ppem 22wKoGW12W3aISSrE2kh/Yzzv4HmZj7GaFQ1k0KUDge01E9zC4OxHpQkVgODIF2hkd+i TuEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6BGMRbJ7yimhgvZbmHDr/gixS+P/wszt83/9cF2eQmw=; b=mEGHcQvtrDW54W5QHGA3ZlKcelyACApumtHHzRtYv1zIepLbZ+4YK78hrxgQPVy1h5 jPLR6zJCiaFBmt+tF+YddbUwTerZV4zRYUemZgMfR1nhh9Zm4k8GJ42u1fdF9CuGvL9l ZFFoqDigFcPMowk107/oCXbpBW/BsUc4K1mhJiPkwTjRNcra7hoMB5u8RMYD75f83VT/ bs/c/wUcnSH03YSG8zG8jiuktLSUW7YnmalmFrbR/EPZnCoq85GQdvP/cqtG4pDi08aS bBp2i6cDhj9QUvKwVgTGMzHW92mSq8npmOFBOT7aSF+looDKhMhMfCgfpMzi/PiuACHC mdmA==
X-Gm-Message-State: AD7BkJJBdtPcydH6eMzuhpaQPrs3gaWRb+1wtTXjtR2D+HCG0W+MjvEBwoOKCRbbypYLO5jEdO1tb8XtMGVmleSv
MIME-Version: 1.0
X-Received: by 10.107.131.169 with SMTP id n41mr8297179ioi.132.1457969725610; Mon, 14 Mar 2016 08:35:25 -0700 (PDT)
Received: by 10.107.183.141 with HTTP; Mon, 14 Mar 2016 08:35:25 -0700 (PDT)
In-Reply-To: <CABcZeBMcL9+9im2hqLe1KHgbv+0ghrTTV=sK371sVX0ejXOyXA@mail.gmail.com>
References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <CAH9QtQFAJkq-cmY3xhvw43N4q1E7i1JJoECKLpVFb_vTRbGs4A@mail.gmail.com> <874mc9g895.fsf@setec.io> <CAH9QtQGJ73h_O64pKo-YukbxqkjqaQE7cus7iraFO43W+W+vhg@mail.gmail.com> <CABcZeBMcL9+9im2hqLe1KHgbv+0ghrTTV=sK371sVX0ejXOyXA@mail.gmail.com>
Date: Mon, 14 Mar 2016 08:35:25 -0700
Message-ID: <CAH9QtQGxVLxo8T3UjaYqUc=3fJSFCrT6PfjVtciv6Ea9xOoy3Q@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a113ebf8496ed08052e0407b6
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qRadW2BOUTe_Ngx-7ipl0pbcM4c>
Cc: Scott Schmit <i.grok@comcast.net>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2016 15:41:36 -0000

On Mon, Mar 14, 2016 at 4:39 AM, Eric Rescorla <ekr@rtfm.com>; wrote:

> This is just my opinion, not Google's.  Here is a dumb idea I just had:
>>
>> The current 0-RTT modes described in TLS 1.3 are clearly only for admins
>> who really know what they are doing.  If the current 0-RTT modes are deemed
>> to dangerous, then how about going back to session IDs, and doing 0-RTT
>> resumption from the session cache?
>>
>
> Isn't this more or less what we have been calling PSK-resumption? Can you
> explain
> the difference?
> -Ekr
>

Sometimes all you need is to rename a thing to make it acceptable to
everyone.  What should we call stateful 0-RTT resumption vs stateless 0-RTT
resumption to make the difference clear?  We have all been calling "0-RTT
resumption" the stateless version, whether DH-0RTT or PSK-resumption based
0-RTT.

Stateless PSK-resumption has all the "new and exciting" security holes.
Stateful PSK-resumption is boring, just like 1-RTT.  Stateless DH-0RTT and
PSK-resumption is well documented in the spec, but is dangerous.  Stateful
PSK-resumption is not documented in any way, and appears to have been
depreciated.  Users who want it will have to build it as a non-standard way
to use tickets, by encoding the session-ID in the ticket.  All I am
suggesting is to change the documentation so that the standard 0-RTT
resumption mode is the safe stateful version that puts the session-ID in
the ticket (and of course, drop the DH-0RTT mode).

As we all know, what matters most in security is the default mode.  I am
suggesting making the default 0-RTT resumption mode stateful, with a
documented session-ID (and let's bring back the timestamp, too, since we'll
need it).

Bill