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

Andy Lutomirski <> Fri, 07 November 2014 02:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 743DB1ACE9D for <>; Thu, 6 Nov 2014 18:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mlWqKRa0P3z6 for <>; Thu, 6 Nov 2014 18:42:01 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC1A71ACE9B for <>; Thu, 6 Nov 2014 18:42:00 -0800 (PST)
Received: by with SMTP id u20so1740859oif.25 for <>; Thu, 06 Nov 2014 18:42:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/V7zTxUKgtOHaesIdid92n9f61Hgl2MoVZug6QGcHJY=; b=QxcQzUHMTbdk9QAy+NxCiot1LvaQKpu+PRYpnGX3TL297+ObG+1oxXbU/p7Bp6Q+3I Z2VBJa9WIpYooDmD/QP+iXKbxlm0VwP5LxZFlzxyXpqgQR3mE/eCs2LgsOPjmPLYb8KX 3mQ85OSagHYbmEgitc0L1yoeR3qEESq8DTj1yVHTkgk4dFCrwMhhtASOOilBsyWswU5i Yu2oVzIsnfs+KvdmhABKGy/mfd1l6XQFZXwclJzUr8BIlEc4EERnkfKG2f4ZUy4835uE j8MNXWoZRfQNY630ZQXmdbV6/jxgPthdX4mxKtBR1amGspJFav9rilRKjyUfYtksQ84r KHLA==
X-Gm-Message-State: ALoCoQmDWsXYmwR3JGWGIUPiXvg8WyJGY+knPoIfZ1bbTMFWuVA9sC460nR1uQnlm0S0cKbunnpI
X-Received: by with SMTP id f189mr5519060oib.25.1415328120204; Thu, 06 Nov 2014 18:42:00 -0800 (PST)
Received: from ( []) by with ESMTPSA id yq1sm3432228obc.15.2014. for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Nov 2014 18:41:59 -0800 (PST)
Message-ID: <>
Date: Thu, 06 Nov 2014 18:41:57 -0800
From: Andy Lutomirski <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Hugo Krawczyk <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
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: Fri, 07 Nov 2014 02:42:02 -0000

On 10/31/2014 05:54 PM, Hugo Krawczyk wrote:
> During the TLS interim meeting of last week (Oct 22 2014) I suggested
> that TLS
> 1.3 should abandon signature-based authentication (other than for
> certificates)
> and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
> static Diffie-Hellman for authentication. This has multiple benefits
> including
> major performance gain (by replacing the per-handshake RSA signature by the
> server with a much cheaper elliptic curve exponentiation), compatibility
> with
> the mechanisms required for forward secrecy, natural accommodation of a
> 0-RTT
> option, and a simple extension without signatures for client authentication.

I like this idea a lot.

> Note on certificates: Since in current practice servers hold
> certificates for
> RSA signature keys rather than for static DH keys, the certificate field
> in the
> above protocol will be implemented by a pair consisting of (i) the
> server's RSA
> signature certificate and (ii) the server's signature using this RSA key
> on the
> server's static public DH key g^s. The latter signature by the server is
> performed only when a new static DH key is created (how often this
> happens and
> how many such keys are created is completely up to the server - it has the
> advantage that these keys can be changed often to increase security against
> leaked keys). This use of RSA also enjoys the high efficiency of RSA
> verification for the client. 
> The handling of Client certificates would be similar.

I would like to see one modification of this: I think that the
certificate should be (RSA/ECDSA certificate, server's long-term DH
share, expiration), signed by the cert.  That way any user of a
certificate can sign short-term shares instead of long-term shares,
significantly reducing the impact of a leak.

It would be even better if there were a way to limit one of these things
to a certain host.

That being said, I do have one significant concern with this: what
happens when someone builds a quantum computer?  I don't expect TLS 1.3
to be post-quantum secure, but I would like the road to replacing
primitives for post-quantum security to be reasonably clear.

Unfortunately, I'm not aware of a credible post-quantum DH-like
construction.  On the other hand, post-quantum signatures are
straightforward if rather large right now, and post-quantum public-key
encryption is, as far as I remember, not guaranteed to be a drop-in
replacement for DH.

Will this end up being a problem?