Re: [TLS] 0RTT? (Martin Rex) Mon, 04 August 2014 21:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 31DCB1A0320 for <>; Mon, 4 Aug 2014 14:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.852
X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UfwGQ09wUusV for <>; Mon, 4 Aug 2014 14:01:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 66BB51A0100 for <>; Mon, 4 Aug 2014 14:01:04 -0700 (PDT)
Received: from by (26) with ESMTP id s74L12tY005596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Aug 2014 23:01:02 +0200 (MEST)
In-Reply-To: <>
To: Watson Ladd <>
Date: Mon, 4 Aug 2014 23:01:02 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Cc: "" <>
Subject: Re: [TLS] 0RTT?
X-Mailman-Version: 2.1.15
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: Mon, 04 Aug 2014 21:01:08 -0000

Watson Ladd wrote:
> I think I came up with a decent idea for handling 0RTT handshakes,
> namely making resumption 0RTT, and doing a side rekeying.

These idea(s) seem to based on a number of extremely optimistic
assumptions that have zero chance to get airborne in many usage

The "regular" TLS session resumption means that client announces
a TLS session ID in ClientHello and server looks up that session ID
in its own cache for a match.  If there is no match, a regular
TLS full handshake proceeds.

0RTT is a no-go for a huge number of existing apps which do not
perform any fancy reconnect fallbacks at the application level
(closing the previous connection, opening a new connection and
starting a new handshake from scratch while requesting different
handshake characteristics this time).  For the general case
a 1RTT resumption is required, which can successfully perform
a full handshake in case that resumption is not possible,
without having to go through a connection/handshake failure.

> The big limitation is ticket keys are going to need rotation. This
> also doesn't address the desire to put extra data in DNS to give some
> degree of forward secrecy, but I don't think you can change DNS that
> quickly without some problems.

The visibility of data DNS is another bold assumption that doesn't
hold for a number of usage scenarios.  It is pretty normal for
company networks to run their own DNS universe internally, and
provide accessibility to servers on the internet only through
HTTP CONNECT proxies.  In general, only these HTTP proxies have
access to both DNS universes (internet and internal).

I remember when Java applets became popular for use with online
brokers ~17 years ago, and lots of these applets crashed and burned
behind HTTP CONNECT proxies.  The browser had no problem connecting,
but the applets choked on hostnames that didn't resolve.  The
workaround was to add the brokers web server hostname with an
arbitrary ipv4 address ( to the local host file so that
the Java applet would get a(n obviously useless) response
from gethostbyname() and be happy.