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

Bill Cox <waywardgeek@google.com> Mon, 14 March 2016 04:29 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 A2D0A12D957 for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 21:29:17 -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 SySa0GoNSKEF for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 21:29:15 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 4ED6712D515 for <tls@ietf.org>; Sun, 13 Mar 2016 21:29:14 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id z76so209227332iof.3 for <tls@ietf.org>; Sun, 13 Mar 2016 21:29:14 -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=NKdiCqqoShjnqULct7NKPPKJj2SARLj/yDPTSf7aYlU=; b=h7QnvG4dq7e4o8Ex8xqTBMbfGZ23epPKsEKGZCEINwsu88qDnaPOfWObsksNdPFMRk CzAdHN4gQCjg1A/GdiujttOXvDaur+5mZlIbpNqlxXt00JELt/Q9hlvqpCXYeXI9HtYY 6GEn5D8HpGBIw8dOUs9fPQs27v9xyb61+67k2/T+T3vdu9oc6dnj+xMsEzr72EWfRKFl 3/Wfk+tBNHOMVCaiy1FJII05XdOV+qcOe7Hrajqe/nsVc/JfrYNEpLl/4G7Ip2ek0ufV 8eHbjl03vwlKWu3+f3oAUheAso7TyzEY4DcV+6YTdQXIF0j3pm/eA8By/zpLKu7dl+vk lbVA==
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=NKdiCqqoShjnqULct7NKPPKJj2SARLj/yDPTSf7aYlU=; b=D9I1N8o1w3fUi7bOMWghzR7dPGFZXoqs1fexMcMo97KlRYFHTInd6F02EgC0i7MawS 5pywZJDHhfbrjpb95uHjHg2Z5MmhzZryF+QzZLVvzvxdnJVxyK56Jy8QZW4rVjtohHm3 lbDGw7vl+wfRW7N55BRHpD8Aj4evrk7nqc1lD0paBpM4yb+4z46zXJMGLdLdE74Ih9Cd A786auXW9xv44J0a26qXk50QrcNe1Jt/K5YA6r/Kfs8cgWkKP+xjpzDta7chpDV8Hv9/ 84YdKzxeW9Wi3GuPaDjgFti5Yw6r3wz5XHNkHHMC8nwiaJ9m71WnjKp8YcQHJMdg+wzD gIkQ==
X-Gm-Message-State: AD7BkJIIpVIbzk05U07g/ly/9M1Q4B8t8KHnLKt8/pdwmowpJd4Yi11CI9dWvpDVJbpUedK8eUoSWQMXdI65JK7G
MIME-Version: 1.0
X-Received: by 10.107.8.30 with SMTP id 30mr22598518ioi.60.1457929753328; Sun, 13 Mar 2016 21:29:13 -0700 (PDT)
Received: by 10.107.183.141 with HTTP; Sun, 13 Mar 2016 21:29:13 -0700 (PDT)
In-Reply-To: <874mc9g895.fsf@setec.io>
References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <CAH9QtQFAJkq-cmY3xhvw43N4q1E7i1JJoECKLpVFb_vTRbGs4A@mail.gmail.com> <874mc9g895.fsf@setec.io>
Date: Sun, 13 Mar 2016 21:29:13 -0700
Message-ID: <CAH9QtQGJ73h_O64pKo-YukbxqkjqaQE7cus7iraFO43W+W+vhg@mail.gmail.com>
From: Bill Cox <waywardgeek@google.com>
To: Harlan Lieberman-Berg <hlieberman@setec.io>
Content-Type: multipart/alternative; boundary=001a113fb7160e4888052dfab935
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ng2zh56w5UFpKgOengQ2Z-nq7J8>
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 04:29:17 -0000

On Sun, Mar 13, 2016 at 6:26 PM, Harlan Lieberman-Berg <hlieberman@setec.io>;
wrote:

> Bill Cox <waywardgeek@google.com>; writes:
>
> More generally, I strongly believe that TLS 1.3 should not
> provide options which we think should be restricted to "admins who know
> what they're doing".  These end up hurting us down the line (cf EXPORT
> cipher suites.)
>
> I think we should ship the parts of 0-RTT that we believe are
> intrinsically safe for (the vast majority) of the internet to enable and
> use on day 1.
>

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?

This is not only fairly simple given the existing code base, but it fits
well with my personal bias towards supporting strong client authentication,
which basically got thrown under the bus in the current 0-RTT scheme.
Frankly, my current job (working on token binding) is a lot less appealing
in a world where servers cannot do proofs-of-possession with clients.  With
0-RTT cached session resumption, the TLS sequence numbers remain intact,
and we inherit the security parameters from the original connection.  The
new replay attacks go away, as do most of the "new and exciting" ways to
PWN TLS 1.3 0-RTT.

The new tickets could still be supported to enable advanced operators the
flexibility they need to implement stateless 0-RTT, but from the TLS point
of view, it would just be a 0-RTT resume using a session ID, with
additional ticket data.  If the admins at a particular company want to
stuff all the session state into the ticket and accept the security
consequences of stateless 0-RTT resumption, I think they should have the
flexibility to do that.  I _think_ the new tickets give them what they need.

This would enable the standard 0-RTT resume to be as secure as keeping the
connection alive the whole time.  I think it would stop this "race to the
bottom" problem people are worried about on this thread.

So... how dumb is this idea?

Bill