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

Bill Cox <> Wed, 16 March 2016 01:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7EC912D6B1 for <>; Tue, 15 Mar 2016 18:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x_E5sKMaf2Xy for <>; Tue, 15 Mar 2016 18:38:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE10D12D84A for <>; Tue, 15 Mar 2016 18:38:42 -0700 (PDT)
Received: by with SMTP id g203so46341441iof.2 for <>; Tue, 15 Mar 2016 18:38:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=WVU1UHOoTV8wO3zHCO5tN/+ndUb+SG3x3hwha8If2/A=; b=HprMrsMMWSPKFvU/7uo+bpAQzutIcAPvutUmP/ssLRv7zSELBBZ84ZwwZPp1Z7HpGV bsR3yfrUf8lAQgY9dhm1Cr4MHTO5q3mXqEyVEZmHaYAC2xy/DLasZmpbSzwPLpKP69GN Q3kt7djO9pepYhra3ge/sappYT5ZzskTvQoTqnFwkOYKIR6sgnjNY+D4t7w5yyNLhxfJ qaMKIrWhMs7o5Q2DbHtA4tIes0kFlF5NzZcXv38fdJ1Fue4AcqUsqJSRPY3Rkj909WVQ ye0myYJv+W/KS4gV7EB2GUhs+bAHYqiDdgci8hTS4+vmPNIVlT5MN+6EwybIXW9000GJ nLbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=WVU1UHOoTV8wO3zHCO5tN/+ndUb+SG3x3hwha8If2/A=; b=OIy2Q8Rl3bcB5hUg73HyT9A/g1b/ybPEx6BUCzCXmb0tU+TR58CDo/RnDBMRwwQn1D yFZFNeQJYQ4ffKCxNO+BKEoM2u4OCw9qthQYsmyzAtLo10ZW5Al4Se5Crv42yR7/Sh53 FkYxapymADdlThFwwDPNb1z+3HCjPm5qP5Awfc26dq/UW0PgQ7Wawy1PaK+ZXSn7Ys8E 15WT7WHqQVZ7caSJL5yMRvsmVWQozyRJsc0KPLvBwe/0QKijLUUzKQYujKNn799T+lGY 312JFXDeFsiRDP8JbabfNkBr/0QgrEdlwOK7M3XqcBfasZSvPd2PeJoAwUUGYRXk7MKD iKpg==
X-Gm-Message-State: AD7BkJLqAi7CbijqOD1TgUwd9HR19iM63CpLMWK1ylYiUx/KkhMPnqSnKUNHWtm1RtQH0ALqVHOva3QSSw0gn/4j
MIME-Version: 1.0
X-Received: by with SMTP id 30mr1875813ioi.60.1458092321928; Tue, 15 Mar 2016 18:38:41 -0700 (PDT)
Received: by with HTTP; Tue, 15 Mar 2016 18:38:41 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 15 Mar 2016 18:38:41 -0700
Message-ID: <>
From: Bill Cox <>
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
Content-Type: multipart/alternative; boundary=001a113fb716e64bb4052e209265
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Simple, secure 0-RTT for the masses
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Mar 2016 01:38:44 -0000

On Tue, Mar 15, 2016 at 2:45 PM, Colm MacCárthaigh <>

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

Hmm... my first thought is we can't say all that in a "simple secure 0-RTT"
description :)  I do think it would help if all that and more were in a
more comprehensive document somewhere.

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

I would be happy if we could recommend at least one reasonably secure
method for 0-RTT for HTTPS that has a reasonable chance of satisfying the
skeptics, and then state that 0-RTT for other protocols, and stateless
0-RTT, needs to be carefully considered for the application.