Re: [TLS] Simple, secure 0-RTT for the masses

Colm MacCárthaigh <colm@allcosts.net> Tue, 15 March 2016 20:22 UTC

Return-Path: <colm@allcosts.net>
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 54D1212D774 for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 13:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_RED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.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 rxQDj26XPnUS for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 13:22:00 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 76DC312D76C for <TLS@ietf.org>; Tue, 15 Mar 2016 13:22:00 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id g127so36078342ywf.2 for <TLS@ietf.org>; Tue, 15 Mar 2016 13:22:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=VhNYqyzzdZSz+xYNeNW3AXrHvPnsU1DzO0FzScaavLs=; b=myuVIWyG68hhjilLhDql/7BJEn3fOkmOhsJszAFNq4h7B1wkPk7B6/lsYgZlATYXzJ VzWy+YmNjljaKn2dyttldvanH0qdLOYM/B3d2QnQ1ikF6mmRrXqLglQOGxJNhg6R1QvB SYZov2JImxSSnBfWackCAhxte9JnEzDpQJLXedLwd/oktwH8D750fdhh+F2dzcjnZICU wa1X1CYPoUqew4llYyB5yApvaTXHLirI883JhWIXPNLHodwSq+WAmxnAZNnvrUfEFtAy mIewX8MMGfVYMny6F+h9WZqoFwaqBhHxKti2t8EdH0oHxPJ/QJSFktl+4zJdYeTFx7kO JtXA==
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=VhNYqyzzdZSz+xYNeNW3AXrHvPnsU1DzO0FzScaavLs=; b=muvQ19th+VxQGjiWlnurax5xPiGArIsFLAw1Ie76kYGIq14yUjtx4NWYabxFc7b6FB k1sq4IVG8nrijGkPonCQ4cUelAHZLmt2e2s7YPS+zaGO1mmvhH6lw4tbW0Lyh3FyW5F8 uxiN7/v4TER1+Bp21E49uZJY8hRIImTg6HPwAdnjM1r4rYYlnNCeG1KvjR2zWRk7wGaE 6ZHvY1KCqwtFwUd/bzUXEdV4rEsxNF3FmXkbxPcS15OBtmNDKNLESlpDg7TlrltwTp2K zL/yD6iUKyReUJeVrYM8/+eXxQV7dchYNeNQSkZLyPWktLBkEa9wqtB460tL9eeZwYt0 +Mhw==
X-Gm-Message-State: AD7BkJLbldkymjnP0lXLX4TS8jF2cswjB0NYn4QdmguSqHA7od1pJH/y4GqTeayFoE740ZVX2LZI2nSg5uabLA==
MIME-Version: 1.0
X-Received: by 10.13.214.1 with SMTP id y1mr16181405ywd.307.1458073319645; Tue, 15 Mar 2016 13:21:59 -0700 (PDT)
Received: by 10.129.32.196 with HTTP; Tue, 15 Mar 2016 13:21:59 -0700 (PDT)
In-Reply-To: <CAH9QtQGdZ9=XG-Qc5G6amM1pOnBse5jZndL0kExxArWXoQbhsQ@mail.gmail.com>
References: <CAH9QtQGdZ9=XG-Qc5G6amM1pOnBse5jZndL0kExxArWXoQbhsQ@mail.gmail.com>
Date: Tue, 15 Mar 2016 16:21:59 -0400
Message-ID: <CAAF6GDegiWr3cWPpQAiVTZ5RhWFg24C-=SB=b=tKVTpaPn3V5g@mail.gmail.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
To: Bill Cox <waywardgeek@google.com>
Content-Type: multipart/alternative; boundary=94eb2c0770e4468a25052e1c2615
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_LBlzL1H8UzstvpGBd0bTvu_Ddg>
Cc: "tls@ietf.org" <TLS@ietf.org>
Subject: Re: [TLS] Simple, secure 0-RTT for the masses
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: Tue, 15 Mar 2016 20:22:02 -0000

On Tue, Mar 15, 2016 at 3:51 PM, Bill Cox <waywardgeek@google.com> wrote:

> I think it is worth documenting what we feel would be the simplest secure
> 0-RTT mode that is safe for any company to use.  I think we owe the users a
> link to such a document in the TLS 1.3 spec.  Here is my attempt at
> creating the simplest possible TLS 1.3 compatible safe 0-RTT scheme.  It
> uses a traditional server-side session-cache.
>

Thanks for the awesome write up! This helped me clear my thinking a lot,
especially the proof.


> During a 0-RTT resumption handshake:
> - Get the session ID from the ticket, check for a cache hit, and drop to
> 1-RTT if not found
> - compare the resumption counts in the session state and ticket, and fall
> back to 1-RTT if they do not match
> - increment the resumption count in the ticket and session state
> - send the updated ticket to the client
>

Here the resumption counts have to be synchronized between the client and
server, but is the count cryptographically authenticated? can can attacker
can take 0RTT data from session N, increment the resumption count, and
replay that 0RTT data?

Since synchronization and authenticity are both required here, would it be
simpler to use the sequence number and PRF state from the session? it can
be saved by the client and server on session close, and they take off where
they left things on any subsequent connection. That also gives clients and
their users additional confidence in the protocol: the server can't just
ignore things like resumption counts.

Another sort of warm and fuzzy reason I like this is that the whole thing
resembles a single-long-running regular TLS connection over a single TCP
socket. That makes things easier to verify, and some things easier to
implement.

To see that this provides roughly TLS 1.2 security, note that so long as
> the protocol never has to drop to 1-RTT, it is basically equivalent to TLS
> 1.2 session-ID based resumption.  When we do drop down to 1-RTT, we will
> replay 0-RTT application data, opening up new replay attacks.  However,
> after this paper
> <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN>, I do
> not believe there are any significant new replay attacks against HTTPS,
> ssh, or any real protocol I can think of.
>

Unfortunately I don't think that's a safe assumption. The paper is about
browser behavior, but there are API clients and SDKs that do not retry as a
matter of design, they rely on TLS for non-replayability. In any event,
there might be no problem: wouldn't it be a TLS library bug if the library
somehow fell back to 1-RTT mode while also decrypting and passing on the
0RTT data? the client and the server need to agree on whether it was
received.
-- 
Colm