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

Colm MacCárthaigh <> Wed, 16 March 2016 04:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38B2812D7CB for <>; Tue, 15 Mar 2016 21:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o40DhkYMaBId for <>; Tue, 15 Mar 2016 21:33:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A977212D56B for <>; Tue, 15 Mar 2016 21:33:41 -0700 (PDT)
Received: by with SMTP id m126so24150527ywd.0 for <>; Tue, 15 Mar 2016 21:33:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=X4LI0jATIQstW5oLXuZRYRyo/PBvqmkay8SgcVgHjyM=; b=z09IzjPZqfsc+2d6AHWLv6qxSHCGe9qMnxcMlxWea+hqoEbnTI6/QfPi4rQhzg8QxW G3GnRWIAHQmUm5qDbXHLLtPfvYW6YxbO5j5Xj6SNSF2xjogRRcZj42tuRuAwlqOE2zRy p1WGfnED82FstBAy7biXBW2Ats1QQH6i7KA/CrYrQf18QPxlEUmaNyg4J6E08exTnPuO h4V7Qwk18vulqQ3RvQaQUFTgb4WcW1lyUwB1XV5F/AvGU/KXU4xxPafiWSBtC1pvVq5C KF1GOQ9paB4edKUtafKEs/Nzo1WsmBAG3okAwGO29uu0emTeQH3K7Yew/U5LgeLwxzjS fmOw==
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=X4LI0jATIQstW5oLXuZRYRyo/PBvqmkay8SgcVgHjyM=; b=M+Cs8vV9k5kvxxsvX2229bz5CuVuGHGA+B+uXeypEuUzkZM/3tT+52Cpu95QCY/+Nj VKof/kGSfQwljiCp6q19Ch0NnH9TygdFTWoz2cF9gDIMcaXqWKMR8Wm5oiGgEz0B6VKd jSUPlsGM2rGah4IrbC780ZiRjaDsM02g+v49nscvM6PfcRxIBXcj4dt7vUBQehBzBRZI ZF3VyAQ0Xk1ljz45mKlP6A6xmglbahxe0JNX+sPZIIFlo4zTsMEejs1mPIqkx7tTAjDh V9qVERTXWu6A1z7tqqpTHKMo6ZDKQ2oJBg99iTPOHLNkPrTmq+UVKD87ccPGJijC0qX9 03Rw==
X-Gm-Message-State: AD7BkJKNUZU7/yIf1sILUw4OcdMlW4/fA0HPbkPxTCrcVTvU7VCr7WBwAXcEs8EBbwvdouCCi7lo4W8Tk0jxvA==
MIME-Version: 1.0
X-Received: by with SMTP id u7mr739650ywd.100.1458102820861; Tue, 15 Mar 2016 21:33:40 -0700 (PDT)
Received: by with HTTP; Tue, 15 Mar 2016 21:33:40 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 16 Mar 2016 00:33:40 -0400
Message-ID: <>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
To: Bill Cox <>
Content-Type: multipart/alternative; boundary=001a114e7e78af2cab052e23043f
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 04:33:43 -0000

On Tue, Mar 15, 2016 at 9:38 PM, Bill Cox <> wrote:

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

After meditating on this a little, how about something like this:

Benefits Forward secrecy:

* Clients SHOULD use a resumption ticket only once, and get a new
resumption ticket when using an existing one.

Benefits Forward Secrecy and Idempotence:

* Client and server should erase the existing ticket upon use.

(a captured early data section is mooted for replay quite quickly in the
default "good" case)

Benefits Idempotence;

* Make early data and application data separate record layer content types.
Make it clear that they do not form a continuous stream; you can't simply
concatenate them at the application level and bolt on to existing protocols
such as HTTP, SMTP, etc.

* Advise that clients using 0RTT SHOULD occasionally send duplicate early
data handshakes. As a normal part of the protocol, a well behaved client
should intentionally do what an attacker might do and send the whole
section twice, causing the server to resolve the duplication. Keep the
anti-bodies strong.