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

Hugo Krawczyk <> Fri, 07 November 2014 08:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 911BD1A1A9A for <>; Fri, 7 Nov 2014 00:33:10 -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 ybXgKuDOWjHr for <>; Fri, 7 Nov 2014 00:33:08 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE10D1A1A99 for <>; Fri, 7 Nov 2014 00:33:07 -0800 (PST)
Received: by with SMTP id z12so2279547lbi.15 for <>; Fri, 07 Nov 2014 00:33:06 -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=V1JdVPnklbDbGBGHzUKkYggGGZWORJjfiPCXpgS0Vhc=; b=mJN5OdBV30RDDM+MuoSbAaJxyok53Jq5VfJ8iSGg8cOmSzQ9A/Ph1bvLeY48ratj/F n4xlLvN0H8PT98zZ2SLO21r/BidUetLXkI1kiIw2fmJKDKVyK0Dy0oeha6CfO1kK7sVU 73hGg982jPaxiDwNf4KzZI+C51ooD8Mqy3JH/yS6VF73qIoaX2KO/sCPLa/4p9HBFYsd c47LWhGpOlsirsz8wtADXizXL+ZS3gN7vgTKEmGUcS5FqIRxuG7qrJsmKH18ZwQilKLe XK1RkVJLvya/ZBhZ9L0hDPRI0hSIk6NTpyoE2YqjSPOn4wEqfl7tJRnx5rncswv+VxhA aXMg==
X-Received: by with SMTP id v1mr9838405lal.3.1415349186366; Fri, 07 Nov 2014 00:33:06 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 7 Nov 2014 00:32:36 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Hugo Krawczyk <>
Date: Fri, 07 Nov 2014 10:32:36 +0200
X-Google-Sender-Auth: 6RKT_uUV9NazNtIeGZYxYi_O86I
Message-ID: <>
To: Andy Lutomirski <>
Content-Type: multipart/alternative; boundary="001a11c356267c94b5050740a93f"
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 08:33:11 -0000

Regarding the post-quantum question below: Any public key encryption (PKE)
mechanism can be used for PFS, you just need to generate session-specific
private-public key pairs and use them for that session only. So any
quantum-resistant PKE (QR-PKE) scheme can be used for PFS. More
fundamentally, digital signatures do not suffice for key exchange. You need
a  PKE, or similar mechanism, to actually exchange the key (signatures are
only good for authenticating the exchange). Once you have a QR-PKE, you
replace the key g^{xs} in OPTLS with an encryption of a random key under
the server encryption public key and use this random key for computing the
Finished message.

By the way, I am personally more concerned about the possibility of a
significant advance in (classic) ECC cryptanalysis in the near-medium
future than with a practical-enough quantum machine that can break the ECC
cryptography. In particular, progress in quantum will most likely be
gradual and will give us time to prepare the next-generation QR
cryptography while a mathematical break of ECC could happen overnight (or
over several nights :). For all we know, it might have already happened...
(I guess one can say that someone might have already built a quantum
computer but to me that looks much more unlikely).


On Fri, Nov 7, 2014 at 4:41 AM, Andy Lutomirski <> wrote:

> 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?
> --Andy