Re: [TLS] OPTLS: Signature-less TLS 1.3

Hugo Krawczyk <> Tue, 04 November 2014 08:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E0351A7002 for <>; Tue, 4 Nov 2014 00:47:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 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, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UtUpj4NntJOS for <>; Tue, 4 Nov 2014 00:47:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98C5D1A8882 for <>; Tue, 4 Nov 2014 00:47:38 -0800 (PST)
Received: by with SMTP id mc6so452539lab.26 for <>; Tue, 04 Nov 2014 00:47:37 -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=duB39/5+icjvOV5GHcNc3D9aebHIv8j9F22FzV2u0gA=; b=FG9TmHHOkEKfu7suZeLehgYzZJzokJBRChmkmxb93wu7WhnGqsStQBwO8YI/RF64v7 JJbVIowKdk1MQAy5/uiYp2DKZGFvqO8jWqoQ08KWlBON3Xgbn3qoPZfUDD5MD2BMfi/x VfgOE4sJQAqRX1ZwvNYaHuzns9tWIX3XREKn6K4ZoI8HBwGFGvTD5NqjIua2DOSm1HjK hO9wZhqSsEGdfjH9IlwGBwZJCiGM5TUjUgDkXL/ADwNgNfvBUR1ipWzIz4qpuKLKq5Nu WB6E9bok+AO+blHItpx8H8uwrI/ybvvv4+EjH8DhypJ+8D4Fnje2GKxbNla++6QaTA03 rQuw==
X-Received: by with SMTP id q4mr56038806laa.48.1415090856910; Tue, 04 Nov 2014 00:47:36 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 4 Nov 2014 00:47:06 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Hugo Krawczyk <>
Date: Tue, 04 Nov 2014 10:47:06 +0200
X-Google-Sender-Auth: wO3MuXeesd19VSaxW1z6x11mpiU
Message-ID: <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary="001a11c34ee0d9e66205070483de"
Cc: "" <>, Hoeteck Wee <>
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3
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, 04 Nov 2014 08:47:40 -0000

On Mon, Nov 3, 2014 at 6:47 PM, Nico Williams <> wrote:

> On Sun, Nov 2, 2014 at 4:24 PM, Hugo Krawczyk <>
> wrote:
> > Don't forget that 0-RTT cannot be supported with a signature-based
> protocol
> > so in that sense going to static DH is a win-win.
> That was DJB's point a while back, and, really, this goes back to the
> old AUTH_DH concept back in 1986.  It goes back further, actually,
> IIUC, all the way back to DH's invention.
> If you know the peer's public DH key a priori (from DNSSEC, from
> /etc/publickey [who remembers that?]) then you can send one security
> context establishment message and immediately start sending encrypted
> and authenticated data.  You need a response message to get key
> confirmation, and you can't get PFS until after consuming that
> message.
> (The GSS-API deals with this, incidentally.  A security context can be
> partially established but ready to encrypt application data with
> security caveats.  This is called "prot_ready".)
> A proper static-static DH + PFS exchange would take the usual 1.5
> round trips, but would be "prot_ready" in 0 round trips.
> There's a lot to be said for this.  But note that RSA key transport
> also lends itself to being prot_ready in 0 rt, so we still need to
> quantify the total cost of static-static DH + PFS, and RSA key
> transport + PFS for a proper comparison.

​The costs for the 0-RTT option in addition to the cost of an ephemeral DH
are as
DH+PFS: a single variable-base exponentiation for client and server.
RSA+PFS: for server an RSA decryption, for client an RSA encryption.
So the computational advantage of DH+PFS is very significant for the server.
For client RSA-PFS has some advantage as RSA encryption is faster than a DH
exponentiation but the difference is less dramatic than for the server, in
particular considering that the client is already doing two DH
In addition, RSA encryption requires added protocol operations (and
implementation care) to prevent Bleichenbacher attack (e.g., you'll need to
dummy-decrypt ClientData even if the received ciphertext is illegal).
And aren't we in the process of phasing out RSA wherever possible?


> Nico
> --