Re: [TLS] Re-thinking OPTLS

Nico Williams <nico@cryptonector.com> Tue, 25 November 2014 03:49 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347B31A1B8C for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 19:49:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 EFfiT5lI_P7l for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 19:49:18 -0800 (PST)
Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6D28B1A1B8A for <tls@ietf.org>; Mon, 24 Nov 2014 19:49:18 -0800 (PST)
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 34A691B4058; Mon, 24 Nov 2014 19:49:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=6MDFF8BRgDPszV +SUF4b8//IIxU=; b=nYiZR93QqIhzUT8lG51PFWRcPxXWBrfe6TiwyHbqRBI1pG TWZ5Jl1v/iR4GJ+VuJ89mGbAEMP4/WRQqZsAUlRyc69hijlzPRHxW9udDpLbNC7h poOd4gmXHionfTa3ieYJRvz+9SrUxt4C5a5AbzUhwB55bltyPfmRFHHWI9nN8=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id D72121B4057; Mon, 24 Nov 2014 19:49:17 -0800 (PST)
Date: Mon, 24 Nov 2014 21:49:17 -0600
From: Nico Williams <nico@cryptonector.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Message-ID: <20141125034915.GT3200@localhost>
References: <CADi0yUMCGuYbqrJWa-KXNmgNvc19xOWwpx2DCLOvgv62haedCQ@mail.gmail.com> <20141124063304.GA3200@localhost> <CADi0yUMvj7k1JXpa_9H3brUizr4QsLh6gsjzXaRJo79Vv0dqnQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADi0yUMvj7k1JXpa_9H3brUizr4QsLh6gsjzXaRJo79Vv0dqnQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3oj3mOI4Q_qAXU4DOnnr0fMDekM
Cc: "tls@ietf.org" <tls@ietf.org>, Hoeteck Wee <hoeteck@alum.mit.edu>
Subject: Re: [TLS] Re-thinking OPTLS
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 25 Nov 2014 03:49:19 -0000

On Mon, Nov 24, 2014 at 07:06:18PM -0500, Hugo Krawczyk wrote:
> On Mon, Nov 24, 2014 at 1:33 AM, Nico Williams <nico@cryptonector.com>
> wrote:
> > I'm in favor of using static server (EC)DH keys for server
> > authentication and possible 0-RTT, particularly in connection
> > with DANE.
> >
> > I *don't* think that OPTLS is worthwhile without connection to DANE, but
> > only because OPTLS is just an optimization with roughly the same
> > applicability as an existing optimization that is much faster: session
> > resumption [with encrypted session state tickets].
> >
> 
> Session resumption is indeed faster if you don't do PFS - otherwise it is
> still faster but not by much.

If one wants half-PFS (foward security relative only to client
compromise) including for 0-RTT data then OPTLS wins every time.

> And of course, as I'm sure you agree, there are 0-RTT scenarios that cannot
> be  reduced to session resumption as in the QUIC case mentioned by AGL or
> any setting where keeping a shared secret state at the client is not
> practical.

Hmm, a client that can't keep a shared secret around probably can't keep
a server sub-cert either...  Nor reuse its ECDH keys (which the QUIC doc
linked by AGL talks about in conjunction with caches of shared keys,
which then is a lot like resumption).  A client that can't keep state
could use DANE though, and thus get 0-RTT with half-PFS every time.

Of course, it's all about relative numbers: how long a client is willing
to go without using new keys for PFS (relative to client compromise),
how frequently it connects to the same server, and how long the server
is willing to go without using new keys for PFS (relative to server
compromise).  That the client is more sensitive about PFS than the
server makes some sense.

(Shouldn't we really speak of PFS relative to compromise of each peer?
After all, they can't really prove that the other peer isn't reusing
PKs, not spending without extra effort monitoring for reuse.)

Nico
--