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

Watson Ladd <> Fri, 07 November 2014 05:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4676F1ACEE6 for <>; Thu, 6 Nov 2014 21:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yh-VLe2byZxH for <>; Thu, 6 Nov 2014 21:45:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D649B1ACEEB for <>; Thu, 6 Nov 2014 21:45:20 -0800 (PST)
Received: by with SMTP id t59so2122610yho.13 for <>; Thu, 06 Nov 2014 21:45:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QT3rUfMKdltQWUhulJmhaxWIfCXgEnwPW78VJrPlNjM=; b=inJuO1gyWH8f0r0EHbyZwmgovHziZap1qBxHvM6zUWULF8cPQfZPv9eJyLVqymiChQ TuLAqbm0YSLd5cA7NLxxhulbP+IO2bvYmC4aOn8Iuwul3bcnlZ6hyUzVekzV8VDEyKGs Fyi1eo1euBC7Bh++7nrLw4y8E8XsybaAyu4zNZWkokRxNLJStZzDttNJkE46NNO2vHIs HElaeRGPPlZ3zEnsvmI+dg+6jXWXJsXMGP0CSlE2qokTzx4qDptkuoYkpuxPOl/HgUq7 x/qOnRdPSBwu3qlrN79VZuVg381+apjZw5WNzOs0XT9kdExzuoCGtGgROHKwAbmTmjN7 S7cQ==
MIME-Version: 1.0
X-Received: by with SMTP id k45mr8637860yha.163.1415339120173; Thu, 06 Nov 2014 21:45:20 -0800 (PST)
Received: by with HTTP; Thu, 6 Nov 2014 21:45:20 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 06 Nov 2014 21:45:20 -0800
Message-ID: <>
From: Watson Ladd <>
To: Andy Lutomirski <>
Content-Type: text/plain; charset="UTF-8"
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 05:45:26 -0000

On Thu, Nov 6, 2014 at 6:41 PM, 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.

Note that in the above proposal, long-term can be entirely defined by
the server or client as the case may be. I feel I'm missing something

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

The client cert that is? I'm not sure what this gets you: we know how
to use certs securely.

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

If supersingular isogeny volcanoes are secure, it won't be a problem.
NTRU for old TLS is also a possible backup plan.

> --Andy
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin