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

Colm MacCárthaigh <colm@allcosts.net> Wed, 16 March 2016 04:33 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 38B2812D7CB for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 21:33:43 -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 o40DhkYMaBId for <tls@ietfa.amsl.com>; Tue, 15 Mar 2016 21:33:41 -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 A977212D56B for <TLS@ietf.org>; Tue, 15 Mar 2016 21:33:41 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id m126so24150527ywd.0 for <TLS@ietf.org>; Tue, 15 Mar 2016 21:33:41 -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=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; d=1e100.net; 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 10.13.210.7 with SMTP id u7mr739650ywd.100.1458102820861; Tue, 15 Mar 2016 21:33:40 -0700 (PDT)
Received: by 10.129.32.196 with HTTP; Tue, 15 Mar 2016 21:33:40 -0700 (PDT)
In-Reply-To: <CAH9QtQF02zwnB6dOGjFfWX2RLc4_RSODFpHaVLZkK_5KDf93sg@mail.gmail.com>
References: <CAH9QtQGdZ9=XG-Qc5G6amM1pOnBse5jZndL0kExxArWXoQbhsQ@mail.gmail.com> <CAAF6GDegiWr3cWPpQAiVTZ5RhWFg24C-=SB=b=tKVTpaPn3V5g@mail.gmail.com> <CAH9QtQHvrz0guqGeMxD-C1ifCLOvOuADGdeqtCMHkEnRZ=y+hw@mail.gmail.com> <CAAF6GDc+Lnzpx38YT0gvgetb8E9yVsgMkLMh1SB7tu=fw_SK4A@mail.gmail.com> <CAH9QtQF02zwnB6dOGjFfWX2RLc4_RSODFpHaVLZkK_5KDf93sg@mail.gmail.com>
Date: Wed, 16 Mar 2016 00:33:40 -0400
Message-ID: <CAAF6GDd0h=1--pViASw3pT5nMAM4SRy2C2hzA6XF7Ba_g+oL4w@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=001a114e7e78af2cab052e23043f
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Acvj34TwsrcCC8qedjaCY6a1DaA>
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: Wed, 16 Mar 2016 04:33:43 -0000

On Tue, Mar 15, 2016 at 9:38 PM, Bill Cox <waywardgeek@google.com>; 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.

-- 
Colm