Re: [TLS] Re-thinking OPTLS

Hugo Krawczyk <> Tue, 25 November 2014 00:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 24CC71A89F5 for <>; Mon, 24 Nov 2014 16:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zRSGwKxzwN5w for <>; Mon, 24 Nov 2014 16:06:51 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E44F61A89B5 for <>; Mon, 24 Nov 2014 16:06:49 -0800 (PST)
Received: by with SMTP id n15so2607922lbi.2 for <>; Mon, 24 Nov 2014 16:06:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=sGpW3wR7kcT4alynrEX2+Qf3xlHfqPInmIap71W/ZwQ=; b=GXRDbimMh5AnSiNx+XmIYEeSn65riIUBu1pofe//tALF1hSHrz3iWKCu1rFwzWkxUA bnMionQ3nXurE8x/PpRH46bCvGosaDE6fLdIMDsXJOQHp5kCyEgO90oNzew/FwCqbv+k X9WasfgMs6txW9Mm5Is3nJJSnm0LUGUfDPiNMPgyHZWGH5AphvCKiTDdnEJvbW5eCuXy wyOE8bye7pRyp5/X6i9Auq/gnhi08ZQpqWJ5L2R9jgnQubzjM8NXJuw1Nk6PL7nCE4YT 7ckW5ZeymyU3YJqDn+cIX+LxlLnBs07DHSDsdG2fNCKI/tNTBOPokLNVeMGUP3vGBDEz OQ5A==
X-Received: by with SMTP id i9mr1449168laf.81.1416874008260; Mon, 24 Nov 2014 16:06:48 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 24 Nov 2014 16:06:18 -0800 (PST)
In-Reply-To: <20141124063304.GA3200@localhost>
References: <> <20141124063304.GA3200@localhost>
From: Hugo Krawczyk <>
Date: Mon, 24 Nov 2014 19:06:18 -0500
X-Google-Sender-Auth: Mo0wrzZrwFNuAfg92OTXgmGMgGQ
Message-ID: <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary="089e0160b870f437190508a3afa6"
Cc: "" <>, Hoeteck Wee <>
Subject: Re: [TLS] Re-thinking OPTLS
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: Tue, 25 Nov 2014 00:06:52 -0000

On Mon, Nov 24, 2014 at 1:33 AM, Nico Williams <>

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


> But since I think sprinkling DANE on is the obvious thing to do given
> OPTLS as part of the protocol, I'm in favor.
> Security-wise the use of static (EC)DH keys is well-understood (as well
> understood as (EC)DH is in general).
> The g^xs plus (not the arithmetic operator) g^xy method of obtaining PFS
> is also OK, and heck, if need be the client could use two different x's,
> and the protocol ought to allow it (not least because the client might
> want to use different groups/ curves for PFS key agreement than for
> authentication key agreement).
> Nico
> --