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

Colm MacCárthaigh <colm@allcosts.net> Tue, 15 March 2016 21:45 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 3D4C312D661 for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 14:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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] 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 z_a1e47O3rRc for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 14:45:04 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 BEE8012D568 for <TLS@ietf.org>; Tue, 15 Mar 2016 14:45:03 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id m126so14797922ywd.0 for <TLS@ietf.org>; Tue, 15 Mar 2016 14:45:03 -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=AFXRBdorqy2kCcCpXTZwtURZC93EYRojNvhpGSmQzQo=; b=eS8eTWasi08B6DH04KUUun3bVfxWzzH6+ub7h8aeVEBC34Dg8UiQe8pvxnnLuQ/u5D 9VsJ97NG8OFm+2DTqfuChpnYiIrksQrfP7r8cqfEyp9QKZz92rk24sxx/l0JtonVkP2i y3d2wybC1qXG0C/wvXfkEnnKquuQ0BFZYBhygq33a6nQIh6hchXPGiXrcKx5bsaiAbmX lEiughm72qjToqC3f0a+t/Kv/VLrSeiHuSzIzUnnmAPQaGoWlP8YQAHuR5kNfcMrXCAz mizhPtfWwNYynaONTSnbcgJDdEi8hzj1El6ZwolX1yB0bPzCTmfBnp40fHAUMWu+a0H3 xUmg==
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=AFXRBdorqy2kCcCpXTZwtURZC93EYRojNvhpGSmQzQo=; b=Q8JbU7gALc6U/ApHQtWLtmZN6qh6TtCZM3OSEAYE+aDyUVX2RcOZRe+fSROWwT5Ofo WSouMAOCsVyZBi6Ybc7XzR6rQFnbrmDAGNXgIRVTb/rLAlNHDYOcB1duAM+hiYWf0mfy mVPJCQKaS3H9wvOKmrn3bv5zeb3w4T7hhh5FgQlztzlOcPpxfliAVKEgt+MKpnMgcjS6 l5AatJlUrF48XgGthdMgv9CR/irVXI9Gwy8onYitth+RB+79RWdorhm6uW0uKHpfKScd RBihWUKsg4wNFpOn0DxDPCmiOaHnnqdht8QhazJ+QL9zDfBJUhX7Yt+xpZ6fYK7xZqee it1A==
X-Gm-Message-State: AD7BkJL6BozWe6lhCFnNL0NAhYwAfXRET/1hz24khTAY9JSfvb28U6h8evUNvoPrme9sdtQwASssUzoB9itdrg==
MIME-Version: 1.0
X-Received: by 10.129.155.81 with SMTP id s78mr163309ywg.24.1458078302934; Tue, 15 Mar 2016 14:45:02 -0700 (PDT)
Received: by 10.129.32.196 with HTTP; Tue, 15 Mar 2016 14:45:02 -0700 (PDT)
In-Reply-To: <CAH9QtQHvrz0guqGeMxD-C1ifCLOvOuADGdeqtCMHkEnRZ=y+hw@mail.gmail.com>
References: <CAH9QtQGdZ9=XG-Qc5G6amM1pOnBse5jZndL0kExxArWXoQbhsQ@mail.gmail.com> <CAAF6GDegiWr3cWPpQAiVTZ5RhWFg24C-=SB=b=tKVTpaPn3V5g@mail.gmail.com> <CAH9QtQHvrz0guqGeMxD-C1ifCLOvOuADGdeqtCMHkEnRZ=y+hw@mail.gmail.com>
Date: Tue, 15 Mar 2016 17:45:02 -0400
Message-ID: <CAAF6GDc+Lnzpx38YT0gvgetb8E9yVsgMkLMh1SB7tu=fw_SK4A@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=94eb2c0b8e7c4d55f6052e1d4f96
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ptaReCwePAxYiKMV4sIBTcLulcg>
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 21:45:06 -0000

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

> I prefer your solution, but it would require getting the TLS 1.3 protocol
> changed.  TLS 1.3 seems to be geared towards making stateless resumption
> with reusable tickets.
>

We keep circling that alright, and it doesn't work without sacrificing FS
and/or replay-protection :(


> The issue seems to be that in TLS 1.3, tickets are reusable multiple times
> to resume sessions, so we can't store the TLS sequence number in the
> ticket.  If this were being used for an actual pre-shared key resumption,
> it would probably be OK, but it seems to break security in multiple ways
> when using tickets for TLS 1.2-style resumption, leaving us with no choice
> but to emulate the continuation of the TLS sequence numbers (and PRF
> state?  Is that needed?).
>

Sorry; I confused things by saying with PRF-state, but what I had in mind
there was turning the crank on the PRF to derive new encryption and mac
keys for the resumed session. If you do it that way; and if the PRF
provides anti-backtracking, then compromising the session cache can only be
used to decrypt future resumed connections, rather than anything previously
collected or currently active. If you're going to increment state for each
resumption; might as well provide forward secrecy too.

Protocols seem to fall into two camps.  The ones that require replay
> resistance from the TLS layer all seem to terminate TLS connections in the
> same place so that the session cache can be safely and efficiently
> synchronized, avoiding replay attacks even when using 0-RTT.  For example,
> when ssh-ing into a machine, that one machine terminates the connections,
> and can have a shared cache.  None of the 0-RTT TLS-layer replay attacks
> I've read seem to work against a single server-side session cache.
>

I think I agree with that; but maybe would state it as: we can preserve
forward secrecy and replay mitigation for 0RTT data, but at the cost of
read-after-write consistency from a server-side data-store. The store
needn't be transactional, an eventually consistent store could be used: but
the miss-rate would be elevated over what we see today. So it would work
better in the single server case than the many distributed servers case -
but could work for both.


> The other camp is HTTP-like protocols that terminate all over the place.
> These all seem to be replay-tolerant because random network errors will
> cause random replays, and there is no efficient way to synchronize the
> session cache globally.
>

I think that's a dangerous position too. Triggering browser retries
requires a certain level of difficulty and has a certain amplification
factor. Sniffing wifi and sending a TCP message is far easier. An attacker
could exhaust things like server-side request throttling limits far more
quickly with the latter than the former. Besides: lowering our own levels
of security because other tools have already done the same is just another
race to the bottom.

-- 
Colm